Bill Winspur wrote:
> Is the point of the forward attr to implement session state thru url
> rewriting (or cookies), instead of session-scope ?
> What is the scope of the copied xform docs in the hello world example,
> which does not forward ?
There is no session involved at all when forwarding. The point is just
to allow, after submission of a form, passing large amounts of data
from the submitted page to the following page.
To go from page A to page B from a user's perspective, you have the
following possibilities:
1) Put a URL for page B directly on page A. This is not always
possible when page B depends on server-side processing, for example
depending on user input on page A. For web sites, for example, it
is clearly the preferred solution though.
2) Submit page A to a certain URL, and letting the server-side decide
what page B is. Then, you have two options:
1) Send a client-side redirect to the client, who can then access
page B by loading the URL sent by the server. If you want to
pass information between page A and page B with this method, it
has to be somehow encoded in the resulting URL for page B. The
drawback is that URL length is limited, so the amount of
information you can pass this way is limited as well. This is
the mechanism you select when choosing
instance-passing="redirect".
2) Perform a "server-side redirect", or "forward", and directly
send page B to the client. This way, any amount of information
can be passed from page A to page B. The drawback is that the
browser does not show a URL identifying page B at this
point. This may or may not be important. This is the mechanism
you select when choosing instance-passing="forward".
On a related note, there are not many ways of storing data associated
with a page and recovering it when the page is submitted. You can:
1. Store it server-side, typically using a session object (which is
typically identified with an HTTP cookie or more rarely a parameter
appended to the URL. Because the client keeps an id associated with
the data stored on the server, sessions have to expire, otherwise
servers would keep using more storage for sessions. The benefit is
that you can store directly any type of server-side object. This is
where you use URL rewriting or cookies, BTW: to implement session
mechanisms.
2. Store it client-side. In this case, the data to be stored has to be
serialized as text, and stored for example into hidden form fields
or the URL. Again, the disadvantage of the URL is that their length
is limited, so the amount of data stored can only be very small. If
stored in hidden form fields, it can be submitted either as a GET
or a POST. In the first case, the URL limitation shows again. So
POST is the best solution.
With our XForms engine, the XForms instance is stored on the
client-side in hidden form fields so that it can be reconstructed
on submit. Then, the default is to use the POST method to submit
forms on that page. This way, XForms instances of any size can be
stored client-side, with the advantage of not requiring session
tricks, but the disadvantage of requiring larger HTML pages aS
XForms instances grow larger.
I hope this clarifies things a little.
>> Do you mean the mechanisms for implementing sessions?
>
> Yes, that's what I mean.
The Servlet spec seems to mandate that servers support sessions with
clients that do not support cookies, and advocates URL rewriting for
that purpose. Practically, I think all servlet containers will support
those two mechanisms at least. To support URL rewriting, you need to
call the correct API for each URL you are generating.
(BTW, with Presentation Server all URLs in HTML and XHTML are
rewritten through oxf-rewrite.xsl, but the implementation may not be
calling the Servlet API in the end (check rewriteURL() in
ServletExternalContext). This should be trivial to fix, just a matter
of calling HttpServletResponse.encodeRedirectURL() and encodeURL().)
>> This being said, it doesn't explain why your session gets cleared.
>
> Watching the console, when using the session listener, I saw that
> the second start-session event occurred when I clicked the button
> causing a page jump, not when the page carrying the button was
> initially displayed.
It means the new page is trying to create a session, probably because
it doesn't find any current session. This should not happen...
>> Have you tried a couple of browsers?
>
> Not yet - will do.
It should definitely work with Mozilla / Firefox and IE 6, the
browsers we use commonly.
-Erik
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
