Tags:
create new tag
, view all tags
The TWiki::Func API has a method called getViewUrl(web, topic). All this does is to call getScriptUrl(web, topic, 'view'). In the interests of keeping the API size down, I think it should be deprecated.

Just to remind you, deprecation does not imply removal of the code, only moving the method into the "Deprecated" section of the documentation.

The API is currently used in the following extensions:

  1. AccessStatsPlugin
  2. ActionTrackerPlugin
  3. AlbumOfSnapsPlugin
  4. BatchUploadPlugin
  5. BlogPlugin
  6. ChecklistPlugin
  7. ContributorsPlugin
  8. DirectedGraphWebMapPlugin
  9. EditHiddenTablePlugin
  10. EditInTablePlugin
  11. EditTablePlugin
  12. EditTablerowPlugin
  13. FlowchartPlugin
  14. HeadlinesPlugin
  15. ImageGalleryPlugin
  16. InlineEditPlugin
  17. JavaPasteAddOn
  18. MessageBoardPlugin
  19. MultiLangPlugin
  20. NamespaceManagerAddOn
  21. NatSkinPlugin
  22. PingBackPlugin
  23. PreferencesPlugin
  24. ProjectPlannerPlugin
  25. RedDotPlugin
  26. RedirectPlugin
  27. RedirectRegisterPlugin
  28. SeeSkin
  29. SetVariableAddOn
  30. SignaturePlugin
  31. SlideShowPlugin
  32. TigerSkinPlugin
  33. TopicTranslationsPlugin
  34. URLCachePlugin
  35. UserHomePageAddOn
  36. WebPermissionsPlugin
  37. WysiwygPlugin
  38. XpTrackerPlugin

(extensions not tracked in svn are not listed.)

-- Contributors: CrawfordCurrie - 28 May 2007

Discussion

You do not put a proposal "ReadyForReleaseMeeting" until people have had a chance to discuss it here in Codev.

Our release meetings take too long when we put up proposals that have not been digested and we usually end up not making any decision.

That is also why the release process says that it is a customer advocate that puts a proposal in ReadyForReleaseMeeting.

Since this is not a proposal that involves code of any kind - and therefore no risk of a new bug - there is no reason why it cannot be decided after the feature freeze and make it to 4.2.0 so there is no reason to rush it to tonights meeting (the 28th).

-- KennethLavrsen - 28 May 2007

Sorry; there's no help in the form, and I'm never sure what the right procedure is. Maybe if you added some nameless labels (inline doc) like we have in the Bugs web that would help....

-- CrawfordCurrie - 28 May 2007

I do not have a strong opinion on this one, but in general I'd prefer not to deprecate popular functions, even if you can do the same with another function. This function is used by 38 extensions in the SVN repository alone (probably more in extensions published on twiki.org only), meaning that all those extensions need to be updated in future releases or risk being labelled as non-compliant at least. The XpTrackerPlugin uses this function 10 times.

Writing getViewUrl(web, topic) is shorter than getScriptUrl(web, topic, 'view'), and also easier to discover in the list of functions.

-- PeterThoeny - 29 May 2007

Agreed; my concern is soley that the API is getting quite large, and very similar functions tend to confuse users. I can't think of any simple rules to offer for when getViewUrl should be used in preference to getScriptUrl, mainly because AFAIK there are no circumstances in which it's preferable.

-- CrawfordCurrie - 30 May 2007

Since the only motive is to avoid a function call that can be avoided by calling another funtion with different parameters I am against deprecating the function. We can avoid issues in the future by keeping the API stable.

-- PeterThoeny - 30 May 2007

Let us vote on this after 4.2.0 release. No urgency.

-- KennethLavrsen - 03 Jun 2007

See the recent benchmark results in InvestigatingTWikiPerformance. The more "dead" code we leave lying around, the slower TWiki gets.

-- CrawfordCurrie - 06 Jun 2007

I find this is a little stretched. This little procedural function call is negligible to the initialization and object binding going on elsewhere in the core.

-- PeterThoeny - 06 Jun 2007

As I said, death of a thousand cuts. Heal one cut, that's another milliscond you never have to worry about again. Func is already one of the largest (and slowest to compile) modules. But the main drive is keeping the API clean and simple, and not allowing it to get overweight. As I said above, I can't think of any simple rules to offer for when getViewUrl should be used in preference to getScriptUrl, mainly because AFAIK there are no circumstances in which it's preferable. So why keep it?

-- CrawfordCurrie - 08 Jun 2007

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2008-02-15 - CrawfordCurrie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.