Le mardi 25 janvier 2005 � 21:52 +0100, Erik Bruchez a �crit :
Jos Vos wrote:
Hi,
When I step through the pages in my application, I always (except for the first page) see the page URI of the *previous* page in my browser's location field. This looks very strange...
This is when I use <config instance-passing="forward"> in my page-flow.xml, to get rid of the long URI's (see a previous thread). When I omit this attribute, the base URI's are correct and not one page behind, except that the long URI's (containing the whole form) are back then... :-(
Yes, because in order to allow the page flow to make a dynamic decision as to what the next page is, forms are submitted with the URL of the current page. This works well from a URI perspective when you do redirects, but with server-side forwards you get that lag (because page A submitted the form, and the result is the content of page B).
One "solution" to end the confusion would be to use meaningless page names. Other frameworks exhibit a similar behavior, like the JSF RI, last time I checked.
I don't like this kind of behaviour that much. To me, an URL is something you can bookmark or copy/paste between browser windows and that's often not the case if you are abusing POST requests and server forwarding.
I had the same issue with the web site I am developing and for which you've already helped me a lot. Unfortunately isn't yet clean enough to share it right now but the basic principles I have followed are:
* RESTish usage of URLs (for instance, instead of using http://example.com/displayDoc?id=foo I am using http://example.com/document/foo/ and instead of using http://example.com/edit?id=foo&val=bar (or its POST equivalent) I am using http://example.com/document/foo/edit) * Usage of POST only to POST updates or creation of new documents. * Usage of client redirect in action/results.
The last point appears to require that you clean up the instance so that only information that can be matched into the regexp groups that compose your URL if you want to avoid long URI's.
The development isn't finished yet, but that seems to be working fine so far.
I agree with your approach in theory. It is good practice (TM) to use a REST approach whenever possible. This is also bookmark-friendly.
Unfortunately, if the amount of state needed to produce a given page is larger than regular URL sizes, whatever method you choose to encode / compress that state in the URL, you are stuck. This scenario happens often with certain web applications that generate a large amount of state information (filling-out a large insurance form, for example). I think there are cases where it is simply not worth making sure that all the URLs look nice. Typically, consider a wizard-style interface, where you go from screen to screen. You may not even want users to bookmark until you are done, and you probably don't care much about how your URLs look like during the process.
-Erik
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ orbeon-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/orbeon-user
