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

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

------------=_1287572087-30467-6235
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Jake,

I just tried to test what you commited, but as soon as I build, I come
into a bug affecting at least my environment: the jvm will SIGSEGV
when...

     [l10n] Generating localized templates in...
     [l10n] /home/franck/devel/workspace/BarracudaMVC/WEB-INF/tmp
$/src_xmlc/org/barracudamvc/tutorials/xmlc
     [l10n] HelloWorld4_sv.html
     [l10n] HelloWorld4_pt.html
     [l10n] HelloWorld4_fr.html
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=3D0x00007fd81b820b90, pid=3D5026, tid=3D1405648544=
21264

My JVM is OpenJDK 64-Bit Server VM (17.0-b16 mixed mode linux-amd64).

I'm going to try with another JVM and to narrow down the source of the
problem... I'll keep you informed.

Franck=20




Le vendredi 15 octobre 2010 =C3=A0 00:42 -0600, Jacob Kjome a =C3=A9crit =
:
> Hi Franck,
>=20
> See comments inline below.  Also note that I committed the changes.  Pl=
ease update
> and try things out.
>=20
> On 10/14/2010 4:43 AM, Franck Routier wrote:
> > Hi Jake,
> >=20
> > first of all thank for having done this work.
> >=20
>=20
> No problem.  I've been meaning to get this in for a while, just didn't =
have the time.
>=20
> >>
> >> So, while DOMFactory.getInstance(Class) suffices for Barracuda, it d=
oes not for
> >> XMLC.  We need the Locale as the second argument.  But that would ch=
ange the
> >> interface, which might not be so bad.  But then we'd have essentiall=
y 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 fals=
e
> > 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 wh=
at
> > exactly, but I remember my tests where not succesful)... So maybe the
> > ability to switch from xmlc to ... nothing is not that valuable. Afte=
r
> > all, xmlc in a libre/free software, so depending on it is really ok.
> >=20
>=20
> 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 framewor=
k could be
> used within Barracuda.  But, as you say, "not all Barracuda possibiliti=
es [are]
> supported [using Jivan]".
>=20
> >> 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 th=
eir 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 com=
petency: the
> >> component model.  For instance, here's how to load a Document using =
plain old XMLC...
> >>
> >>
> >>         Locale locale =3D ...;
> >>         XMLCContext context =3D XMLCContext.getContext(this.getServl=
etContext());
> >>         XMLCDeferredParsingFactory dpFactory =3D
> >>             context.getXMLCDeferredParsingFactory();
> >>         Document page =3D
> >>             dpFactory.create(new XMLCCreateOptions()
> >>                             .setXmlcClass(HelloWorld4HTML.class)
> >>                             .setUserLocale(locale)
> >>                         );
> >>
> >>
> >> Why complicate such a simple procedure behind a bunch of Barracuda s=
pecific
> >> interfaces, which cannot possibly predict the various inputs a DOM l=
oading
> >> 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, provi=
des 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 ?
> >=20
>=20
> For the most part, yes.  However, XMLC supports the following configura=
tions....
>=20
> XMLObject xmlObj =3D null;
> xmlObj =3D dpFactory.create(new XMLCCreateOptions()
>                             .setXmlcClass(getXmlcClassFromSomewhere())
>                             .setUserLocale(request.getLocale())
>                             //.setFallbackLocale(Locale.US)
>                          );
> //OR
> xmlObj =3D dpFactory.create(new XMLCCreateOptions()
>                             .setXmlcClassName(getXmlcClassNameFromSomew=
here())
>                             .setUserLocale(request.getLocale())
>                          );
> //OR
> xmlObj =3D dpFactory.create(new XMLCCreateOptions()
>                             .setDynMarkupFilePath(getDynMarkupFilePathF=
romSomewhere())
>=20
> .setDynDomFactoryClassName(XercesHTMLDomFactory.class.getName())
>                             .setUserLocale(request.getLocale())
>                          );
>=20
>=20
> 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 repar=
se 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 wel=
l 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).
>=20
> Plus, though XMLC derives the markup encoding from XMLC configuration f=
iles or the
> markup file itself, you never know if a framework might require that in=
formation
> 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.
>=20
> Interfaces methods on the DOMFactory just don't seem to make much sense=
.
> Implementations must be able to be plugged in without presuming the arg=
uments 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 deprecat=
e the old
> stuff and write new ones in parallel.
>=20
> >> 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?
> >=20
> > Does what you have done break apps that use the DOMLoader / DOMFactor=
y
> > interfaces ?
> >=20
>=20
> Nope. No breakage.
>=20
> > 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 :-)
> >=20
> > What do you think ?
> >=20
>=20
> 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.
>=20
> 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 respo=
nse object
> (along with a few other things).  I also noticed one thing lacking in X=
MLC's
> XMLCContext DOM writing, which may entail a 2.3.3 release, though nothi=
ng that
> currently affects Barracuda (nor XMLC users all that much).  Anyway, I =
left that
> stuff alone for now.
>=20
> > Franck
> >=20
>=20
> Jake
> pi=C3=A8ce jointe document texte brut (message-footer.txt)
> --
> Barracuda mailing list
> [email protected]
> http://www.ow2.org/wws/lists/projects/barracuda

--=20
Franck Routier=20
             Logo Ax=C3=A8ge
Ax=C3=A8ge
23,rue Saint-Simon
63000 Clermont-Ferrand
T=C3=A9l: +33 (0)4 63 05 95 40
Fax: +33 (0)4 73 70 65 29
Email: [email protected]







------------=_1287572087-30467-6235
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

------------=_1287572087-30467-6235--