Michael Jouravlev wrote:
On 8/12/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:I don't like bookmarkable urls as they are now. First, they look ugly. Second, the page is shown directly without redirection. On the contrary, I want to send a command to a page, so it would process it, and then render itself after redirect.
Ahh but this i can change.For homepages i already build in what a homepage should do (HomePage render strategy)
So if you hit a homepage ("/") you can specify what should happen
no redirect
redirect to bookmarkablePage (that is the homepage)
redirect to page (path=x)
the default is page redirect
What we could do is give a setting that says what should happen with a
bookmarkable page
no redirect redirect to page (path=x) What we could do is give the url it self that behaviour: bookmarkablePage=mypage?redirect=true What is ugly about those urls, what do you want?
If my page is not versioned ("version") nor has several instances ("path") then I do not want to see anything in the url besides base page address, I do not want to see "version" or "path".
there is no page adress, yes there is but that is path path=x is the address of that page in mem. There is no other way.
Also, I do not want to see any parameters in the url. Parameters are commands, they should be processed in the input phase, then Wicket should redirect to page and render it in its current state, parameters are not needed for that.
We just need to know what page to render in a redirect. and path=x is the thing we need to lookup the component.But i personally don't mind those urls. I like to keep them a bit clean and not so long
But i think wicket does that pretty good.
Ok, I guess I cannot get rid of "path" parameter completely, because Wicket takes a simple route to build urls and combines them from webapp context root and some params like class name or class name and instance, etc.
yes path is the thing how we lookup a instance of a page.
I would prefer that for pages which are not versioned and have only one instance, the url would be built using context root + Page name. Of course, page name should be uniqie, and I do not want to use full package+class name.So, for signIn example, non-versioned home page would look like /signin/homeand non-versioned signin page would look like /signin/login
yes but this will not work You can have multiply instances of one page in a session A DetailPage displaying object A and one displaying object B another problem with /signin/xxx instead of /signin?xxxxis that the base is suddenly changing so all relative urls or the url generation
must take that into account. So it is a big change.
If no one objects, I will give some attention to the urls, since ugly urls drive me crazy ;-)
i and i know almost all core developers of wicket really don't care. Why is that so important ? I really don't get that. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
