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

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

------------=_1287052998-30467-5840
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Hi Jake,

first of all thank for having done this work.

> 
> 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.
> 
Well, abstracting the DOMLoader at least give the option to swith
DOMFactory and document parser if needed. But it might well be a false
sense of "security". Until now, the only alternative has been Xmlc or
Jivan. I don't think Jivan is supported in any way (in fact the site is
down). As far as I can tell, it was suffuring from limitations anyway
and not all Barracuda possibilities were supported (cannot remeber what
exactly, but I remember my tests where not succesful)... So maybe the
ability to switch from xmlc to ... nothing is not that valuable. After
all, xmlc in a libre/free software, so depending on it is really ok.

> 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.
> 
Are there really so many possibilities ? I think document name / url and
a locale might be enought for anybody, don't you think ?

> 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?

Does what you have done break apps that use the DOMLoader / DOMFactory
interfaces ?

I not, go and check in you work. If it breaks, I'd rather find a way to
modify DOMLoader/DOMFactory to take the new locale parameter into
account, as trunk is in some way the "stable" Barracuda :-)

What do you think ?

Franck




------------=_1287052998-30467-5840
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

------------=_1287052998-30467-5840--