[EMAIL PROTECTED] wrote: i wrote: >> please don't move parameters or usecase identifiers into the uri.
my wording was too general. see below for clarification. >> most search engines and robots handle uris and get params >> differently, and they know why. controls that define the looks of a >> page (as opposed to the content) should be in a GET parameter. a >> uri is a resource identifier, note the "uniform" part. :-D sticking >> presentation or session-related information into the uri is just >> abysmally wrong. > > Lenya uses parameters and usecase identifiers to create unique pages: i'm aware of that, and i don't like it. a "usecase" should mean "here's a base url" (a *resource*), do something special with it. i.e. change presentation, show me another subset of data, etc. of course there are usecases that are not related to pages and content (such as login). in that case the base url is state information (i.e. where to go back to after finishing the usecase). i don't like that either. say i have a site with login. doing it with a usecase querystring means that somebody who mirrors it gets to pull one login page for every page that has a "login" link on it. > http://myserver/mypub/live/index.html => Homepage > http://myserver/mypub/live/index.html?lenya.usecase=login => Login > page much better would be a link to "login.html?context=somepage.html" because now the content is in the url path and the usability details are in the parameters. > http://myserver/mypub/live/index.html?lenya.usecase=map => Sitemap that is really bad style imho, since the displayed output has nothing to do with index.html at all. it should be sitemap.html?context=index.html (if, say, you want to highlight the current page). > These "parameters" define distinct pages, and should be handled by > search engines and robots as such. This could be improved by > changing the URLs to: http://myserver/mypub/live/index.html => > Homepage http://myserver/mypub/login => Login page > http://myserver/mypub/map => Sitemap > > How is this bad? this is good, sorry for being imprecise (it was late after a long job yesterday). as i said above, there are things currently expressed with querystring params that should be part of the base url. i was thinking of your example to add stylesheet information to the base url when i wrote my reply, and that is definitely bad imho. > The example you quoted was about using different stylesheets for one > document. One could have the full navigation. One stylesheet could > be "printable" with no navigation. One could show META information. > One could show only the Headers. Each can have a different layout > and different graphics. A visitor would consider them to be distinct > pages, so why is an important part of the URI in the querystring? well, ultimately it's a matter of taste, but i believe in strict separation of content and presentation, and since there is a "traditional" semantic difference between base urls and querystring params (the base url being the "resource" itself and the params being additional information), anything presentation-related should be kept out of the base url as much as possible so that a resource is a resource :) (of course there can't be precise rules. it's similar to accessibility in that respect, you can't validate it, you have to "get the idea".) > For the record, the "parameters" in a URL are called the > "querystring" because their first use was searching. But even the > following URLs produce distinct pages: > http://www.google.com/search?q=apache > http://www.google.com/search?q=lenya well, for highly volatile content (i.e. *queries*) querystrings are of course fine. the resource in this case is the google index. > The querystring is sent as part of the GET line of HTTP. In the old > days, websites would use an exclamation mark rather than a question > mark before their parameters just so search engines and robots would > see distinct URLs. and that's what i don't like. don't second-guess people's intention. >> imho, even the area part itself is wrong, but since the users won't >> ever see the "authoring" part, i just shrug and live with it. but >> the url kludge is definitely the least sexy part of lenya. > > Yes, that is why many sites proxy to hide the "/pubname/live". But > the "?lenya.usecase=login" is more difficult to hide. agreed. > I want to move "live" and "authoring" to Usecases, except we are > calling them "Modules" now. seconded. > I want the Module name to replace the > Area. I want the "live" Module to be the default so it is not > required in the URL. It should also be easy to configure one of the > Publications as the default so the server's homepage is a > Publication's "live" homepage without specifying either the > publication name or "live" in the URL. Would you consider these > improvements? definitely. for authoring, i don't really care about url semantics and whether stuff is in the base url or the querystring, since it's all internal anyway. but in live, urls must be clean. >> from solprovider's suggestion it's a small step to including >> session cookies in the uri. don't laugh, there are a couple >> hare-brained cm systems out there that do exactly that. > > Lenya uses > javax.servlet.http.HttpServletResponse.encodeRedirectURL(), which > puts the session id in the URL unless it has received a valid Cookie > from the browser. All good architectures have an alternative for old > or crippled client software. Disable Cookies for a Lenya site if you > want to test it. oh my god. i did not know that. it's ok for authoring, but for live, this is a horrible mistake - it's deadly for people running a recursive wget (which unless told otherwise will silently reject cookies). is this cookie mechanism active in live/ by default? regards, jörn -- "Án nýrra verka, án nútimans, hættir fortíðin að vekja áhuga." "Without new works, without the present the past will cease to be of interest." - Ásmundur Sveinsson (1893-1982) -- Jörn Nettingsmeier, EDV-Administrator Institut für Politikwissenschaft Universität Duisburg-Essen, Standort Duisburg Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
