Here's a dumb idea -- why don't we rename the view script to "aview" or just "a" (and while we're at it, rename cgi-bin to "a" also)?

Background: Quite often, I navigate to TWiki by typing a URL into the "address bar" on my browser (IE5). As I type, IE keeps "suggesting" URLs I've used before. The problem is that "edit" is before "view" in alphabetical order, so it always suggests the edit pages before the view pages, so I do one of:

• call the edit page and then go to the view page
• move to the mouse and scroll down (in a window that only displays a small number (at a time) of the large number of pages I've visited -- so navigation is difficult)
• type the entire URL, or at least up to v for view, and then consider using the mouse (or type more)

If view had an alternate name that came before edit, it would be easier.

Also, if both cgi-bin and view were changed to a, it would be that much less typing.

I will probably do both of these for WikiLearn -- I wonder if I can do the cgi-bin change by changing the script alias in httpd.conf, or by using a soft link -- I guess I'll find out.

Starting a list of things I'd probably have to change from "view" to "a"

• the perl file
• all template files currently named view
• search the code for occurrences of view -- I wonder if it's easy to make a SED script that displays a line (or a few lines) containing "view" and asks me to confirm the change?

-- RandyKramer - 07 Jul 2001

I agree, I have also thought this

-- MartinCleaver - 07 Jul 2001

I think its a good idea to change the name of the view script. I don't expect the code/template changes would be that difficult.

-- JohnTalintyre - 08 Jul 2001

Suggestion:

Rename "edit" to "modify".

Rename "view" to "display".

Background: I'm not a friend of cryptic names. A name should express exactly what it's good for; if it's named "aview", users will start to wonder what that "a" means.

-- JoachimDurchholz - 08 Jul 2001

Thanks for all the responses!

I'm not a friend of cryptic names either, but my typing fingers are sometimes willing to make exceptions. I wonder if I can make a softlink to "view" named "a" and get TWiki to work that way? (Then I'd have to think about where to change "view" to "a" and where I could leave it as is -- I'd like to always use "a" in the URLs, whether entered by me or by TWiki, so that my browser history only contains URLs with the "a" in them.)

Then I think about cgi-bin -- is that a meaningful name? Well, maybe a little more meaningful than a, but if somebody asks me what cgi-bin means, my first answer would be "the name of the directory where the Twiki Perl scripts are located" and would it be any worse if it were "a"?

(Your suggestions do solve the alphabetical order problem, but not the "carpal tunnel" problem.

(Just keeping the discussion going, maybe there are some other suggestions?)

-- RandyKramer - 08 Jul 2001

cgi-bin sounds meaningful to me. But: who does really care, that your wiki pages are implemented as CGI scripts using the package of the day? Shouldn't you rather hide this implementation detail from your URL?

If you send around wiki URLs, wouldn't it be much cooler to have: https://twiki.org/Codev/RenameViewToAview instead of https://twiki.org/cgi-bin/view/Codev/RenameViewToAview or - even worse - https://twiki.org/cgi-bin/a/Codev/RenameViewToAview ?

For that to work, the view URLs have to be coded different from all the others. Or you make all links relative as mentioned in WhyBaseTag.

-- PeterKlausner - 09 Jul 2001

How about https://twiki.org/Codev/RenameViewToAview/view ?

Ie. have the view at the end. PidgeonCatPidgeon.

Even: or https://codev.twiki.org/RenameViewToAview/view

(Although I wouldn't support that because in my opinion not allowing Webs to be notated with WikiWords means that Wiki is semantically unorthoganol. Hey ho.)

-- MartinCleaver - 10 Jul 2001

"If you send around wiki URLs, wouldn't it be much cooler to have: https://twiki.org/Codev/RenameViewToAview"

Yes! or

"https://twiki.org/Codev/RenameViewToAview/view"

I tried reading WhyBaseTag, but it's just not sinking in right now. I'll try again later.

-- RandyKramer - 10 Jul 2001

I don't think that changing the order of script name and topic name is going to help. You'll have to specify both before you can fire off the stuff.

Here's a different idea: Use

   https://twiki.org/Codev/RenameViewToAview

i.e. store a rendered HTML version of every topic (see PageCaching). Edit/diff/whatever URLs look like

   https://twiki.org/cgi-bin/edit/Codev/RenameViewToAview

as before, but these aren't usually the first thing that you want to see when typing a URL in the Address bar.

-- JoachimDurchholz - 11 Jul 2001

"You'll have to specify both before you can fire off the stuff." - although this is true that is not a problem as long as the browser suggests the options to you. (IE does)

-- MartinCleaver - 11 Jul 2001

Joachim: Actually, I think changing the order will help -- once my browser's address history buffer is cleared out, "view" will be the last part of the URL and thus the last thing sorted on. As I type "https://twiki.org/C" for example, the stuff displayed on the address line history is probably all Codev stuff, or very quickly becomes so as I type "...o...d...e...v", and then if I type "...R..e", I'm probably very close to having specified the exact page I want. If at that point a few pages are specified, or I have to select between .../view, .../edit, and .../preview, that's not a big deal.

Nevertheless, the approach entirely without "view" is nicer.

A "PageCaching" approach for the view seems fine also (as long as it's a feature of TWiki, not something I have to try to implement). It sounds like it should only be a partial page cache to allow for templates.

Martin: Just to make sure we're both talking about the same thing, when you mention the browser suggesting the options to you, you mean in the address history buffer, right? (Or am I missing something?)

If that's what you mean, Konqueror has the same basic feature, although they don't seem to specify the previous pages visited in alphabetical order, but it does narrow the choice of pages as you type more into the address.

I just tried Netscape Navigator 3.04 (I use it as my mail client) -- it doesn't have this feature, but I would think most modern browsers would have the feature.

-- RandyKramer - 11 Jul 2001

Randy: Yup, that's what I mean.

I agree that if we left out view then view should be the default.

I think page caching is a valid point but is complex relative to just altering the URLs. As such we might want to implement the URL change quite soon but page caching less soon.

-- MartinCleaver - 11 Jul 2001

Keep in mind that the script name must be the first in the URL, then followed by the parameters of the script, i.e. topic-name and parameter e.g. for the skin used. You could do some tricks with server configuration, but a script called with parameters is always necessary. Therefore it is really difficult to work with defaults for the script name.

From my point of view the above ideas increase the complexity of TWiki, increase the complexity of the server setup and remove backward compatibility for stored links (Favorites in MS-speak).

TWiki should not depend on some browser features which would probably change. Type in of the URL in the address line is done by a minority of users, most of the users simply follow the links or use Bookmarks/Favorites.

Probably a PlugIn could insert JavaScript code in the page and will allow to access the topic list with a mechanism similar to the ^R of bash at the browser.

-- HubertWeikert - 11 Jul 2001

Re script name must be first in URL: A URL like https://twiki.org/Codev/RenameViewToAview is not a script URL, that's correct, but if that's already the URL of a rendered TWiki topic this is not a problem.

Re increases complexity: That's correct, but PageCaching is already in the works, and if that's in place it should be simple (require little complexity) to adapt the URLs for viewing.
I agree that it would be overkill to add PageCaching just to get rid of the URL.
Besides, the complexity argument could be held against the vast majority of changes underway. I'm pretty sure that the core developers will say No if they feel that they can't keep it under control.

Re TWiki should not depend on browser features: These features aren't likely to change since they are genuinely useful. Besides, people are going to use the current version of IE for a while to come, and it's a Good Thing to increase the usability of TWiki if it doesn't compromise other things.

Re PlugIn: No JavaScript if it can be done without it. See GetRidOfJavaScript.

-- JoachimDurchholz - 12 Jul 2001

PageCaching makes no sense if you use skins. You need a unique URL for the topic with the skin. There are already several skins in use, e.g. print
https://twiki.org/Codev/RenameViewToAview_print could be a cachable name for this, but this solution does not fit with the intention of this topic.

Complexity. Presently we only have one complex object to cope with: TWiki. Above mentioned ideas require a special server setup, out of control of TWiki developers.

-- HubertWeikert - 12 Jul 2001

I have also been looking for ways to simplify the URLs for easier emailing and such. Since view is the address to be sending around, that's the one I was looking to optimize. In Apache:

ScriptAlias /view/ "/home/httpd/twiki/bin/view/"

Then the url is https://twiki.org/view/Codev/RenameViewToAview.

My original idea was to do:

ScriptAlias / "/home/httpd/twiki/bin/"

This would result in URLs looking like https://twiki.org/Codev/RenameViewToAview. I found that this almost worked--except that images wouldn't display. It seemed to me that Apache was trying to treat any url as a script and, of course, images aren't.

-- MikeBarton - 17 Jul 2001

That's a help, and I can make it ScriptAlias /a/ ... to address both my concerns. I'll have to try this -- a nice simple fix / workaround -- thanks!

-- RandyKramer - 18 Jul 2001

How about instead:

ScriptAlias / "/home/httpd/twiki/bin/"

and

ScriptAlias /pub "/home/httpd/twiki/pub/"

etc.

-- MartinCleaver - 18 Jul 2001

Tried both approaches, I need to put a little more thought / effort into each of them.

The /a/ approach worked fine "out-of-the-box" in a view - edit - preview - view cycle and in a search. An issue remains in that TWiki still looks up pages using .../twiki/bin/... instead of .../a/... which means my browser's history contains some of both -- I probably can't depend on being able to find all pages I'm looking for under the .../a/... portion of the browser's history. Maybe with some thought, especially in the direction of the problems with the second approach (Martin's), it might be fine.

The second approach started out working OK, but when I went to edit I ran into a problem -- when TWiki tried to edit page http://192.168.0.8/twiki/bin/edit/TWiki/TWikiInstallationNotes.Reminder, it returned "WikiLearn Error: This web does not exist ERROR The web you specified does not exist."

This was probably addressed in Martin's "etc.", which I will have to spend a little more time interpreting.

-- RandyKramer - 18 Jul 2001

Thought I'd paste in the relevant lines (I think) from my httpd.conf file, twice -- once as modified per the first suggestion (which works, but could use some tweaking), then as modified for the second suggestion (which doesn't quite work). If anybody can tell me what I need to change, that would be helpful.

httpd.conf modified to use /a/ in view URL

Questions:

• Not sure why the URLs for edit, preview, and view of the form: http://localhost/twiki/bin/edit/Codev/RenameViewToAview still work, since I commented out the ScriptAlias for /twiki/bin/? Maybe the Alias does it? (But then I guess I don't know what the difference between a ScriptAlias and an Alias is, or why we need the ScriptAlias in the first place?)

• Would like TWiki (itself) to call view as .../a/... instead of .../twiki/bin/view/... . I'll be playing with the templates in the next several days, so I may figure this one out.

# Introductory comments deleted for posting on TWiki
# ScriptAlias /twiki/bin/ "/home/httpd/twiki/bin/"

ScriptAlias /a/ "/home/httpd/twiki/bin/view/" 

Alias /twiki/ "/home/httpd/twiki/"

<Directory "/home/httpd/twiki">
Order Deny,Allow
Deny from all
</Directory>

<Directory "/home/httpd/twiki/bin">
Options +ExecCGI
SetHandler cgi-script
# To enable access control based on .htaccess
AllowOverride All 
Allow from all
</Directory>

<Directory "/home/httpd/twiki/pub">
Options FollowSymLinks +Includes
AllowOverride None
Allow from all
</Directory>

httpd.conf attempted modification to use / in view URL

Questions:

• URLs for edit, preview, and view of the form: http://localhost/twiki/bin/edit/Codev/RenameViewToAview no longer work, so, for example, editing cannot be done. (Martin's "etc." may be the key.

# Introductory comments deleted for posting on TWiki
# ScriptAlias /twiki/bin/ "/home/httpd/twiki/bin/"

ScriptAlias / "/home/httpd/twiki/bin/view/" 
ScriptAlias /pub "/home/httpd/twiki/pub/" 
# Add unknown "etc." ???


Alias /twiki/ "/home/httpd/twiki/"

<Directory "/home/httpd/twiki">
Order Deny,Allow
Deny from all
</Directory>

<Directory "/home/httpd/twiki/bin">
Options +ExecCGI
SetHandler cgi-script
# To enable access control based on .htaccess
AllowOverride All 
Allow from all
</Directory>

<Directory "/home/httpd/twiki/pub">
Options FollowSymLinks +Includes
AllowOverride None
Allow from all
</Directory>

-- RandyKramer - 19 Jul 2001

The etc you are missing is that for every script except view you need an alias. Hence, you need:

ScriptAlias / "/home/httpd/twiki/bin/view/" 
ScriptAlias /edit "/home/httpd/twiki/bin/edit" 
ScriptAlias /preview "/home/httpd/twiki/bin/preview" 

ScriptAlias /pub "/home/httpd/twiki/pub/" # Actually, I am not sure you need this at all.

Now the interesting thing is that "pub" and the script names now live in the same namespace as the names of the webs. Unless the webs can never start with a lowercase letter this is not a problem. If they can start with a lower case letter it would be safer to alias the scripts such that they start with a character that a web will never start with.

Hence, for the other scripts it might be sensible to have the aliases such as:

ScriptAlias /_edit "/home/httpd/twiki/bin/edit" 
ScriptAlias /_preview "/home/httpd/twiki/bin/preview" 

Assuming that webs will never start with an "_".

-- MartinCleaver - 20 Jul 2001

Martin,

Wonderful! Thank you!

I'll try this later today (I hope).

I'm back ...

No luck -- it doesn't immediately work. I'll spend some time on the templates and maybe the light will dawn.

Hmm, Martin -- your server is on Windows? Mine is on Linux -- I wonder if that makes a difference?

-- RandyKramer - 20 Jul 2001

What I have said so far is just speculative. I've never tried it. What problems are you having?

-- MartinCleaver - 22 Jul 2001

Martin,

I wrote a long story, then tried something else -- you may want to skip ahead to the paragraph that starts with "Oops, wait, I just tried something else".

Some notes:

(Aside: Although I'd like to get this working on my home TWiki, and try to make it work for SourceForge, I suspect I will have a long row to hoe getting SourceForge to make any necessary changes in their httpd.conf file.)

• Calling a page using http://192.168.0.8/Wikilearn/ToDos works fine.

• If I click edit on that page, it calls http://192.168.0.8/twiki/bin/edit/Wikilearn/ToDos, and I get "WikiLearn Error: This web does not existERROR The web you specified does not exist." (I've done a little experimenting with the %SCRIPTURLPATH% that is partially described below.)

• I've tried calling edit with various combinations (just to find one that works), like:
  • http://192.168.0.8/edit/Wikilearn/ToDos (same result)

• Because I expect that view will be called using .../twiki/bin/view/... at times, I've tried calling view with various combinations, like:
  • http://192.168.0.8/twiki/bin/view/Wikilearn/ToDos (same result as edit calls, web does not exist)

• I've tried experimenting in the ScriptAlias for edit by rearranging the "/"s in different combinations (more relevant to edit than view). I won't list them here but I tried things like "/edit", "/edit/", "edit/", and "edit"; with and without a trailing "/" on the path.

• I also tried some, but not all, of the above in combination with variations on the %SCRIPTURLPATH>.

• At times (but unfortunately I no longer remember which times) I seemed to be getting a little closer -- I got a slightly different message than "this web does not exist" (but, again, I don't remember what it was).

To summarize so far, I guess I'm trying to let you know I tried a fair number of variations, but it was pretty much a clueless attempt -- I didn't know what I was doing, so I didn't know when I was getting close, or how to get any closer.

One more thing. I suspect even if we got this to work to the extent that I could call pages using / for view, and, for example /edit for edit, we would also have to make /view work for view, because TWiki, after a preview, will "automatically" call a view, and I believe it uses a call something like http://192.168.0.8/%SCRIPTURLPATH%/view/Web/WikiPage (which is similar to the way it calls edit). (Or, I would have to make appropriate changes to the Perl code.)

No problem if you don't want to take time to work on this -- the .../a/... method of calling is almost as good and a big help, but has the same pitfall that (AFAIK) I must convince SourceForge to change their httpd.conf file. (Luckily, that approach does not prevent calls like .../twiki/bin/edit/... from working.)

Oops, wait, I just tried something else -- if I use these two lines:

ScriptAlias /twiki/bin/ "/home/httpd/twiki/bin/" # The original ScriptAlias
ScriptAlias / "/home/httpd/twiki/bin/view/" # Martin's main suggested addition

Things work reasonably well -- I can call the view like http://192.168.0.8/Web/WikiPage or http://192.168.0.8/twiki/bin/view/Web/WikiPage, and the edit, preview, save cycle works OK without changing the %SCRIPTURLPATH%. This is probably as good as I'm going to get this for the time being, so I'll leave it at this (unless someone has another suggestion).

As I stated somewhere above, it would be nice if all the calls to view, both the ones I make and the ones TWiki makes after a save or search, used the form without the %SCRIPTURLPATH% and "view", just so that the browser history of calls to view were all in one place, but, this is a significant improvement (if I can convince SourceForge to support it).

Thanks!

PS: I just changed "/twiki/bin/" to "/w/" in the script alias and changed the %SCRIPTURLPATH% from "/twiki/bin" to "/w", so all my local TWiki URLs are that much shorter. (Still two different calls to view, though.)

PPS: Oops, just came back again -- just noticed that some of the images from the templates are not displaying. Would swear they were there when I first tested. Hopefully I just have to tweak %PUBURLPATH% or something like that.

PPPS: I'm gonna hang it up for now -- making no progress. If you read an earlier version of this last note, I incorrectly referred to %SCRIPTSUFFIX% instead of %SCRIPTURLPATH%. I've fixed that now, and I never had made any changes to %SCRIPTSUFFIX%, only to %SCRIPTURLPATH%. I now have a page on my local twiki that displays many of the relevant variables (like %SCRIPTURLPATH%, %PUBURLPATH%, etc.) so that I can see how they change as I make other changes.

PPPPS: There must be some caching related things that I don't understand. I switched back to the configuration that worked for .../a/..., restarted Apache, etc., and this time the logos didn't work in that approach. Did some fooling around, switched to the original configuration, did some fooling around, and got the logos to appear. Then switched to the .../a/... approach, restarted Apache, blah, blah, blah, and the logos worked with the .../a/... approach. There wasn't much opportunity for a typo, because I just need to comment and uncomment some lines in httpd.conf to make the changes. It seems like it just doesn't want to react immediately when I make changes. I'm becoming more and more content with the .../a/... approach!

-- RandyKramer - 23 Jul 2001

You're obviously not on SourceForge, so the following may or may not apply to your situation.
SourceForge does not serve the WWW page from the machines where the developers log in. It just silently copies the contents of the http directories from one machine to the other (in both directions, this is why TWiki works at all since otherwise the user edits would just live on the WWW machine and never be visible to the developer). If the copying daemon is overloaded, it can take up to a minute until the changes have arrived on the WWW server (or that's what I experienced, and it was one of the reasons why I gave up on SF - it was one of the things that made setting up TWiki on SF immensely frustrating because you never knew whether the latest configuration change was really in the system or not, there was no feedback on the copying status).

-- JoachimDurchholz - 25 Jul 2001

Joachim,

Thanks! You're right, the Twiki I'm discussing above is on my home LAN, but I plan to put WikiLearn on SourceForge, so the information is helpful.

-- RandyKramer - 25 Jul 2001

Randy. Gosh you've tried so many combinations now you have confused me as to what your setup is.

Please re-embed your config so I can have a look. M.

-- MartinCleaver - 25 Jul 2001

Martin,

Sorry this took so long. Here's the configuration I tried again this morning, and, this morning, it's working fine. However, last time it seemed that this configuration worked fine for a while, and then the images (logos) in pub stopped being found.

So, I'll try it this way for a while, and let you know if the problem recurs.

(I was going to try to refactor this entire topic, but I'll wait at least a few days to see how this pans out.)

This trial setup handles URLs of the form http://192.168.0.8/Codev/RenameViewToAview, http://192.168.0.8/w/view/Codev/RenameViewToAview, and http://192.168.0.8/w/edit/Codev/RenameViewToAview (the last two after changing /cgi-bin to "/w" in the TWiki.cfg file, and as long as I enter them in the "Location" window of my browser).

Here is an excerpt from my httpd.conf, followed by an excerpt from TWiki.cfg. I am using the 20010315 beta.

# Original setup (with %SCRIPTSUFFIX% set to "/twiki/bin")
# ScriptAlias /twiki/bin/ "/home/httpd/twiki/bin/"

# Trial setup
ScriptAlias /w/ "/home/httpd/twiki/bin/"
ScriptAlias / "/home/httpd/twiki/bin/view/"

# Martin Cleaver's original suggestion
# ScriptAlias / "/home/httpd/twiki/bin/view/" 
# ScriptAlias /edit "/home/httpd/twiki/bin/edit" 
# ScriptAlias /preview "/home/httpd/twiki/bin/preview"

# Martin wasn't sure about:
# ScriptAlias /pub "/home/httpd/twiki/pub/" 

# Setup to use .../a/...
# ScriptAlias /a/ "/home/httpd/twiki/bin/view/" 

Alias /twiki/ "/home/httpd/twiki/"

<Directory "/home/httpd/twiki">
Order Deny,Allow
Deny from all
</Directory>

<Directory "/home/httpd/twiki/bin">
Options +ExecCGI
SetHandler cgi-script
# To enable access control based on .htaccess:
AllowOverride All 
Allow from all
</Directory>

<Directory "/home/httpd/twiki/pub">
Options FollowSymLinks +Includes
AllowOverride None
Allow from all
</Directory>

Here is an excerpt from TWiki.cfg: (The comments that start "was" are reminders to me of the original setting of things I tried tweaking.)

# variables that need to be changed when installing on a new server:
# ==================================================================
#                   %WIKIHOMEURL% : link of TWiki icon in upper left corner :
$wikiHomeUrl      = "http://192.168.0.8/twiki";
#                   Host of TWiki URL :    (Example "http://myhost.com:123")
$defaultUrlHost   = "http://192.168.0.8";
#                   %SCRIPTURLPATH% : cgi-bin path of TWiki URL:
$scriptUrlPath    = "/w"; 
# was "/twiki/bin"
#                   %PUBURLPATH% : Public data path of TWiki URL (root of attachments) :
$pubUrlPath       = "/twiki/pub";
# was "/twiki/pub"
#                   Public data directory, must match $pubUrlPath :
$pubDir           = "/home/httpd/twiki/pub";
# was "/home/httpd/twiki/pub"
#                   Template directory :
$templateDir      = "/home/httpd/twiki/templates";
#                   Data (topic files) root directory :
$dataDir          = "/home/httpd/twiki/data";

-- RandyKramer - 30 Jul 2001

Martin (or anyone else),

I rebooted my Linux box, and the problem is back. I am creating a new page, RenameViewToAviewWorking, to attempt to deal with the problem. I will post some relevant portions of this page (primarily the excerpts from the preceding two files, the current problem, and other things that might (or might not) be relevant.

Partly it is an intent to start over with a "clean sheet of paper" and assemble all the relevant clues in a less cumbersome form.

-- RandyKramer - 02 Aug 2001

See also CommonFrontEndCgiScript for a proposal on how this could affect future versions of TWiki.

-- MartinCleaver - 02 Jul 2002