You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2006/09/30 07:44:22 UTC
Form label defaults (was Struts 2.0.1 release)
This is a tricky one and will take more thought. Currently, the value
attribute is optional, but how the name is used for the label key is the
question - ActionClass.name, ActionClass.method.name, name, etc.
I'd like to see how the Able project will handle this one, as they are
looking to work over Struts using a comprehensive convention-based approach.
Don
David H. DeWolf wrote:
> Sounds good to me too. . .
>
> any hope of convincing one of you to apply this (or a similar) patch
> prior to the release:
>
> https://issues.apache.org/struts/browse/WW-1458
>
> Thanks,
>
> David
>
> Don Brown wrote:
>> I want to roll the Struts 2.0.1 release next weekend, October 8. A
>> lot of changes have gone into the code since 2.0.0 and I'd like to
>> have a solid release that people can check out after Ted and my talks.
>>
>> I'm thinking we'll do this at the Sunday hackathon since I believe
>> Ted, Wendy, and I will all be present. Any objections?
>>
>> Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Form label defaults (was Struts 2.0.1 release)
Posted by Ted Husted <hu...@apache.org>.
>From https://issues.apache.org/struts/browse/WW-1458
> <@s.textfield name="user.userName"
> value="%{user.userName}"
> label="%{getText('user.userName')}"/>
As discussed on the mailing list, the value is already defaulted to
the name, so the (very common) idiom in question is
<@s.textfield name="user.userName" label="%{getText('user.userName')}"/>
The three use cases I can think of are
1. The name and label key token match
2. The name and label key tokens do not match
3. The label is meant to be empty
(1) If the label key matches the name, then the simplest possible form might be
<@s.textfield key="user.userName" />
which implies that there is a i18n key like
* user.username = "User Name"
and where we search for the i18n message key in all the usual places.
(2) If the label key cannot be made to match the name, the next
simplest form might be something like
<@s.textfield name="user.userName" key= "payables.login.username" >
So, if the name attribute is specified we use it verbatim, and we
still use the key attribute to obtain the label text.
(3) But, what is there is no label to lookup? In that case, we would
specify name, but not label or key.
<@s.textfield name="user.userName" />
Now, this strategy could be the intent of the patch. I couldn't be
sure without applying the patch and running some tests. But, I thought
addressing the use cases one by one would be helpful in any event.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Form label defaults (was Struts 2.0.1 release)
Posted by "David H. DeWolf" <dd...@apache.org>.
I've taken a look through the strips documentation in regards to
localization and it seems as though it's pretty close to what's been
discussed already in this thread. The one thing stripes tries to do as
well is translate keys that could not be found into something a little
more user friendly (e.g. "fieldName" would be come "Field Name").
http://stripes.mc4j.org/confluence/display/stripes/Localization
David
Patrick Lightbody wrote:
> This is really good stuff, keep working to flesh it out fully. Take a look at the Stripes i18n/validation scopes for an example of a well-done implementation.
>
> Also, one thing I'd note: we do default the value attribute to the evaluation of the name attribute already, so the question is all about defaulting the i18n key.
>
> For the short term, you can actually achieve this by just editing your controlheader.ftl template and making a call out to $stack.finValue("getText(...)"), but of course we'd prefer to have best practices as the default option.
>
>> Fair enough. So if I understand correctly, before we
>> commit something
>> in this regard, you'd like to consider and come to
>> consensus on the
>> correct approach for standardizing the lookup of
>> label names when the
>> 'key' shortcut is used within the tags.
>>
>> With this in mind, I've taken a look at able and have
>> found that it does
>> not internationalize anything. Because of this:
>>
>> 1) the tags are not a verbose as I have found them to
>> be in most situations.
>>
>> 2) there's no 'best practice' we can leverage from
>> able.
>>
>> So, does anybody else have any thoughts on what this
>> convention should
>> look like? Don, through your examples below
>> (ActionClass.name,
>> ActionClass.method.name, name, etc. . .), are you
>> proposing those
>> conventions as individual possibilities or a
>> hierarchy of which the
>> first one found would be applied. The latter seems
>> like a good idea to
>> me. . .except for the fact that I would reorder it
>> and define the
>> rule/convention as:
>>
>>
>> For any key 'example.propertyName' provided as a
>> shortcut to any of the
>> ui tags, the label should be displayed based upon the
>> first of the
>> following which can be resolved:
>>
>> 1)
>> getText('ActionClass.actionMapping.example.propertyNam
>> e')
>> 2) getText('ActionClass.example.propertyName')
>> 3) getText('example.propertyName')
>> 4) 'example.propertyName'
>>
>> Let me know your thoughts,
>>
>>
>> David
>>
>>
>> Don Brown wrote:
>>> This is a tricky one and will take more thought.
>> Currently, the value
>> attribute is optional, but how the name is used for
>> the label key is the
>> question - ActionClass.name,
>> ActionClass.method.name, name, etc.
>>
>> I'd like to see how the Able project will handle
>> this one, as they are
>> looking to work over Struts using a comprehensive
>> convention-based
>> approach.
>>
>> Don
>>
>> David H. DeWolf wrote:
>>> Sounds good to me too. . .
>>>> any hope of convincing one of you to apply this
>> (or a similar) patch
>>>> prior to the release:
>>>>
>>>> https://issues.apache.org/struts/browse/WW-1458
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>>> Don Brown wrote:
>>>>> I want to roll the Struts 2.0.1 release next
>> weekend, October 8. A
>>>>> lot of changes have gone into the code since
>> 2.0.0 and I'd like to
>>>>> have a solid release that people can check out
>> after Ted and my talks.
>>>>> I'm thinking we'll do this at the Sunday
>> hackathon since I believe
>>>>> Ted, Wendy, and I will all be present. Any
>> objections?
>>>>> Don
>>>>>
>>>>>
>> ------------------------------------------------------
>> ---------------
>>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail:
>> dev-help@struts.apache.org
>>>>>
>>>>
>> ------------------------------------------------------
>> ---------------
>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail:
>> dev-help@struts.apache.org
>>>>
>>>
>>>
>> ------------------------------------------------------
>> ---------------
>>> To unsubscribe, e-mail:
>> dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail:
>> dev-help@struts.apache.org
>>>
>> ------------------------------------------------------
>> ---------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail:
>> dev-help@struts.apache.org
>>
>>
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=44702&messageID=90791#90791
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Form label defaults (was Struts 2.0.1 release)
Posted by Patrick Lightbody <fo...@opensymphony.com>.
This is really good stuff, keep working to flesh it out fully. Take a look at the Stripes i18n/validation scopes for an example of a well-done implementation.
Also, one thing I'd note: we do default the value attribute to the evaluation of the name attribute already, so the question is all about defaulting the i18n key.
For the short term, you can actually achieve this by just editing your controlheader.ftl template and making a call out to $stack.finValue("getText(...)"), but of course we'd prefer to have best practices as the default option.
> Fair enough. So if I understand correctly, before we
> commit something
> in this regard, you'd like to consider and come to
> consensus on the
> correct approach for standardizing the lookup of
> label names when the
> 'key' shortcut is used within the tags.
>
> With this in mind, I've taken a look at able and have
> found that it does
> not internationalize anything. Because of this:
>
> 1) the tags are not a verbose as I have found them to
> be in most situations.
>
> 2) there's no 'best practice' we can leverage from
> able.
>
> So, does anybody else have any thoughts on what this
> convention should
> look like? Don, through your examples below
> (ActionClass.name,
> ActionClass.method.name, name, etc. . .), are you
> proposing those
> conventions as individual possibilities or a
> hierarchy of which the
> first one found would be applied. The latter seems
> like a good idea to
> me. . .except for the fact that I would reorder it
> and define the
> rule/convention as:
>
>
> For any key 'example.propertyName' provided as a
> shortcut to any of the
> ui tags, the label should be displayed based upon the
> first of the
> following which can be resolved:
>
> 1)
> getText('ActionClass.actionMapping.example.propertyNam
> e')
> 2) getText('ActionClass.example.propertyName')
> 3) getText('example.propertyName')
> 4) 'example.propertyName'
>
> Let me know your thoughts,
>
>
> David
>
>
> Don Brown wrote:
> > This is a tricky one and will take more thought.
> Currently, the value
> attribute is optional, but how the name is used for
> the label key is the
> question - ActionClass.name,
> ActionClass.method.name, name, etc.
>
> I'd like to see how the Able project will handle
> this one, as they are
> looking to work over Struts using a comprehensive
> convention-based
> approach.
>
> Don
>
> David H. DeWolf wrote:
> > Sounds good to me too. . .
> >>
> >> any hope of convincing one of you to apply this
> (or a similar) patch
> >> prior to the release:
> >>
> >> https://issues.apache.org/struts/browse/WW-1458
> >>
> >> Thanks,
> >>
> >> David
> >>
> >> Don Brown wrote:
> >>> I want to roll the Struts 2.0.1 release next
> weekend, October 8. A
> >>> lot of changes have gone into the code since
> 2.0.0 and I'd like to
> >>> have a solid release that people can check out
> after Ted and my talks.
> >>>
> >>> I'm thinking we'll do this at the Sunday
> hackathon since I believe
> >>> Ted, Wendy, and I will all be present. Any
> objections?
> >>>
> >>> Don
> >>>
> >>>
> ------------------------------------------------------
> ---------------
> >>> To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail:
> dev-help@struts.apache.org
> >>>
> >>>
> >>
> >>
> ------------------------------------------------------
> ---------------
> >> To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail:
> dev-help@struts.apache.org
> >>
> >>
> >
> >
> >
> ------------------------------------------------------
> ---------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail:
> dev-help@struts.apache.org
> >
> >
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=44702&messageID=90791#90791
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Form label defaults (was Struts 2.0.1 release)
Posted by "David H. DeWolf" <dd...@apache.org>.
Fair enough. So if I understand correctly, before we commit something
in this regard, you'd like to consider and come to consensus on the
correct approach for standardizing the lookup of label names when the
'key' shortcut is used within the tags.
With this in mind, I've taken a look at able and have found that it does
not internationalize anything. Because of this:
1) the tags are not a verbose as I have found them to be in most situations.
2) there's no 'best practice' we can leverage from able.
So, does anybody else have any thoughts on what this convention should
look like? Don, through your examples below (ActionClass.name,
ActionClass.method.name, name, etc. . .), are you proposing those
conventions as individual possibilities or a hierarchy of which the
first one found would be applied. The latter seems like a good idea to
me. . .except for the fact that I would reorder it and define the
rule/convention as:
For any key 'example.propertyName' provided as a shortcut to any of the
ui tags, the label should be displayed based upon the first of the
following which can be resolved:
1) getText('ActionClass.actionMapping.example.propertyName')
2) getText('ActionClass.example.propertyName')
3) getText('example.propertyName')
4) 'example.propertyName'
Let me know your thoughts,
David
Don Brown wrote:
> This is a tricky one and will take more thought. Currently, the value
> attribute is optional, but how the name is used for the label key is the
> question - ActionClass.name, ActionClass.method.name, name, etc.
>
> I'd like to see how the Able project will handle this one, as they are
> looking to work over Struts using a comprehensive convention-based
> approach.
>
> Don
>
> David H. DeWolf wrote:
>> Sounds good to me too. . .
>>
>> any hope of convincing one of you to apply this (or a similar) patch
>> prior to the release:
>>
>> https://issues.apache.org/struts/browse/WW-1458
>>
>> Thanks,
>>
>> David
>>
>> Don Brown wrote:
>>> I want to roll the Struts 2.0.1 release next weekend, October 8. A
>>> lot of changes have gone into the code since 2.0.0 and I'd like to
>>> have a solid release that people can check out after Ted and my talks.
>>>
>>> I'm thinking we'll do this at the Sunday hackathon since I believe
>>> Ted, Wendy, and I will all be present. Any objections?
>>>
>>> Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org