On 1/25/06, Joern Nettingsmeier <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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 > 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".)
I agree that the destination page should be a parameter so the login and map URLs use the querystring for the context. (And yes, my "map" Usecase does highlight the current page for "You were here.") I think stylesheet information belongs in Lenya's base URLs because it controls everything. Lenya stylesheets do not distinguish between presentation and function. Changing the stylesheet could just change the colors, but that is less important than that it change the function to present a completely new page. http://myserver/mypub/live/index.html?lenya.usecase=login is awful. http://myserver/mypub/login is much better. http://myserver/mypub/login/returnpage.html fits your objections. http://myserver/mypub/login?return=returnpage.html satisifes everybody. The important design change is to move the function (Module name) before the data. We cannot make a decision about whether to use the path or the querystring for parameters until then. > >> 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. So you like my ideas. :) === > > 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? Yes, but it is only active when Lenya writes the URLs. Most stylesheets do not include the SessionID in their links. Even the navigation elements forget to maintain the SessionID, so browsers without Cookies will not maintain the session without much development work. The SessionID is normally only added during <map:redirect session="true">. The only place it is noticable in the "default" pub is when match="/" is redirected to "/index.html". It is unlikely to hurt you. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
