Re: Struts 1.4 2.1 sharing localization code
2007/3/2, Niall Pemberton [EMAIL PROTECTED]: If you wanted to start something - any Apache committer can have access to the Commons Sandbox - I think you just have to ask. Something like commons-locale? I feel that Tiles won't use commons-resources current code, but only the new locale resolution code, so from my POV it is the same to wake commons-resources up or create a new sandbox project. In the latter case, anyway, I will let Paul make the proposal, since it is his idea, I won't steal his fun :-) Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
I took a quick look at XWork - they already have a LocaleProvider interface which defines a single getLocale() method: http://tinyurl.com/yqmlv3 Paul's solution (based on some Spring classes) is tied to the webapp context with his equivalent LocaleResolver interface defining two methods: Locale resolveLocale(HttpServletRequest request); void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale); Niall On 3/2/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/3/2, Niall Pemberton [EMAIL PROTECTED]: If you wanted to start something - any Apache committer can have access to the Commons Sandbox - I think you just have to ask. Something like commons-locale? I feel that Tiles won't use commons-resources current code, but only the new locale resolution code, so from my POV it is the same to wake commons-resources up or create a new sandbox project. In the latter case, anyway, I will let Paul make the proposal, since it is his idea, I won't steal his fun :-) Antonio - 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]
Re: Struts 1.4 2.1 sharing localization code
The standalone library would be resolver strategies, but S1 and S2 would need their own adapter. For S1, the adapter is the SelectLocale command, which exposes it for Action.getLocale(). Since I've been busy getting the next 1.3 GA out the door, I haven't had time to look at this 1.4 feature again. But I will within this month. Paul Niall Pemberton wrote: I took a quick look at XWork - they already have a LocaleProvider interface which defines a single getLocale() method: http://tinyurl.com/yqmlv3 Paul's solution (based on some Spring classes) is tied to the webapp context with his equivalent LocaleResolver interface defining two methods: Locale resolveLocale(HttpServletRequest request); void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale); Niall On 3/2/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/3/2, Niall Pemberton [EMAIL PROTECTED]: If you wanted to start something - any Apache committer can have access to the Commons Sandbox - I think you just have to ask. Something like commons-locale? I feel that Tiles won't use commons-resources current code, but only the new locale resolution code, so from my POV it is the same to wake commons-resources up or create a new sandbox project. In the latter case, anyway, I will let Paul make the proposal, since it is his idea, I won't steal his fun :-) Antonio - 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]
Re: Struts 1.4 2.1 sharing localization code
On 2/28/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/2/22, Antonio Petrelli [EMAIL PROTECTED]: What could be useful for Tiles is a single configurable entry-point from which the current Locale should be taken. I don't know if Paul means this. I think Niall cleared my doubt in the Tiles Developers list, letting me know about Paul's work: http://issues.apache.org/struts/browse/STR-2897 I noticed that it can be easily used also with Tiles, so now the question is: where does this code belong to? I don't think that putting it in Struts is a good idea, since it will create an unwanted dependency. But neither commons-resources nor commons-i18n seem to have a Locale resolving feature. Both of those places seem to be good to me, I really don't know why there are two projects for the same subject (correct me if I am wrong). Whatever the choice is, I am willing to collaborate. Commons resources never made it to a release and Commons i18n never made it out of the Sandbox. The reason for two projects (AFAIK) was they were created by different people. Commons Resources was code factored out of Struts 1. If you wanted to start something - any Apache committer can have access to the Commons Sandbox - I think you just have to ask. Niall Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
2007/2/22, Antonio Petrelli [EMAIL PROTECTED]: What could be useful for Tiles is a single configurable entry-point from which the current Locale should be taken. I don't know if Paul means this. I think Niall cleared my doubt in the Tiles Developers list, letting me know about Paul's work: http://issues.apache.org/struts/browse/STR-2897 I noticed that it can be easily used also with Tiles, so now the question is: where does this code belong to? I don't think that putting it in Struts is a good idea, since it will create an unwanted dependency. But neither commons-resources nor commons-i18n seem to have a Locale resolving feature. Both of those places seem to be good to me, I really don't know why there are two projects for the same subject (correct me if I am wrong). Whatever the choice is, I am willing to collaborate. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
2007/2/22, Don Brown [EMAIL PROTECTED]: Ah, that makes much more sense :) As for collaborating, I'm all for it, however in the case of Struts 2, it would happen probably at the XWork 2 layer. Since this code would be useful to non-Struts projects, perhaps it would be better to move it to Jakarta Commons, say commons-i18n? I believe that project is still in the sandbox and looking for developers so it may be ripe for new development. I thought there was another commons project that Struts 1 was always going to move to, commons-resources or something? Tiles could benefit for such a project too. Anyway it seems that both commons-resources and commons-i18n are not made for a web environment. What could be useful for Tiles is a single configurable entry-point from which the current Locale should be taken. I don't know if Paul means this. Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
Actually I think the xwork2 i18n code is pretty good. I would probably look at that code as the basis--or at least make sure that we don't loose any functionality. Although there's some areas that need work--(hint validators), I thought webwork had pretty good i18n support. Far more flexible and straightforward than Strut1 from what I remember. :) Tom Don Brown wrote: Ah, that makes much more sense :) As for collaborating, I'm all for it, however in the case of Struts 2, it would happen probably at the XWork 2 layer. Since this code would be useful to non-Struts projects, perhaps it would be better to move it to Jakarta Commons, say commons-i18n? I believe that project is still in the sandbox and looking for developers so it may be ripe for new development. I thought there was another commons project that Struts 1 was always going to move to, commons-resources or something? Don On 2/21/07, Paul Benedict [EMAIL PROTECTED] wrote: Ah. Good email. I didn't realize that my sentence could be read as such, but now I can see that interpretation. Here's what I meant: I'd like to propose creating a sub-project (like the annotations) for localization. Not creating annotations for localization, but a subproject like you did for annotations. Is that clearer? Man, sounds confusing still. Paul Don Brown wrote: For the unaware like me, could you go more into the problem that exists in Struts 1 and 2, and the solution that involves these annotations? Just from this message, I'm a bit confused why we would use annotations for something like this. Don On 2/21/07, *Paul Benedict* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'd like to propose creating a sub-project like the annotations for localization. I am not at the point of committing my 1.4 changes, but real important classes are independent of s1 and could be used in s2. This is all theory. I haven't spent enough time looking at s2 to figure out in-depth its localization strategies are. But I think it's a worthwhile effort to look into. Is anyone interested? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
On 2/21/07, Don Brown [EMAIL PROTECTED] wrote: Ah, that makes much more sense :) As for collaborating, I'm all for it, however in the case of Struts 2, it would happen probably at the XWork 2 layer. Since this code would be useful to non-Struts projects, perhaps it would be better to move it to Jakarta Commons, say commons-i18n? I believe that project is still in the sandbox and looking for developers so it may be ripe for new development. I thought there was another commons project that Struts 1 was always going to move to, commons-resources or something? Yes, Commons Resources: https://svn.apache.org/repos/asf/jakarta/commons/dormant/resources/trunk/ As with several other Commons components, it started life as part of Struts. Several people, mostly from the Struts team, worked on it over quite a period of time, and it went through a couple of redesigns, but never got as far as a release and is now considered dormant. (Contrary to Antonio's comment, Commons Resources was originally designed for use in web apps. However, the web-ness of it was abstracted out so that it can be used elsewhere as well.) One thing to bear in mind when looking at sharing code between Struts 1 and other projects: Struts 1 has a requirement that its resource bundles be serialisable. This is why it is not based on the standard java.util.ResourceBundle class, which is not serialisable. Struts 2 currently uses ResourceBundle in a number of places. -- Martin Cooper Don On 2/21/07, Paul Benedict [EMAIL PROTECTED] wrote: Ah. Good email. I didn't realize that my sentence could be read as such, but now I can see that interpretation. Here's what I meant: I'd like to propose creating a sub-project (like the annotations) for localization. Not creating annotations for localization, but a subproject like you did for annotations. Is that clearer? Man, sounds confusing still. Paul Don Brown wrote: For the unaware like me, could you go more into the problem that exists in Struts 1 and 2, and the solution that involves these annotations? Just from this message, I'm a bit confused why we would use annotations for something like this. Don On 2/21/07, *Paul Benedict* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'd like to propose creating a sub-project like the annotations for localization. I am not at the point of committing my 1.4 changes, but real important classes are independent of s1 and could be used in s2. This is all theory. I haven't spent enough time looking at s2 to figure out in-depth its localization strategies are. But I think it's a worthwhile effort to look into. Is anyone interested? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Struts 1.4 2.1 sharing localization code
I'd like to propose creating a sub-project like the annotations for localization. I am not at the point of committing my 1.4 changes, but real important classes are independent of s1 and could be used in s2. This is all theory. I haven't spent enough time looking at s2 to figure out in-depth its localization strategies are. But I think it's a worthwhile effort to look into. Is anyone interested? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
For the unaware like me, could you go more into the problem that exists in Struts 1 and 2, and the solution that involves these annotations? Just from this message, I'm a bit confused why we would use annotations for something like this. Don On 2/21/07, Paul Benedict [EMAIL PROTECTED] wrote: I'd like to propose creating a sub-project like the annotations for localization. I am not at the point of committing my 1.4 changes, but real important classes are independent of s1 and could be used in s2. This is all theory. I haven't spent enough time looking at s2 to figure out in-depth its localization strategies are. But I think it's a worthwhile effort to look into. Is anyone interested? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
Ah. Good email. I didn't realize that my sentence could be read as such, but now I can see that interpretation. Here's what I meant: I'd like to propose creating a sub-project (like the annotations) for localization. Not creating annotations for localization, but a subproject like you did for annotations. Is that clearer? Man, sounds confusing still. Paul Don Brown wrote: For the unaware like me, could you go more into the problem that exists in Struts 1 and 2, and the solution that involves these annotations? Just from this message, I'm a bit confused why we would use annotations for something like this. Don On 2/21/07, *Paul Benedict* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'd like to propose creating a sub-project like the annotations for localization. I am not at the point of committing my 1.4 changes, but real important classes are independent of s1 and could be used in s2. This is all theory. I haven't spent enough time looking at s2 to figure out in-depth its localization strategies are. But I think it's a worthwhile effort to look into. Is anyone interested? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.4 2.1 sharing localization code
Ah, that makes much more sense :) As for collaborating, I'm all for it, however in the case of Struts 2, it would happen probably at the XWork 2 layer. Since this code would be useful to non-Struts projects, perhaps it would be better to move it to Jakarta Commons, say commons-i18n? I believe that project is still in the sandbox and looking for developers so it may be ripe for new development. I thought there was another commons project that Struts 1 was always going to move to, commons-resources or something? Don On 2/21/07, Paul Benedict [EMAIL PROTECTED] wrote: Ah. Good email. I didn't realize that my sentence could be read as such, but now I can see that interpretation. Here's what I meant: I'd like to propose creating a sub-project (like the annotations) for localization. Not creating annotations for localization, but a subproject like you did for annotations. Is that clearer? Man, sounds confusing still. Paul Don Brown wrote: For the unaware like me, could you go more into the problem that exists in Struts 1 and 2, and the solution that involves these annotations? Just from this message, I'm a bit confused why we would use annotations for something like this. Don On 2/21/07, *Paul Benedict* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'd like to propose creating a sub-project like the annotations for localization. I am not at the point of committing my 1.4 changes, but real important classes are independent of s1 and could be used in s2. This is all theory. I haven't spent enough time looking at s2 to figure out in-depth its localization strategies are. But I think it's a worthwhile effort to look into. Is anyone interested? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
