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 <[EMAIL PROTECTED]> wrote: > 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 this > 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 together. > - Adding icons and so on can easily be achieved by adding a new class (like > LocalizedDescription...) > - I'll add a proposal for using localized messages for logging as I've used > 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 switch > 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 will > 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 it > here. I've worked with digester in the past but it's just too complex and > xml-im-exporter is just kicking-ass... > > Warmest regards, > Daniel > > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im > Auftrag von James Mitchell > Gesendet: Mittwoch, 6. Oktober 2004 15:17 > An: Jakarta Commons Developers List > Betreff: [i18n] Did I miss something? > > Wow, how did I miss this? I wonder what we can do with this and > commons-resources and/or Apache Struts. > > 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. > > 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 (this > would probably go under Apache Struts contrib). > > 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) > > 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) > > c) The types of LocalizedMessages or LocalizedExceptions I can use are the > following: > - System error > - Error > - Warning > - Alert > - Flag > - Info > > d) I would like to add an entry like: > <entry key="small-icon">/images/some-icon-small.jpg</entry> > (also one for large-icon) > > e) New MessageManager impl that can assemble messages based on a config file > 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) > > 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)? > > 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)? > > Have you thought about Spring integration? > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
