Okay thank you for the clarification. I had changed my copy of themes/simple/text.ftl to add the html5 attribute in the case when "required=true" was set. This continues to work fine for me when I set "requiredLabel=true" -- so in my case it does have an additional (beneficial) side effect, in that my theme applies the required="required" attribute.
I've given up on possible reversion of the WW-3908 change and changed all of my templates. It wasn't too hard. The only developer-list appropriate aspect of this issue is that treating "required" as a dynamic attribute sucks because if you specify <@s.textfiled ... required=false requiredLabel=false /> then you get something completely unexpected -- this is passed through to the browser, which will require the field due to the boolean-attribute nature of "required." I feel that it's inappropriate to treat "required" as a dynamic attribute, and that renaming it to "requiredLabel" should not have been done in the first place. But it was done, so we must react and use the framework as it is designed. Thank you for your continued insights into this. On Wed, Sep 11, 2013 at 1:47 PM, Steven Benitez <steven.beni...@gmail.com>wrote: > Nope, it's just the asterisk. Backend validation is handled in the action's > validate method or validation XML. > > On Wednesday, September 11, 2013, struts wrote: > > > I see -- I was under the mistaken impression that "requiredLabel" before > > 2.3.12 defined -- at the field level -- which character would be used to > > indicate that a field is required. Similar to how "labelSeparator" > works. > > I see now that the character used is hard-coded to an asterisk, and that > > "requiredLabel" is relatively new. > > > > I don't understand what you mean by "requiredLabel makes more sense since > > that's all it does." If you set "requiredLabel=true" on tag in Struts > > 2.3.15.1, then it does more than show an asterisk -- it also causes the > > back-end to enforce validation, doesn't it? I know that I'm "stuck" in > > pre-WW-3908 thinking due to it working one way for years, but to me > > "required=true" makes more sense to cause three things to happen: > > 1) An asterisk to appear next to a field (depending on theme) > > 2) For the back-end to validate that the field is not-blank or null > > 3) For the front-end to enforce that the field is filled out via html5 > > 'required="required"' output, possibly dependent on theme > > > > > > On Wed, Sep 11, 2013 at 12:02 PM, Steven Benitez > > <steven.beni...@gmail.com <javascript:;>>wrote: > > > > > I already updated to requiredLabel, so I vote we stick with that. :) > > > > > > Besides, requiredLabel actually makes more sense, since that's all it > > does. > > > You could invert the logic you proposed so that if a required attribute > > is > > > detected with a value of anything but "false", you consider that to > > trigger > > > requiredLabel="true". At least that way you are driving the label off > the > > > client validation, rather than the other way around. > > > > > > > > > On Wed, Sep 11, 2013 at 12:00 PM, struts <str...@rgm.nu<javascript:;>> > > wrote: > > > > > > > So as not to pollute the JIRAs too much with speculation or > suggestions > > > > that haven't been thought out, I'd like to have a discussion about > the > > > > "required" attribute here on the list. > > > > > > > > I propose that we revert the changes made in WW-3908, namely -- turn > > > > "requiredLabel" back into "required." Then, to support the html5 > > > required > > > > boolean attribute, change "themes/simple/text.ftl" to check <#if > > > > parameters.required?default(false)> required="required" </#if>. > > > > > > > > This is a backwards compatible change (from the > themes/simple/text.ftl > > > > perspective). It is also backwards compatible with templates made > > before > > > > Struts 2.3.12. > > > > > > > > It has a side effect that modern browsers will enforce client-side > > > > validation for text fields like this: > > > > <@s.textfield name="whatever" required=true /> > > > > > > > > I believe this side effect to be universally beneficial, but I could > be > > > > wrong about that. > > > > > > > > CONS: > > > > > > > > * Some folks have already gone and updated their templates to change > > > > "required" to "requiredLabel." These folks would have to go back > and > > > > revert that, unless logic was put in to see if requiredLabel was one > of > > > > "true" "false" or other. :-/ On the other hand, this frees up the > > > > "requiredLabel" attribute to be a String again, and allow per-field > > > > overriding of the default asterisk (*) character. > > > > > > > > * (maybe) Some folks may not want clients to enforce "required" in > > forms. > > > > > > > > PROS: > > > > > > > > * html5 required attribute, being specific to the way a tag is > > rendered, > > > > should be handled in themes where rendering logic exists. > > > > > > > > * Avoids "required=false" problem in 2.3.15.1, which confusingly does > > > cause > > > > modern browsers to require a field. For this reason alone, > "required" > > > > should not be a dynamic attribute. > > > > > > > > * Backwards compatible with pre-2.3.12 templates. > > > > > > > > * (subjective) Tag usage feels more natural -- "required" sounds > like a > > > > boolean, "requiredLabel" sounds like a String. > > > > > > > > What do you guys think? > > > > > > > > --rgm > > > > > > > > > >
