Re: i18n and Resources
> > I guess it's time for me to jump into the discussion of > > sharing tools :-) If I can I would like to share an > > introspector between struts and velocity. I have a feeling > > that the structs introspector is more complete so I > > would be all for using the struts introspector and it > > can probably be done :-) > > > > It should be feasible to share this. The needs look to be reasonably similar. > > I recently refactored this family of classes to have no dependencies on other Struts > APIs (or even on servlet APIs for that matter). Future enhancement plans include > support for PropertyEditor classes (to let apps customize the property<-->String > translations necessary when going to and from an HTML page) and bean properties that >are > Collections (treating them sort of like indexed or array-based properties), which >would > also benefit both Velocity and Struts. I think it's totally feasible. The idea of a pluggable introspector came up on the vel-dev list a couple weeks ago and that's probably a good idea and if that were done then we could probably share the introspector that's in struts. Velocity has some non-standard behavior like picking values out of Maps, but the introspector proper could probably be shared without much work. If I could get the struts introspector working in velocity maybe we could make that the first tool placed in the org.apache.util package! :-) We'll show them we can play nice ;-) jvz.
Re: i18n and Resources
Jason van Zyl wrote: > > Ted Husted (a Struts commtter) and several others are trying to put together a > > proposal for a code sharing subproject/repository/something on the GENERAL list > > right now -- this sounds like another candidate for code that could be shared once > > the infrastructure of the sharing is set up. > > I've been following it, I've just been quiet :-) > I've been following some of it, and probably spoke a little rashly in some circumstances :-). > > > Jason, does this also relate to the DbResources discussion recently on > > VELOCITY-DEV, or is that something different? > > A little different I think: that was more about velocity related > tools, or even webapp related tools, versus general tools > like a services framework or db connection pool. > OK ... just wanted to make sure we weren't missing a useful use case. > > I guess it's time for me to jump into the discussion of > sharing tools :-) If I can I would like to share an > introspector between struts and velocity. I have a feeling > that the structs introspector is more complete so I > would be all for using the struts introspector and it > can probably be done :-) > It should be feasible to share this. The needs look to be reasonably similar. I recently refactored this family of classes to have no dependencies on other Struts APIs (or even on servlet APIs for that matter). Future enhancement plans include support for PropertyEditor classes (to let apps customize the property<-->String translations necessary when going to and from an HTML page) and bean properties that are Collections (treating them sort of like indexed or array-based properties), which would also benefit both Velocity and Struts. > > jvz. Craig
RE: i18n and Resources
On Mon, 19 Feb 2001, Schachter, Michael wrote: > Jason, > > I don't see why not, the general idea is the same. Maybe there should be an > org.apache.services package and a separate repository for this sort of > thing? The kind of thing where Turbine and Struts committers can both > participate? There's a discussion on the general list about general tools and frameworks. I guess we should jump in there as there is a discussion in progress! > If there was collaboration, I'd prefer it not to be Struts or Turbine based. > A framework where the community at large decides on how the interface > methods are declared would be a powerful thing, and shouldn't be interfered > with because different design methodologies for web applications cause > different projects to exist. I mean, this is open source. There's a services framework in Avalon and there is one in Turbine. I'm all for melding them into a single framework. There's probably good things about both of them, I am only familiar with the Turbine service framework, but I will be looking at the Avalon way soon! jvz.
Re: i18n and Resources
> Ted Husted (a Struts commtter) and several others are trying to put together a > proposal for a code sharing subproject/repository/something on the GENERAL list > right now -- this sounds like another candidate for code that could be shared once > the infrastructure of the sharing is set up. I've been following it, I've just been quiet :-) > Jason, does this also relate to the DbResources discussion recently on > VELOCITY-DEV, or is that something different? A little different I think: that was more about velocity related tools, or even webapp related tools, versus general tools like a services framework or db connection pool. I guess it's time for me to jump into the discussion of sharing tools :-) If I can I would like to share an introspector between struts and velocity. I have a feeling that the structs introspector is more complete so I would be all for using the struts introspector and it can probably be done :-) jvz.
RE: i18n and Resources
Jason, I don't see why not, the general idea is the same. Maybe there should be an org.apache.services package and a separate repository for this sort of thing? The kind of thing where Turbine and Struts committers can both participate? If there was collaboration, I'd prefer it not to be Struts or Turbine based. A framework where the community at large decides on how the interface methods are declared would be a powerful thing, and shouldn't be interfered with because different design methodologies for web applications cause different projects to exist. I mean, this is open source. -Original Message- From: Jason van Zyl To: '[EMAIL PROTECTED] ' Sent: 2/19/01 7:21 PM Subject: RE: i18n and Resources > I hate the fact that the word "service" is so overused, but in this context > it would be an implementation of an interface residing at the request scope > of an application. > > I'm still pushing for a lightweight, application level service framework > within Struts, I'm just working on a proof of concept and some real code > before I go and introduce anything, probably not a great move community-wise > on my part. > > For people unfamiliar with the service framework I'm talking about, > basically it's a set of standard interfaces for common application > functionality such as localization, device detection, object pooling, etc. > The most common functionality would be included with implementations with > Struts, more time-intensive implementations could hopefully be represented > as a set of plugins/adapters for commercial vendor products that provide > that functionality. There is already a functional services framework in Turbine, is there anyway we could work together on this? jvz.
Re: i18n and Resources
Jason van Zyl wrote: > > I hate the fact that the word "service" is so overused, but in this context > > it would be an implementation of an interface residing at the request scope > > of an application. > > > > I'm still pushing for a lightweight, application level service framework > > within Struts, I'm just working on a proof of concept and some real code > > before I go and introduce anything, probably not a great move community-wise > > on my part. > > > > For people unfamiliar with the service framework I'm talking about, > > basically it's a set of standard interfaces for common application > > functionality such as localization, device detection, object pooling, etc. > > The most common functionality would be included with implementations with > > Struts, more time-intensive implementations could hopefully be represented > > as a set of plugins/adapters for commercial vendor products that provide > > that functionality. > > There is already a functional services framework in Turbine, is > there anyway we could work together on this? > Ted Husted (a Struts commtter) and several others are trying to put together a proposal for a code sharing subproject/repository/something on the GENERAL list right now -- this sounds like another candidate for code that could be shared once the infrastructure of the sharing is set up. Jason, does this also relate to the DbResources discussion recently on VELOCITY-DEV, or is that something different? > > jvz. Craig
RE: i18n and Resources
> I hate the fact that the word "service" is so overused, but in this context > it would be an implementation of an interface residing at the request scope > of an application. > > I'm still pushing for a lightweight, application level service framework > within Struts, I'm just working on a proof of concept and some real code > before I go and introduce anything, probably not a great move community-wise > on my part. > > For people unfamiliar with the service framework I'm talking about, > basically it's a set of standard interfaces for common application > functionality such as localization, device detection, object pooling, etc. > The most common functionality would be included with implementations with > Struts, more time-intensive implementations could hopefully be represented > as a set of plugins/adapters for commercial vendor products that provide > that functionality. There is already a functional services framework in Turbine, is there anyway we could work together on this? jvz.
RE: i18n and Resources
Craig, >> Hi, >> >> I'm attempting to develop a fuller form of internationalization for >>Struts, >> which includes retrieving content from more than something such as a >> ResourceBundle. The basic idea is that you have a Resource, which is >>an >> interface that represents anything that has internationalized content. >>It >> has a method that looks basically like this: >> >> public byte[] getData(String key, Locale locale, TimeZone timeZone); >> >> Of course, time zone is optional, it would depend on the >>implementation >> whether or not to use it. >> >It would be interesting if the existing MessageResources mechanisms (and >the > tag) could be layered on top of this abstraction in some >convenient way -- either by creating an implementation of >MessageResources or >by extending your Resource abstraction to include a getString() method. Funny thing is, the current way I'm designing this is this Resource abstraction, the manager of resources, and anything else, is actually just a part of an implementation of a Localization Service I'm developing. There probably wouldn't be too much of a problem with a MessageResources implementation using the service. I hate the fact that the word "service" is so overused, but in this context it would be an implementation of an interface residing at the request scope of an application. I'm still pushing for a lightweight, application level service framework within Struts, I'm just working on a proof of concept and some real code before I go and introduce anything, probably not a great move community-wise on my part. For people unfamiliar with the service framework I'm talking about, basically it's a set of standard interfaces for common application functionality such as localization, device detection, object pooling, etc. The most common functionality would be included with implementations with Struts, more time-intensive implementations could hopefully be represented as a set of plugins/adapters for commercial vendor products that provide that functionality. In some ways I'm looking for this LocalizationService to supercede the current MessageResources functionality. I attached the interface if anyone wants to take a look at it. With the functionality represented by the Resource interface, I'm nearly done an implementation. Whichever road the Struts community chooses to go (ie, whether or not to include this service framework), I'd like to add the resource interface and it's companions. A MessageResources implementation using this wouldn't be a big deal. LocalizationService.java
Re: i18n and Resources
"Schachter, Michael" wrote: > Hi, > > I'm attempting to develop a fuller form of internationalization for Struts, > which includes retrieving content from more than something such as a > ResourceBundle. The basic idea is that you have a Resource, which is an > interface that represents anything that has internationalized content. It > has a method that looks basically like this: > > public byte[] getData(String key, Locale locale, TimeZone timeZone); > > Of course, time zone is optional, it would depend on the implementation > whether or not to use it. > It would be interesting if the existing MessageResources mechanisms (and the tag) could be layered on top of this abstraction in some convenient way -- either by creating an implementation of MessageResources or by extending your Resource abstraction to include a getString() method. Craig
Re: i18n and Resources
Wong Kok Wai wrote: > I'm definitely interested but one question: why not use java.util.ResourceBundle as >the > base class? It helps as existing ListResourceBundle and PropertyResourceBundle can >still be > used. > Among other things, ResourceBundle and PropertyResourceBundle are not Serializable. This causes problems on several application servers that like their servlet context attributes, and not just session attributes, to be Serializable. Craig
Re: i18n and Resources
I'm definitely interested but one question: why not use java.util.ResourceBundle as the base class? It helps as existing ListResourceBundle and PropertyResourceBundle can still be used. "Schachter, Michael" wrote: > Hi, > > I'm attempting to develop a fuller form of internationalization for Struts, > which includes retrieving content from more than something such as a > ResourceBundle. The basic idea is that you have a Resource, which is an > interface that represents anything that has internationalized content. It > has a method that looks basically like this: > > public byte[] getData(String key, Locale locale, TimeZone timeZone); > > Of course, time zone is optional, it would depend on the implementation > whether or not to use it. > > You would define these resources in some xml file, like so: > > name="STATIC_CONTENT"> > /usr/local/content/static > > > name="DB_CONTENT"> > > > > Then, you would use a taglib inside of your jsp page to retrieve the > content: > > <%@ page langauge="java" %> > <%@ taglib uri="/WEB-INF/struts-i18n.tld" prefix="i18n" %> > > This is static internationalized content: > > > > This is internationalized content pulled from a database: > > > > Taking this further, you could create a resource implementation that plugs > into some kind of commercial content managment system, and so on. > > Is there any interest in something like this? I'm currently in the process > of developing this idea, and I'd like as much input as possible, not only > with this, but with internationalization in general. I attached the > Resources class, just to illustrate a bit. > > <> > > > Name: Resource.java >Resource.javaType: JAVA File >(application/x-unknown-content-type-java_auto_file) > Encoding: quoted-printable
