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.204 as permitted sender)
Message-ID: <9da4f452041006155652bbf3b3@mail.gmail.com>
Date: Thu, 7 Oct 2004 00:56:56 +0200
From: Oliver Zeigermann <oliver.zeigermann@gmail.com>
Reply-To: Oliver Zeigermann <oliver.zeigermann@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: AW: [i18n] Did I miss something?
In-Reply-To: <E1CFKYe-0001Ar-00@smtp07.web.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
References: <026e01c4abaf$241e2b80$34000a0a@auburn>
	 <E1CFKYe-0001Ar-00@smtp07.web.de>

If people really want this stuff I would be glad to create a new
sandbox component for the XML import and export stuff.

Importer is mainly SAX plus all that I ever wanted to have
additonally, i.e. have the path of the generated event, more than one
listener, element, attribute and conent data at one position where
applicable and more. Almost no overhead.

Exporter is a simple set of helpers that makes you generate valid XML
with almost zero performance overhead.

Oliver

On Thu, 7 Oct 2004 00:46:52 +0200, Daniel Florey <daniel.florey@web.de> wro=
te:
> Hi James,
> Any contributions are welcome!
> As I still don't get the site generated with maven completely (layout is
> somehow broken and javadocs are missing) this is very high on my todo...
> Maybe you can help me out?
> Would be nice to get a link from the commons page to the i18n in the
> sandbox. Do you know if someone can manage this (having commit access to
> commons)?
> - In general I like the idea to read messages from properties files as th=
is
> might be very useful to migrate existing application to i18n. Even though=
 I
> like the xml-based format more as you can see which entries belong togeth=
er.
> - Adding icons and so on can easily be achieved by adding a new class (li=
ke
> LocalizedDescription...)
> - I'll add a proposal for using localized messages for logging as I've us=
ed
> this in a project using an additional Information class. This works very
> nice and lets you map different error entries to different log messages
> (details to debug, text to info or something like that).
> - I don't know if I used logging at all but it should be no prob to switc=
h
> to log4j or commons-logging.
> - I don't like digester at all as this seems to me the most confusing and
> overdosed way to parse xml files. I talked to Oliver Zeigermann and we wi=
ll
> add xml-im-exporter to commons-sandbox as I find this the very best tool =
do
> sax-based xml-parsing. It's ultra-simple, fast and intuitive. That's why
> I've used it in many projects in the past and would be very glad to see i=
t
> here. I've worked with digester in the past but it's just too complex and
> xml-im-exporter is just kicking-ass...
>=20
> Warmest regards,
> Daniel
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: commons-dev-return-60189-daniel.florey=3Dweb.de@jakarta.apache.org
> [mailto:commons-dev-return-60189-daniel.florey=3Dweb.de@jakarta.apache.or=
g] Im
> Auftrag von James Mitchell
> Gesendet: Mittwoch, 6. Oktober 2004 15:17
> An: Jakarta Commons Developers List
> Betreff: [i18n] Did I miss something?
>=20
> Wow, how did I miss this?  I wonder what we can do with this and
> commons-resources and/or Apache Struts.
>=20
> In my current gig we are using a home grown solution in combination with
> ActionErrors/ActionMessages provided by Struts.  This project would have
> been nice to have about 8 months ago.
>=20
> My immediate needs (scratching my own itch here) would be to help provide
> greater granularity for application messaging (similar to log levels) and
> perhaps a jsp taglib or two to help take advantage of this in my apps (th=
is
> would probably go under Apache Struts contrib).
>=20
> So, with that said, I would like to volunteer to help with this project.
> Off the top of my head what I would like to do is:
> a) offer the same solution with the following alternate implementations:
>  - properties file based configuration (more on this later)
>  - RDBMS based configuration (I've already done this in commons-resources=
)
>=20
> b) Develop a Struts plug-in that will load and configure commons-i18n for=
 my
> Struts applications.
>      (I guess I could just add this as a plug-in under struts)
>=20
> c) The types of LocalizedMessages or LocalizedExceptions I can use are th=
e
> following:
>     - System error
>     - Error
>     - Warning
>     - Alert
>     - Flag
>     - Info
>=20
> d) I would like to add an entry like:
>      <entry key=3D"small-icon">/images/some-icon-small.jpg</entry>
>    (also one for large-icon)
>=20
> e) New MessageManager impl that can assemble messages based on a config f=
ile
> who's entries simply point to existing i18n'd properties file(s) keys.  (=
I
> will provide more details for this on my ShortTermPlans page
> http://wiki.apache.org/struts/ShortTermPlansForJamesMitchell)
>=20
> General questions:
> Is there any reason you did not use commons-logging?  Can we change this =
to
> commons since it will (by default) delegate to the appropriate logging
> framework (let's eat our own dogfood)?
>=20
> Any reason you are using xml-importer instead of digester?  I've read the
> docs on sf.net, but the advantages still aren't clear to me (I'm guessing=
 it
> was just a personal choice made some time ago and you just stayed with it=
).
> Can we change this to use either (or use commons-configuration)?
>=20
> Have you thought about Spring integration?
>=20
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>=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
>=20
>

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