You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Mitchell <jm...@apache.org> on 2004/10/06 16:16:55 UTC
[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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: [i18n] Did I miss something?
Posted by Oliver Zeigermann <ol...@gmail.com>.
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 <da...@web.de> 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: commons-dev-return-60189-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-60189-daniel.florey=web.de@jakarta.apache.org] 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: AW: [i18n] Did I miss something?
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 7 Oct 2004 00:46:52 +0200, Daniel Florey <da...@web.de> 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...
I would very strongly encourage you to use Digester. It's actually a
piece of cake to use - I've seldom had to spend more than a few
minutes writing any set of rules I've needed. And besides the fact
that it's already here in Commons and uses Commons Logging, it's also
in use by many other major projects at Apache, such as Tomcat and
Struts, that would be potential customers for the i18n component.
--
Martin Cooper
>
> Warmest regards,
> Daniel
>
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-60189-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-60189-daniel.florey=web.de@jakarta.apache.org] 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] Did I miss something?
Posted by James Mitchell <jm...@apache.org>.
> ----- Original Message -----
> From: "Daniel Florey" <da...@web.de>
>
>
> 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?
Yes, I'll look at it.
> 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)?
The commons sandbox has its own web page [1] that is linked to from commons
[2].
[1] http://jakarta.apache.org/commons/sandbox/
[2] http://jakarta.apache.org/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).
Sorry, I didn't mean 'for logging', I meant 'messages like logging levels'
for use in my app. Basically, as a user goes along some task like 'create
new loan', if there any system messages, I want to show those and
(optionally) return them to the screen they were just on. I categorize them
like "Alert", which will show (from a preformatted jsp include) a certain
icon and some text indicating that something happened - these are passed
along from the biz layer. This technique takes me beyond simple
ActionErrors and syntax validation.
> - I don't know if I used logging at all but it should be no prob to switch
> to log4j or commons-logging.
I'll go ahead and do it unless someone beats me to it.
> - 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...
I hope you don't mind, but I'd like to add digester capability. I can
provide a way to specify the parser in the config (defaulting to
xml-im-exporter of course). That should give us the greatest flexibility
(such as reusing with Struts' DigestingPlugin, etc)
>
> Warmest regards,
> Daniel
>
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-60189-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-60189-daniel.florey=web.de@jakarta.apache.org]
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
>
>
>
>
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [i18n] Did I miss something?
Posted by Daniel Florey <da...@web.de>.
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: commons-dev-return-60189-daniel.florey=web.de@jakarta.apache.org
[mailto:commons-dev-return-60189-daniel.florey=web.de@jakarta.apache.org] 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org