Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of oliver.zeigermann@gmail.com
 designates 64.233.170.206 as permitted sender)
Message-ID: <9da4f452041010233626fa1429@mail.gmail.com>
Date: Mon, 11 Oct 2004 08:36:27 +0200
From: Oliver Zeigermann <oliver.zeigermann@gmail.com>
Reply-To: oliver@zeigermann.de
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: AW: [xmlio] comparison with Digester
In-Reply-To: <E1CGbnn-0007yj-00@smtp06.web.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
References: <1097402635.9199.55.camel@pcsimon>
	 <E1CGbnn-0007yj-00@smtp06.web.de>

To me this sounds like a reasonable idea. Maybe for Digerter 2?

Simon? What do you think?

Oliver


On Sun, 10 Oct 2004 13:23:46 +0200, Daniel Florey <daniel.florey@web.de> wr=
ote:
> Hi,
>=20
> Wouldn't it be possible to create a xmlio callback-handler that invokes t=
he
> digester rule-matcher? So that we can finally get the best of the two
> approaches: Keep a very slim jar containing just the xmlio/in sax
> augmentation part and call it digester-core.jar or however and an additio=
nal
> digester-rules.jar that contains the rule-specific callback handler and
> enables all the digester add-ons?
> See my comments inline
> Regards,
>=20
> Daniel
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: commons-dev-return-60497-daniel.florey=3Dweb.de@jakarta.apache.org
> > [mailto:commons-dev-return-60497-daniel.florey=3Dweb.de@jakarta.apache.=
org]
> > Im Auftrag von Simon Kitching
> > Gesendet: Sonntag, 10. Oktober 2004 11:04
> > An: commons-dev@jakarta.apache.org
> > Betreff: [xmlio] comparison with Digester
> >
> > Hi,
> >
> > I've had a look at the new "xmlio" code in the sandbox; below is my
> > initial opinion. Note that I am a committer on Digester, and am
> > therefore totally biased....
> >
> > The "in" code that is used to parse input xml documents is really reall=
y
> > similar in concept to what Digester already does.
> >
> > The main features appear to be:
> > (a)
> > A "callback handler list" (instead of a single ContentHandler object).
> >
> > Well, this seems to me to be equivalent to the Digester concept of
> > having multiple Rule objects match a particular input element, ie
> > several distinct sections of code can all be triggered when a particula=
r
> > element is matched.
>=20
> This callbackhandler-list is very useful to temporarily add a
> logging-handler for debugging purposes.
>=20
> >
> > (b)
> > A complete path to the current element is passed to the "startElement"
> > method.
> >
> > Digester has the "getMatch" method which can be called by any rule to
> > get the path to the current element. Xmlio does provide a SimplePath
> > instance instead of a plain string to represent this path (equivalent t=
o
> > the File class wrapping a filename). However in Digester you don't
> > really need anything more complex than a string because you don't
> > normally do computations on paths anyway - you leave that up to the
> > "rule matcher" class.
>=20
> The SimplePath class is very useful if you deal with multiple namespaces.
> How is this represented in digester in a simple string?
>=20
> >
> > (c)
> > The xmlio concept of having a callback method invoked at element end
> > which passes both the element text and the element attributes is mildly
> > useful (but calling this method "startElement" is rather confusing IMO)=
.
> > It would certainly be possible to add this feature to Digester/Digester=
2
> > (though it does have a minor performance drawback). With the current
> > digester code, you can clone the attrs and push them on a (named) stack
> > in begin() and then fetch them back in body() to get the same effect.
>=20
> Working with stacks is complicated especially for Java beginners. So I'd
> like to see this ability in the core parsing jar that will make it. IMO
> simplicity in use is the main goal for the parsing core.
> I think it should be no problem to rename methods if we find better
> wordings.
>=20
> >
> >
> >
> > My initial feeling, therefore, is that I would much rather see
> > additional work put into the Digester project than having this new xmli=
o
> > project essentially recreate a subset of Digester functionality.
> >
> > The main problem with Digester, I think, is that it has nasty
> > inter-class dependencies that prevent subsets of the classes from being
> > distributed. Every Rule class depends upon the Digester class, which
> > provides "parse context". But the Digester class has factory methods fo=
r
> > all the rules - so Digester can't be distributed without including *all=
*
> > the Rule classes. Breaking this dependency is number one priority for
> > Digester2 as far as I am concerned. It isn't that hard to do; I've been
> > experimenting with various refactorings already.
> >
> > I would love to see several jar files built from the Digester2 source: =
a
> > "src" distro, a "full" jar, and a "basic" jar. The basic jar would have
> > about 8 classes, being about 4 classes of core functionality and 4 basi=
c
> > Rule classes. In this form I think the "basic" jar could be entirely
> > appropriate for use by projects such as an i18n library without
> > resorting to creating a new project. Xmlio by itself doesn't provide an=
y
> > functionality to actually instantiate objects or set properties; you
> > need to write one or more subclasses of SimpleImportHandler (similar to
> > ContentHandler), so by the time that is done I think that code based on
> > Digester and xmlio would be pretty similar in size.
> >
> > There is one other significant issue: required libraries. Digester
> > depends upon BeanUtils, mainly because it performs dynamic conversion
> > between strings and other datatypes such as int, bool, etc. For a
> > light-weight parsing library this could be a nuisance; I expect we coul=
d
> > find a way of making automatic datatype conversion (and therefore
> > BeanUtils functionality) optional though. Digester also depends upon
> > commons-logging. I did make a proposal a while ago to make logging
> > dependencies in Digester optional; the patch wasn't received with any
> > great enthusiasm at the time, but with people actually pushing for this
> > it might make it into Digester2.
>=20
> I agree that the core/basic jar should not have any dependencies.
> I look forward to find a way to bring these two together!
>=20
> >
> >
> >
> >
> > Regarding the "out" part of the xmlio libs: this is basically a
> > collection of static functions doing simple but useful xml string
> > encoding etc., and a stream class that does auto-indenting. Digester
> > certainly doesn't have anything like this. This code does feel like it
> > might be at home in "lang" or "codec"...
> >
> >
> >
> > Oliver, if there was a "digester2" project which provided a "basic" jar
> > that was pretty light-weight and had only optional dependencies on
> > commons-beanutils and on commons-logging, might you consider using that
> > in i18n (or even Slide) instead of the xmlio code? (And would you be
> > interested in helping to create digester2??).
> >
> > I'm finally going to be free of the horror that is my current job in
> > December, and plan to spend a fair chunk of January getting a Digester2
> > up and running (assuming that Craig/Robert et al are happy with that).
> > Even if xmlio goes ahead, and the i18n component uses it I will still
> > keep its features in mind when working on Digester2.
> >
> > Cheers,
> >
> > Simon
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org