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

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

------------=_1287121324-30467-5916
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Franck,

See comments inline below.  Also note that I committed the changes.  Please update
and try things out.

On 10/14/2010 4:43 AM, Franck Routier wrote:
> Hi Jake,
> 
> first of all thank for having done this work.
> 

No problem.  I've been meaning to get this in for a while, just didn't have the time.

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

Barracuda uses many XMLC'isms.  Trying to strip it out would be fairly difficult.
 Adding Jivan was kind of an exercise to show that another DOM framework could be
used within Barracuda.  But, as you say, "not all Barracuda possibilities [are]
supported [using Jivan]".

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

For the most part, yes.  However, XMLC supports the following configurations....

XMLObject xmlObj = null;
xmlObj = dpFactory.create(new XMLCCreateOptions()
                            .setXmlcClass(getXmlcClassFromSomewhere())
                            .setUserLocale(request.getLocale())
                            //.setFallbackLocale(Locale.US)
                         );
//OR
xmlObj = dpFactory.create(new XMLCCreateOptions()
                            .setXmlcClassName(getXmlcClassNameFromSomewhere())
                            .setUserLocale(request.getLocale())
                         );
//OR
xmlObj = dpFactory.create(new XMLCCreateOptions()
                            .setDynMarkupFilePath(getDynMarkupFilePathFromSomewhere())

.setDynDomFactoryClassName(XercesHTMLDomFactory.class.getName())
                            .setUserLocale(request.getLocale())
                         );


So, it could be a class, a class name, or a file path (a path relative to the
classpath, servlet context, if configured for it, or a configured reparse resource
directory).  Plus, there's the optional DOM Factory Class Name (an XMLC DOMFactory
as opposed to a Barracuda DOMFactory) when using dynamic loading as well as the
optional user locale and fallback locale (the latter of which can also be set in
web.xml or programmatically on the deferred parsing factory).

Plus, though XMLC derives the markup encoding from XMLC configuration files or the
markup file itself, you never know if a framework might require that information
explicitly provided to it.  The point is, you might think you have all you need
and then run into some new and cool DOM framework that accepts that one extra
argument, without which you can't utilize it's full functionality.

Interfaces methods on the DOMFactory just don't seem to make much sense.
Implementations must be able to be plugged in without presuming the arguments they
accept.  I haven't put much thought into it yet.  Hopefully it will be feasible in
a way that either preserves backward compatibility or we could deprecate the old
stuff and write new ones in parallel.

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

Nope. No breakage.

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

As I stated above, I think the DOMFactory classes need to be refactored to work
without presuming the arguments.  I don't really have a design in mind yet, just a
requirement.  If you come up with something, please let me know.

There's also some work to do on the DOMWriter (XMLC implementation) to properly
write files in the correct character set as well as set it on the response object
(along with a few other things).  I also noticed one thing lacking in XMLC's
XMLCContext DOM writing, which may entail a 2.3.3 release, though nothing that
currently affects Barracuda (nor XMLC users all that much).  Anyway, I left that
stuff alone for now.

> Franck
> 

Jake

------------=_1287121324-30467-5916
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

------------=_1287121324-30467-5916--