xforms:instance/@src resolution doesn't reuse session

> When populating an xforms:instance using the @src attribute it appears
> that if a http connection is made it doesn't reuse the current http
> session of the form.
>
> This is in contrast to http connections made with the
> <xforms:submission>element, which do reuse the http session.
>
> For example, assuming there's a servlet behind the
> 'getDocumentVersions.xml' url which relies on the session, this works:
>
>    <xforms:instance id="document-versions">
>        <versions/>
>    </xforms:instance>
>      <xforms:submission id="getDocumentVersions"
> action="/getDocumentVersions.xml" ... />
>      <xforms:send submission="getDocumentVersions"
> ev:event="xforms-ready"/>
>
> but this does not:
>
>    <xforms:instance id="document-versions" src="/getDocumentVersions.xml">
>        <versions/>
>    </xforms:instance>
>
> Previously we were happily using the former approach as a workaround
> until we ran into some serious performance problems when there were
> multiple instances being populated: each submission appears to be
> forcing a revalidate/recalculate/refresh of the entire model, making the
> form load extremely slowly.
>
> It struck me that xforms-ready probably isn't the best event for this,
> since it means the earlier initial state of the instance data gets
> unnecessarily initialized then immediately overwritten. However using
> the xforms-model-construct caused errors - obviously submissions cannot
> be fired at this stage - and xforms-model-construct-done made no
> noticeable difference to performance.
>
> Finally, noticing this line in the debugging made me wonder if the use
> of submissions were causing further hits on performance by preventing
> caching:
>    DEBUG org.orbeon.oxf.xforms.processor.XFormsServer  - XForms -
> submission occurred during XForms initialization, disabling caching of
> output.
>
> Adrian

>
>  Thanks for the reply Erik - when the cvs code has stabilized a little I
> will experiment.
>
>  I've found that as a workaround adding a dummy xxforms:username attribute
> to the <xforms:instance src="xxx> triggers the non-optimized request which
> reuses the session.
>
>  Regarding xforms-ready - do you think longer term it might be desirable to
> render the initial form state once xforms-ready is fired, before startup
> events/submissions are fired? This way a form could load quickly with empty
> sections which populate with slow-to-load-data as the user watches, rather
> than them seeing a blank screen until every piece of data is loaded.
>
>  Adrian
>
>  Erik Bruchez wrote:
> Adrian,
>
>  I think that this is a variation on this bug:
>
> http://forge.objectweb.org/tracker/index.php?func=detail&aid=305713&group_id=168&atid=350207
>
>  You would think you could hook that initialization logic upon
> xforms-model-construct-done, since all that does is doing some
> initialization related to controls.
>
>  But this wouldn't help you since revalidate/recalculate are already done
> when processing xforms-model-construct. And I don't think you can do a
> submission until xforms-model-construct has finished. So xforms-ready is
> just the best spot to do that kind of initializations, and you do know,
> after all, that the XForms engine is ready at that point ;-)
>
>  You may want to retry this method in the short-term future as a lot of the
> server-side code has changed recently. Who knows, your performance issue
> upon initialization may no longer be one.
>
>  Using instance/@src would certainly be better, but for that you will have
> to wait until the bug is fixed.
>
>  Submitting during XForms engine initialization will disable caching of the
> entire output, but this is only a concern for relatively static forms, i.e.
> if several users hit the same form and if that form is initialized with
> exactly the same data so that the output can be cached and exactly the same
> result can be served to all the users.
>
>  -Erik
>
>  Adrian Baker wrote:
>
> When populating an xforms:instance using the @src attribute it appears that
> if a http connection is made it doesn't reuse the current http session of
> the form.
>
>  This is in contrast to http connections made with the
> <xforms:submission>element, which do reuse the http session.
>
>  For example, assuming there's a servlet behind the
> 'getDocumentVersions.xml' url which relies on the session, this works:
>
>     <xforms:instance id="document-versions">
>         <versions/>
>     </xforms:instance>
>       <xforms:submission id="getDocumentVersions"
> action="/getDocumentVersions.xml" ... />
>       <xforms:send submission="getDocumentVersions"
> ev:event="xforms-ready"/>
>
>  but this does not:
>
>     <xforms:instance id="document-versions" src="/getDocumentVersions.xml">
>         <versions/>
>     </xforms:instance>
>
>  Previously we were happily using the former approach as a workaround until
> we ran into some serious performance problems when there were multiple
> instances being populated: each submission appears to be forcing a
> revalidate/recalculate/refresh of the entire model, making the form load
> extremely slowly.
>
>  It struck me that xforms-ready probably isn't the best event for this,
> since it means the earlier initial state of the instance data gets
> unnecessarily initialized then immediately overwritten. However using the
> xforms-model-construct caused errors - obviously submissions cannot be fired
> at this stage - and xforms-model-construct-done made no noticeable
> difference to performance.
>
>  Finally, noticing this line in the debugging made me wonder if the use of
> submissions were causing further hits on performance by preventing caching:
>     DEBUG org.orbeon.oxf.xforms.processor.XFormsServer  -
> XForms - submission occurred during XForms initialization, disabling caching
> of output.
>
>  Adrian
>
>
> ________________________________
>
>
> --
> You receive this message as a subscriber of the [hidden email]
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email]
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>