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
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:
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
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
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:
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
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
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
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
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:
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
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
12 matches
Mail list logo
