Re: StylesheetLoader and URIResolver

chiba-028qmsAZgctBDgjK7y7TUQ@xxxxxxxxxxxxxxxx wrote:
> Hi Joern,
>
> It's an internal product that we're using as a framework for building
> websites "to order" - it uses an XML publishing concept with skinning,
> applications, auth etc, and (hopefully coming soon) easily developed forms;
> we see it as a long term project so structure and performance are important.
>
> Chiba/XForms gives us the ability to rapidly prototype and develop forms,
> primarily so that we can reduce our development cycle on custom features.
> The biggest issue so far is that although the servlet abstracts client
> interaction from the Chiba core, it doesn't abstract the delivery mechanism
> from Chiba - the expectation is that the servlet is the end-game for the
> XForm, whereas for us other processing (including styling and other XSLT or
> user interaction) is important; XForms become part of the product rather
> than being the product.  I've had to replace ServletAdapter to fit into our
> product, much like Chicoon.
yes. right. If you've serious applications where you want XForms support 
you'll likely roll your own Adapter to fit your scenario. chiba-web is 
more a starting point to see how things fit together and taking it as a 
kind of blueprint for your implementation. Though it should become more 
usefull in the future with more exciting features like AJAX-style 
processing (actually using a different Adapter for doing so). 
Nevertheless we're always interested in ideas to give it a friendlier 
and more usefull interface.
> There seem to be several sections to the servlet which could be abstracted
> as generic components for XML/XSLT style web development (eg like
> StylesheetLoader) - similar to the Apache Commons project?
This is surely the case. Much of these things will be done by the 
environment with you're e.g. using Chicoon. Here Cocoon provides all 
these rich processing features and Chiba becomes a component used in the 
pipelines along with all others.
> There's no problem in listing Chiba as a core technology (in fact, it's a
> boon because I was previously planning on masterminding a crude simile), and
> I hope we'll even contribute to it (first for consideration is form layout,
> second might be a proposal for abstracting ServletAdapter a little further).
See my latest changes in chiba-web module and tell me what you think. 
This is surely not the end of the refactoring game.
Joern

> John.
>
> -----Original Message-----
> From: Joern Turner [mailto:joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx] 
> Sent: 07 September 2005 22:59
> To: John Spackman
> Subject: Re: [Chiba-developer] StylesheetLoader and URIResolver
>
> Hello John,
>
> interesting observations - will answer these on the list but can you 
> please tell me which product you're building? We always have heavy 
> interest in knowing about people's applications.
> as you might also know the license expects you to link or mention the 
> Chiba project as source in your distribution.
> Thanks a lot,
>
> Joern
>
>
> John Spackman wrote:
>
> > Hi guys,
> >
> > We've been doing some work integrating Chiba into our product, and have
> been
>
> > looking at the StylesheetLoader class; there seems to be a bug or
> > inconsistency in the design to do with the URIResolver.
> >
> > XSLTGenerator implements URIResolver and passes itself to the
> > StylesheetLoader which then creates a TransformerFactory and tells the
> > TransformerFactory the URIResolver to use when processing includes.
> Except,
>
> > when a stylesheet is taken from the cache the TransformerFactory is not
> used
>
> > at all and therefore the implication is that the _previous_ URIResolver
> will
>
> > be used (ie the one used to cause the initial entry in the cache).
> >
> > Admittedly, this won't cause a problem unless alternative stylesheets are
> > used and that's probably pretty rare within any given application,
> > particularly as the implementation of XSLTGenerator.resolve() only
> > references straight back to the same StylesheetLoader to resolve the URL,
> > but I mention it because changes of use later down the line (eg into a
> more
>
> > generic cache, or if someone doesn't use the XSLTGenerator provided (I'm
> not
>
> > using it) ) could cause an unexpected bug.
> >
> > The answer seems to be to make StylesheetLoader implement URIResolver, so
> > that it is responsible for loading the stylesheet and all related to the
> > stylesheet whether from the cache or not.
> >
> > John
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
>
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Chiba-developer mailing list
> > Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/chiba-developer
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Chiba-developer mailing list
> Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/chiba-developer

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf