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: resource type="org.apache.struts.i18n.FileSystemResource" name="STATIC_CONTENT" property name="fileBase"/usr/local/content/static/property /resource resource type="org.apache.struts.i18n.DatabaseResource" name="DB_CONTENT" !-- possibly specify a bunch of database related properties such as username and password, or tie it into data sources specified in struts-config.xml. There would also be something specified to where exactly in the data source to pull the content from, this is way up in the air right now -- /resource 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" % h3This is static internationalized content:/h3 i18n:resource key="my.content" name="STATIC_CONTENT" / h3This is internationalized content pulled from a database:/h3 i18n:resource key="my.article" name="DB_CONTENT" / 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. Resource.java Name: Resource.java Resource.javaType: JAVA File (application/x-unknown-content-type-java_auto_file) Encoding: quoted-printable
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
"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 bean:message 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
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
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
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
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
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.
