Using XMLC 2.3.2 L10n/I18n in Barracuda apps (looking for comments)

This is a multi-part message in MIME format...

------------=_1286843489-30467-5602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I've updated Barracuda (locally, not yet checked in) to take advantage of XMLC
L10n/I18n.  I've come up against one roadblock, though.  The DOMFactory interfaces
are not conducive to XMLC-based L10n.  DOMLoader contains methods that accept a
Locale.  However, DOMFactory, which does the implementation-specific work of DOM
loading, does not.  Yet, that is where the Locale is now required.

Existing Barracuda L10n gets away with this by using the XMLC class to wrap the
L10n information.  Because Barracuda's Localize Ant task generates a class per
Locale, each class points at its own distinct localized template file.  With XMLC
L10n, these L10n classes are not generated.  Instead, just one class, representing
the base template, is generated and XMLC takes the template name and derives the
localized template name based on the provided Locale (and configured fallback
locale), with ultimate fallback to the original base template.

So, while DOMFactory.getInstance(Class) suffices for Barracuda, it does not for
XMLC.  We need the Locale as the second argument.  But that would change the
interface, which might not be so bad.  But then we'd have essentially the same
interfaces for both DOMLoader and DOMFactory, which just seems wrong.

At this point, I'm not even sure it was a good idea to abstract this stuff.  After
all, each DOM loading implementation (such as XMLC and Jivan) has their own DOM
loading facilities.  And few will use the same one in the same app.  Having been
away from Barracuda for a while and coming back to it, it seems like Barracuda
tries to bite off too much rather than concentrating on its core competency: the
component model.  For instance, here's how to load a Document using plain old XMLC...


        Locale locale = ...;
        XMLCContext context = XMLCContext.getContext(this.getServletContext());
        XMLCDeferredParsingFactory dpFactory =
            context.getXMLCDeferredParsingFactory();
        Document page =
            dpFactory.create(new XMLCCreateOptions()
                            .setXmlcClass(HelloWorld4HTML.class)
                            .setUserLocale(locale)
                        );


Why complicate such a simple procedure behind a bunch of Barracuda specific
interfaces, which cannot possibly predict the various inputs a DOM loading
framework might require?  I'm of the mind that the DOM Loading stuff be deprecated
or re-engineered in a way that, while abstracting DOM loading, provides full
flexibility to meet the needs of any and all possible inputs a given framework
might require.

Thoughts?  Should I check in what I have done and use XMLC directly for the
HelloWorld4 L10n example, or should I wait for further discussion?


Jake

------------=_1286843489-30467-5602
Content-Type: text/plain; charset="UTF-8"; name="message-footer.txt"
Content-Disposition: inline; filename="message-footer.txt"
Content-Transfer-Encoding: quoted-printable

=0D
--=0D
Barracuda mailing list=0D
[email protected]=0D
http://www.ow2.org/wws/lists/projects/barracuda=0D

------------=_1286843489-30467-5602--