In Cairo, there was a configuration item called
$dispViewPath
and described as "URL path to view script used to render links, relative to =$dispScriptUrlPath=". There was two functions used to build URLs :
-
getViewUrl
to build URLs using the view
script : basically in the form $dispScriptUrlPath/$dispViewPath/WEB/TOPIC
-
getScriptUrl
to build URLs using any other script : basically, in the form $dispScriptUrlPath/SCRIPT/WEB/TOPIC
Several documented shorter-URLs setup for Cairo depend on this distinction, in order to set
$dispViewPath = ""
, and build URLs without
view
:
This topic has been discussed on
TWiki:Codev/ShorterURLs
.
In the current Dakar code,
$dispViewPath
has vanished, and
getViewUrl
simply calls
getScriptUrl
.
Martin Cleaver asked me to package the latter as a contrib alongside Dakar, which is impossible with current Dakar code.
It seems to me this is a feature loss from Cairo to Dakar, which should of course be avoided.
After fixing this :
-
getViewUrl
old behaviour has to be restored
- the bin/ and lib/ directories have to go through a simple Perl substitution command, in order to use this (re-introduced) configuration variable
- some topics in data/, such as the various WebRss.txt, should be adapted to use
$dispViewPath
instead of hardcoding view
- Item911 has to be considered, since it's heavily related
-- BenVoui
This feature should be restored, too many sites are not able to upgrade if not.
Going forward, existing features should not be removed without discussing in
Codev and passing the "Peter test".
--
PTh
Peter, if every feature had to wait for a go/no go from you, then nothing would ever get done. However, adequately documented and tested features don't need to fear removal, as it should be obvious to the developer what breaks if they are removed.
I removed undocumented bad hacks like this one specifically to trigger bug reports, so we could work out what they were supposed to do. I had to take this extreme measure as my requests for information about existing features on Codev were being consistently ignored at the time.
OK, I got that off my chest. I accept that this is a bug. However, Ben, the $dispViewPath hack is a hack, and breaks in so many special cases it makes me weep.
I propose that we do it properly, take a more structured approach, and allow overrides of default URL path on a script-by-script basis. So we allow the definition of:
$TWiki:cfg{ScriptUrlPaths}{view} = 'full short URL path';
in
LocalSite.cfg (this would have to be entered manually using a text editor, but I think that's no big deal). This would allow the script path to be overridden for any named script. Now, to map the URLs in templates would require a
TWikiVariable that constructs urls - something I have considered previously, but never executed on. This would work as follows:
%SCRIPTURL{'view'}%/web/topic instead of %SCRIPTURL%/view%SCRIPTSUFFIX%/web/topic
it would take care of the details of the construction of the URL, including the lookup of the shorter URL for the specific script.
Note that %SCRIPTNAME% will still not work with shorter URLs (it was already broken in Cairo).
CC
Ben - what do you think? Would you like to try implementing this?
--
MC
Crawford on IRC said he has uncommitted code for this. You might want to ask him for it.
--
MC
CC - Great idea !
MC - Sorry, I won't be able to do so before a long time, I fear.
-- BenVoui
As Martin says, I have code that implements this already. SVN 7429
CC
Great, tested, seems to roughly work. Some new bugs are arriving about the details still to fix in this domain.
-- BenVoui