Wow. Now I get it. Thanks for all the help with this issue, and I am
sorry to have been asking the same question repeatedly. It is just that
chiba is the perfect web form editing solution for the situation I am
in, and I don't want to give up on using it (and the thought of being
able to contribute would be nice too). I think, given the results of
this discussion, I will concentrate on making my own modifications to
the ChibaServlet directly, and doing them in a way that is painless to
migrate from version to version as Chiba the project progresses. If I
can stretch my brain enough to see a different, more generic way to do
this and still save the two major pieces of work that require the
EnvironmentAdapter interface, then I will obviously let this list know
and try to contribute some functional code instead of just asking for
info and help. Once again, thanks for the responses and all the great
work so far.
Zach Roberts
on 11/13/2003 10:56 AM Ulrich Nicolas Lissé said the following:
hi *,
i have some more information for you ;-)
joern turner wrote:
Hello,
first, don't worry, you're on the right way... ;)
Zach Roberts wrote:
Hello Everyone,
I have been looking more at writing my own servlet to replace the
ChibaServlet, and I have reached a fair amount of success. However,
I still feel like there are some things I do not understand, and
since this is a vital part of my project I would really appreciate
any insight as to the gaps in my knowledge. Here goes my small
brain-dump:
The org.chiba.adapter.EnvironmentAdapter calls for two methods that
are not documented very well, setForwardResponse() and
setRedirectUri(). All that I can find about these methods is that
they are used during the doPost process which handles some specific
cases of the XForm spec (I think "<xforms:submission
replace='all'/>" and "<xforms:load show='replace'/>" from the code
of the ChibaServlet). These methods are in turn implemented by the
org.chiba.adapter.web.WebAdapter implementation of the
EnvironmentAdapter interface. Also, the WebAdapter stores a
ChibaServlet specifically as a private variable, and from what I can
determine this is specifically to know that these two methods exist
in the private variable chibaServlet, and it is not obvious as to me
why this has been done. This creates a dependency for the default
servlet to be a ChibaServlet instead of a regular HttpServlet. Now,
in order to write a regular HttpServlet which utilizes the
ChibaBean, it must first comply with the ChibaServlet / WebAdapter
expectations, even if there is no reason for it to do that. Also,
it must completely replace the default ChibaServlet, and cannot live
next to it. It just feels like there ought to be a better (or more
abstracted) way to use the ChibaBean from any servlet.
Now, I am no java guru, but I am getting comfortable enough to be
able to modify the EnvironmentAdapter Interface, then update the
WebAdapter implementation to remove the two unknown methods and
change the internal variable from ChibaServlet to HttpServlet.
Then, I am able to write my own servlet which mimics most of the
ChibaServlet functionality. So, I guess the ultimate question I am
asking is what am I breaking by doing it this way? What do I lose
when I get rid of those two methods from the EnvironmentAdapter
interface? And, if I am way off base in my approach, can someone
give me a simple shove in the right direction?
you analysis is quite good so far. i agree with you that the
integration of the servlet is not very good.
it always feels a bit like excuse but again this is understandable
only from the history of the project: initially the servlet was only
written to have a environment the processor lives in. so, not too
much effort was put into its design. since then, our minds are still
focussed on the core of the processor leaving some other parts of the
code in the dust.
but i appreaciate this discussion as a chance to change this situation.
as joern already pointed out, this is grown code. we started a
refactoring to clean up the servlet, and to separate the adapter logic.
unfortunately, we went only half the way while focussing on core
functionality. so, neither the servlet nor the adapter are the result of
any kind of design. any proposals on how to do it better are welcome.
but the adapter interface is a moving target, work in progress yet.
especially the two callbacks you mentioned have been thought of being
temporary, thus they are left undocumented.
ok, now i try some facts...
uli + me also discussed the removal of the setForwardResponse() and
setRedirectUri() methods. these were introduced with chicoon 0.1 and
used for it. as a new chicoon is on the way, these methods may become
obsolete, but we've to check this with Andrzej who works on chicoon.
Uli, can you comment on this? are these methods still in use for Chiba?
that's not completely true. as robert already found out, both methods
are there for some special cases in XForms processing. put shortly, a
removal of these methods will result in lack of submission and load
action functionality. these are two issues where the XForms spec is
somewhat client centric making server side processing at least
complicated ... but this is a more conceptual than technical topic.
* setRedirectUri:
this method originates from load action support. the load action
traverses a link specified either by a resource attribute or by bound
instance data. additionally, it has a show attribute capable of having
two values: 'new' and 'replace'. the behaviour defined for both values
should be intentionally clear. processing for 'new' is simply not
achievable at server side, since the server cannot open a new client
window (or: presentation context, as the spec puts it). behaviour for
'replace' can be achieved at server side by redirecting to the specified
uri after form processing has finished.
so, the load action implementation stores the uri with the adpater,
which makes it available to the chiba servlet. this is the reason why
the adapter holds a reference to the chiba servlet, since only the
servlet can perform the redirection.
* setForwardResponse:
the spec defines 3 different replace modes for submission responses. you
can have a submission with replace='none', which simply submits data and
ignores the response, if any. a submission with replace='instance'
replaces the current instance with the parsed submission response. this
is especially useful when you submit data in order to insert in a
storage backend which generates unique identifiers (e.g. rdbms). when it
comes to replace='all' things get different in a server side
environment. in '11.1 The xforms-submit Event' the spec states:
"5. The response returned from the submission is applied as follows:
- For a success response including a body, when the value of the replace
attribute on element submission is "all", the event xforms-submit-done
is dispatched, and submit processing concludes with entire containing
document being replaced with the returned body.
- ..."
therefore, chiba's submission implementation stores the response stream
in a map and makes it available to the servlet through the environment
adapter. again, you see the reason why the adapter holds a reference to
the chiba servlet. then, the chiba servlet looks for such a response map
and - if any - routes the submission response stream to the client.
we simply had no better idea how to implement load action behaviour and
how to have the submission response to be forwarded directly to the
client. i would be happy if we find a better solution not depending on
these nasty callbacks.
another issue is the interpretation of replace='all' processing. what
does "entire containing document being replaced with the returned body"
really mean in a server context ? is the returned body another document
containing XForms markup and therefore has to be loaded into the
processor ? or is it an response of arbitrary content type, e.g. pdf,
and should be routed unseen to the client ? we prefer the latter one,
but we are far from being sure about this ...
really hope things are more clear for now, uli.
as already stated i would be happy to change ChibaServlet references
to HttpServlet ones.
Joern
Thanks again for all the great work, and the help is always
appreciated.
By the way, congrats on what looks to be a good 9.3 release!
Zach Roberts
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
|
