hi adrian,
this is due to the spec, which mandates any error/exception during
submission to be propagated via xforms-submit-error. unfortunately,
there's a serious design flaw in the spec around here: the
xforms-submit-error is declared to be non-fatal. therefore, Chiba logs
the error, wraps it into an xforms-submit-error and goes on with normal
processing.
your original idea of hooking in an event handler is the intended way
for Chiba. implement a DOM event listener and register it via
Container.addEventListener with the desired event target. upon receiving
EventListener.handleEvent you might cast down the DOM event to
org.chiba.xml.xforms.events.XFormsEvent in order to access the context
info (which is the original exception in case of xforms-submit-error).
you might consider rethrowing the exception. note, that this won't have
any effect within EventListener.handleEvent, since it will be discarded
silently by Xerces (on of the reasons for Chiba's somewhhate clumsy
error handling). you'll have to store this exception somewhere and
rethrow it after exiting the event loop.
we hope the issue of handling submission errors in a more elaborated way
will be addressed in XForms 1.1.
regards, uli.
Adrian Baker wrote:
I've done some more digging and thinking on this, and I realise that the
standard container-managed error page *is* being generated, however
chiba is ignoring the response body in the AbstractHTTPConnector,
because the HTTP status code is 500.
Just to clarify, in our case the submission target is another servlet,
which goes ahead and does the *actual* submission (the idea being that
the application is unaware that we're using a server-side or client-side
xforms engine). If this submission causes a problem the doPost method
throws an exception, which results in the standard container specified
error page (<error-page> in web.xml) being generated as a response.
I'm curious, however, whether this is the best approach for the
AbstractHTTPConnector to take : surely even if the status code is 500,
the response body can still contain a useful response, and can (should?)
be used rather than being discarded as it is currently. Obviously the
xforms-submit-error event needs to be generated at some point, but
rather than throwing an exception up, perhaps this should be triggered
some other way, and the response still used, at least by default?
This might be preferable to the current (default) behaviour, where an
error response from an HTTP submit simply results in the form
(confusingly) being redisplayed without change or notification, and the
exception being logged. I'm vaguely aware that there is some way to add
handling to the form for an xforms-submit-error event (?), but
(a) this doesn't exist by default,
(b) AFAIK it doesn't seem that this handling can act on/display the
*content* of the error event, and
(c) it would still be good to somehow allow the approach of displaying
the response body from the submission target, even if the header denotes
an error status.
We can do a limited version of (c) by writing a simple extension to
HTTPSubmissionHandler which doesn't generate an exception on a 500
status - it's not ideal though because the xforms-submit-error event
won't get generated (although I'm not sure I see how the event and the
error response can *both* be used).
Adrian
-----Original Message-----
From: chiba-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
[mailto:chiba-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx] On Behalf Of
Adrian Baker
Sent: Tuesday, 18 January 2005 4:03 p.m.
To: chiba-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
Subject: [Chiba-users] propagating exceptions from xforms-submit-error
I'd like to be able to throw the exception that can result
from a submit, however I see that chiba is swallowing this
exception internally and turning it into a
xforms-submit-error event, which doesn't appear to have any
listeners by default.
If I have an application that is embedding the
ServletAdapter, is adding an event listener to the Container
the correct way to generate exceptions from these events ?
What I'm trying to avoid is the current situation where if an
exception occurs during submission, the form is simply
redisplayed and the exception written to the log : instead
I'd like the exception thrown up to the container for display.
thanks,
Adrian
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Chiba-developer mailing list
Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/chiba-developer
--
Ulrich Nicolas Lissé
-------------------------------------------------------
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
|
