Re: [s2] Is it possible to replace/supplement i18n resolution logic?
Ray Clough wrote: We did something similar to what you are suggesting. We still use properties files, but we replaced much of the lookup with our own classes. We created a wrapper around ResourceBundle which has overloaded 'getText()' methods. We make this accessible to all parts of the app with a ThreadLocal object which incorporates the current Locale, and has a 'getMessageProvider()' method. The 'MessageProvider' has the 'getText(key, args)' methods. We did this because the non-Struts modules of the app need Message Support also, and so in order to keep the Struts artifacts out of these modules, we did the extra work. The process of replacing messaging in the JSP pages was too daunting, so we still use the S2 tags to resolve those messages. Our module uses the same ResourceBundle files as the Struts module. However we created our own tag library to replace the s:text tag in some instances where the action isn't S2 (sometimes it is S1, sometimes it is JSF). I think the ideal solution would be to move all the messaging resources into a new Commons project (commons-messaging??), and to access to the messaging service as an interface abstraction. That way the choice of messaging service would be more flexible. Changing the S2 messaging system would require overriding the 'getText()' methods in the ActionSupport class, as well as changing the way that the S2 tags get their messages. That would be a pretty huge job, and would take a huge amount of refactoring of the S2 code base. However, IMHO the S2 tags are really poor, so replacing them completely with a new library would be an excellent step. What I dislike most about the S2 tags is that their syntax is confusing, and very un-jsp-like. They don't allow runtime expressions (like the jstl tags), requiring the use of s:set to create properties which are then de-referenced in the UI tags. Also the syntax for accessing OGNL is particularly incongruous. Some tags require using both a % and a # within one tag. A lot of this is the result of trying to make a tag library that is flexible enough to work in environments other than JSP, but I believe a lot of it is due to the 'hobby-like' nature of S2 (I was not involved, so this is speculation on my part). The evolution of WebWork from Struts allowed the WW developers to 'try things out', and when the project was remerged into S2, many design decisions which should have been reversed were found to be too much trouble. So the 'try things out' features remain to bedevil the S2 application architecture. The very worst feature (again IMHO) is the mandatory use of themes. The other very worst feature is the result 'type' feature which mandates that only one rendering type can be used in any one page. For example, if you are using the Tiles plugin with 'type=tiles', you can't use the jsf plugin with 'type=jsf'. This has mandated that we don't use any plugins at all. Of course, this isn't a big loss because the most of plugins are very very very ... very buggy and do not appear to be in current development, as judged by their still poor implementations. Another very worst feature is the translation of the word POJO to equal Java Bean, and means that everything has getters and setters everywhere, which makes the apps developed with it poorly encapsulated and difficult to maintain (the designers of S2 definitely did not read, or did not comprehend, or did not believe, the central theme of Why Getters and Setters are Evil). Sorry for the rant, but I do like many of the S2 features well enough that I continue to use it, and the S2 architecture is definitely better than S1 (death to ActionForm!). - Ray Clough Do you have a list of specific issues you've seen with the JSF Plugin? It'd be nice to get these documented so 1) users can be aware of them and 2) developers/contributors can fix them. Also, if you believe getters and setters are evil, what's the solution? Most of the Java web frameworks I know of today use getters and setters to read/set values. Are getters and setters evil in your Hibernate/JPA POJOs as well? Matt -- View this message in context: http://www.nabble.com/-s2--Is-it-possible-to-replace-supplement-i18n-resolution-logic--tf4214304.html#a12023507 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Is it possible to replace/supplement i18n resolution logic?
Don Brown wrote:
On 8/4/07, mraible [EMAIL PROTECTED] wrote:
With Struts 2, how would I go about doing the following:
1. Replace the i18n resolution logic to load key/value pairs from a
database
instead of properties files?
Well, if your Action class implements TextProvider (as does
ActionSupport), then you can resolve keys any way you'd like. As for
plugging/altering the existing lookup that is used by ActionSupport,
it really isn't possible right now, and I've love to see a patch
making that more flexible... *hint* *hint* :)
Does this affect s:text as well? I'm not as concerned about Java reading
i18n files as I am about JSPs.
Don Brown wrote:
2. Add an extra processing step to translate wiki syntax in values to
HTML?
You mean like creating your own template to customize the rendering of
the control? If using Freemarker, there might be a nice way to write
something like the ?html piece that processes returned values.
No, I'm looking to add an extra process step. Here's an example, using JSTL
fmt:message since I'm more familiar with it:
messages.properties:
page.message=Welcome to My Cool App *{0}*!
page.jsp:
fmt:message key=page.messagefmt:param
value=${user.firstName}//fmt:message
renders:
Welcome to My Cool App *Matt*!
I want it to render:
Welcome to My Cool App strongMatt/strong!
Thanks,
Matt
--
View this message in context:
http://www.nabble.com/-s2--Is-it-possible-to-replace-supplement-i18n-resolution-logic--tf4214304.html#a12023712
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Is it possible to replace/supplement i18n resolution logic?
Yes, getters/setters are generally 'evil', but sometimes unavoidable. Just because the get/set idiom is popular doesn't make it good. First, the term POJO originally meant Not EJB. The way people have been using it lately means Java Bean. One of the real weaknesses of Struts-1 was the ActionForm. It was really a Struts-specific TransferObject (TO), but being Struts-specific means that you shouldn't put it into your back-end processes, so you had to make another TransferObject for the back end. These two classes were just about identical which made for duplicated code, a primary Design Smell. Furthermore, since all the properties were exposed as Primitive types and Strings, they made for very fragile code, hard to maintain, etc. Now with Struts-2, they have done away with the need for the separate TO, but they just moved the requirement for all the getters/setters to the Action class itself. So now it is the Action which is fragile, difficult to maintain, etc. It is certainly vastly better than S1, but still a pretty lame architecture. But ModelDriven almost comes to the rescue. Now the Action can make an object visible to the web pages, and all the getters/setters can be on that object. So the fragility is taken out of the Action, into the model. There are some problems with ModelDriven, but it is pretty good. The problems with ModelDriven include the fact that it is on the stack, and the stack is re-created for each request, meaning that it isn't really a good repository for the data if the processing of a UseCase takes more than one request, for example creating the model is one request, modifying the model is another, redisplaying it is another, verifying the changes is another. You really have to use some hack with the session to make this useable. Now why are getters/setters evil? I STRONGLY recommend the articles from JavaWorld: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html and http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html?page=2 The author, Alan Holub, knows his stuff. As the preface to his book suggests, he might not be the ideal person to be on a deserted island with, but these articles are full of value. These articles describe the problem and a nice solution. The solution involves the Builder Pattern for the Business Objects, with an Exporter to create the view layer. Of course, working with JSP, you don't want to have to put the code to build the view inside a long println syntax, so some imaginative modification is needed. What I did was to make an Interface with all the objects I might need in my pages: Values, Tables, Trees. Then the exporter provides these objects to the JSP page, and I have no getters/setters at all on the Business Objects (the model), and only a few in the Exporter, which I regard now as a ViewHelper pattern. I make the Exporter available thru the Action class, and now my Actions know nothing about the model, the model knows nothing about the database (the 'Importer' knows that), and the Exporter doesn't expose anything about the Model to the Action or the View. It has become, in essence, a TO. For other view layers, I produce other Exporters, a PDFExporter, a SpreadSheetExporter, etc. - Ray Clough [EMAIL PROTECTED] - Original Message - From: mraible [EMAIL PROTECTED] To: user@struts.apache.org Subject: Re: [s2] Is it possible to replace/supplement i18n resolution logic? Date: Mon, 6 Aug 2007 13:44:16 -0700 (PDT) Also, if you believe getters and setters are evil, what's the solution? Most of the Java web frameworks I know of today use getters and setters to read/set values. Are getters and setters evil in your Hibernate/JPA POJOs as well? Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Is it possible to replace/supplement i18n resolution logic?
On 8/4/07, Ray Clough [EMAIL PROTECTED] wrote: Sorry for the rant, but I do like many of the S2 features well enough that I continue to use it Feel free to start a Struts 3 roadmap on the wiki that identifies some of the features we might subtract, as well as those that we might add. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Is it possible to replace/supplement i18n resolution logic?
Complaining about features in an open source program written by volunteers isn't really very nice, and I apologize for it. All programs have sub-optimal features, mine included, of course, and no one likes having their work sniped at by outsiders. The fundamental architecture of S2 is really sound, which allows me to use most of it in ways which suit me, even if they aren't part of the envisioned use when the app was written. This speaks well of its flexibility and modularity. The latest thing we've done is to use JSF components for all the display pages from S2 actions, and we found that we couldn't use the JSF plugin because it was too buggy. So we just declare that the action types are redirect, and the JSF processor seems to handle everything. I was surprised that this worked, since now there is no tie between the S2 process and the JSF process. The app has had some pure JSF pages for some time, but now to use JSF with S2 but not have to rely on the JSF plugin is really great. Probably there are JSF-things we couldn't do with this method, but the things we want it to do, it does very nicely. We have a 'builder' architecture for all the actions, which 'export' the data to the view. Of course, in a pure exporter, the exporter actually creates the view, but that would require giving up the JSP-idiom, which would be unthinkable at this juncture. Having the JSF components render the exported data items is an ideal compromise for me. We just treat the components as a super-powerful tag set. Again, I apologize for the earlier rant. - Ray Clough [EMAIL PROTECTED] - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Subject: Re: [s2] Is it possible to replace/supplement i18n resolution logic? Date: Sun, 5 Aug 2007 06:32:17 -0400 On 8/4/07, Ray Clough [EMAIL PROTECTED] wrote: Sorry for the rant, but I do like many of the S2 features well enough that I continue to use it Feel free to start a Struts 3 roadmap on the wiki that identifies some of the features we might subtract, as well as those that we might add. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Ray Clough [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Is it possible to replace/supplement i18n resolution logic?
We did something similar to what you are suggesting. We still use properties files, but we replaced much of the lookup with our own classes. We created a wrapper around ResourceBundle which has overloaded 'getText()' methods. We make this accessible to all parts of the app with a ThreadLocal object which incorporates the current Locale, and has a 'getMessageProvider()' method. The 'MessageProvider' has the 'getText(key, args)' methods. We did this because the non-Struts modules of the app need Message Support also, and so in order to keep the Struts artifacts out of these modules, we did the extra work. The process of replacing messaging in the JSP pages was too daunting, so we still use the S2 tags to resolve those messages. Our module uses the same ResourceBundle files as the Struts module. However we created our own tag library to replace the s:text tag in some instances where the action isn't S2 (sometimes it is S1, sometimes it is JSF). I think the ideal solution would be to move all the messaging resources into a new Commons project (commons-messaging??), and to access to the messaging service as an interface abstraction. That way the choice of messaging service would be more flexible. Changing the S2 messaging system would require overriding the 'getText()' methods in the ActionSupport class, as well as changing the way that the S2 tags get their messages. That would be a pretty huge job, and would take a huge amount of refactoring of the S2 code base. However, IMHO the S2 tags are really poor, so replacing them completely with a new library would be an excellent step. What I dislike most about the S2 tags is that their syntax is confusing, and very un-jsp-like. They don't allow runtime expressions (like the jstl tags), requiring the use of s:set to create properties which are then de-referenced in the UI tags. Also the syntax for accessing OGNL is particularly incongruous. Some tags require using both a % and a # within one tag. A lot of this is the result of trying to make a tag library that is flexible enough to work in environments other than JSP, but I believe a lot of it is due to the 'hobby-like' nature of S2 (I was not involved, so this is speculation on my part). The evolution of WebWork from Struts allowed the WW developers to 'try things out', and when the project was remerged into S2, many design decisions which should have been reversed were found to be too much trouble. So the 'try things out' features remain to bedevil the S2 application architecture. The very worst feature (again IMHO) is the mandatory use of themes. The other very worst feature is the result 'type' feature which mandates that only one rendering type can be used in any one page. For example, if you are using the Tiles plugin with 'type=tiles', you can't use the jsf plugin with 'type=jsf'. This has mandated that we don't use any plugins at all. Of course, this isn't a big loss because the most of plugins are very very very ... very buggy and do not appear to be in current development, as judged by their still poor implementations. Another very worst feature is the translation of the word POJO to equal Java Bean, and means that everything has getters and setters everywhere, which makes the apps developed with it poorly encapsulated and difficult to maintain (the designers of S2 definitely did not read, or did not comprehend, or did not believe, the central theme of Why Getters and Setters are Evil). Sorry for the rant, but I do like many of the S2 features well enough that I continue to use it, and the S2 architecture is definitely better than S1 (death to ActionForm!). - Ray Clough - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Subject: Re: [s2] Is it possible to replace/supplement i18n resolution logic? Date: Sat, 4 Aug 2007 12:30:09 +1000 On 8/4/07, mraible [EMAIL PROTECTED] wrote: With Struts 2, how would I go about doing the following: 1. Replace the i18n resolution logic to load key/value pairs from a database instead of properties files? Well, if your Action class implements TextProvider (as does ActionSupport), then you can resolve keys any way you'd like. As for plugging/altering the existing lookup that is used by ActionSupport, it really isn't possible right now, and I've love to see a patch making that more flexible... *hint* *hint* :) 2. Add an extra processing step to translate wiki syntax in values to HTML? You mean like creating your own template to customize the rendering of the control? If using Freemarker, there might be a nice way to write something like the ?html piece that processes returned values. Don Thanks, Matt -- View this message in context: http://www.nabble.com/-s2--Is-it-possible-to-replace-supplement-i18n-resolution-logic--tf4214304.html#a11989382 Sent from the Struts - User mailing
Re: [s2] Is it possible to replace/supplement i18n resolution logic?
Well, if your Action class implements TextProvider (as does ActionSupport), then you can resolve keys any way you'd like. As for plugging/altering the existing lookup that is used by ActionSupport, it really isn't possible right now, and I've love to see a patch making that more flexible... *hint* *hint* :) Am I crazy or would this be as simple as having a setTextProvider() method in ActionSupport that would (take a guess..) set the textProvider which is currently private in ActionSupport. Then when you're configuring your actions with say Spring, you could pass your own TextProvider singleton bean. Zarar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Is it possible to replace/supplement i18n resolution logic?
With Struts 2, how would I go about doing the following: 1. Replace the i18n resolution logic to load key/value pairs from a database instead of properties files? 2. Add an extra processing step to translate wiki syntax in values to HTML? Thanks, Matt -- View this message in context: http://www.nabble.com/-s2--Is-it-possible-to-replace-supplement-i18n-resolution-logic--tf4214304.html#a11989382 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Is it possible to replace/supplement i18n resolution logic?
On 8/4/07, mraible [EMAIL PROTECTED] wrote: With Struts 2, how would I go about doing the following: 1. Replace the i18n resolution logic to load key/value pairs from a database instead of properties files? Well, if your Action class implements TextProvider (as does ActionSupport), then you can resolve keys any way you'd like. As for plugging/altering the existing lookup that is used by ActionSupport, it really isn't possible right now, and I've love to see a patch making that more flexible... *hint* *hint* :) 2. Add an extra processing step to translate wiki syntax in values to HTML? You mean like creating your own template to customize the rendering of the control? If using Freemarker, there might be a nice way to write something like the ?html piece that processes returned values. Don Thanks, Matt -- View this message in context: http://www.nabble.com/-s2--Is-it-possible-to-replace-supplement-i18n-resolution-logic--tf4214304.html#a11989382 Sent from the Struts - User mailing list archive at Nabble.com. - 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]
