> we also have to think about how the Chiba deployment is influenced by
> new adapters/context implementations as well as custom actions,
> submissionhandlers and other extensions that do not belong directly to
> the core of the xforms implementation.
I have being thinking about a related issue since the first time I tried
Chiba: XForms was designed to be a client-side technology, so when designing
a server-side solution we may be unadvertedly introducing changes
incompatible with W3C Recommendation.
I still did not take the time to think about it, but I feel that behind
this server-side solution we have two distinct parts: a client-side
emulation system to provide current browsers the means to display the forms
and a true server-side system to process requests.
What I wonder is if this second part actually exists, i.e., if every
browser in the world is already supporting XForms there will be any need for
Chiba - as we know it today? If this is the case, I believe these two parts
should be very clearly separated and independent in Chiba architecture. For
instance, with browser-side processing it's possible to rely on the URI
resolvers? A clear separation of concerns in the achitecture may ease the
understanding of such issues.
> i wouldn't like to clutter the chiba package structure with new
> extensions on the long run. on the other hand it also generates extra
> effort to maintain optional packages and also sometimes seems like
> overhead to deploy a handful of classes in a separate download. this
> also challenges the consistency between these different distribution
> packages.
We need to have mature extension features if we don't want to bother
users having them to change their homegrown extensions due to critical
refactorings in Chiba's interfaces. Cocoon attacked this problem by it's
complex concept of blocks. While it sucks on some aspects, like having to
download 37.4M and using a small part of it, the idea can serve as an
inspiration to extensibility on Chiba.
Flavio
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
|
