I'm with you on this and I agree that this might be confusing for newcomers. But how would you solve this? I'm against removing the required flag and only have the user notice when he runs into an exception. It should be clear from the documentation that the parameter is indeed required but a default will be used if found and the parameter is not set. As Howard said, in those cases it is documented in the paramter description. An improvement could be an additional flag, maybe 'defaultprovided', to indicate that a default will be provided if not bound which the user can see directly without going through the description.
Uli On 23.08.2011 04:08, Bob Harner wrote: > I know what everybody says it means. I'm just saying that it > *shouldn't* mean that, because it violates the principle of least > surprise. > > I'll stop now. I know I'm in the minority on this. > > > On Mon, Aug 22, 2011 at 9:59 PM, Howard Lewis Ship <hls...@gmail.com> wrote: >> Required means that the value is required for the operation of the >> component. It does not mean that it must be explicitly bound when the >> component can provide a default. The parameter description will >> describe when a default can be provided automatically. >> >> On Sun, Aug 21, 2011 at 5:20 AM, Bob Harner <bobhar...@gmail.com> wrote: >>> Wow, I am truly stunned. I'm not sure I've ever seen a piece of software so >>> completely disregard the common sense meaning of a commonly understood word. >>> So "required" sometimes means "optional if certain conditions are met >>> elsewhere". And users are just supposed to figure that out on their own??? >>> >>> Bob Harner >>> On Aug 21, 2011 7:03 AM, "Igor Drobiazko" <igor.drobia...@gmail.com> wrote: >>>> The semantics are "the parameter is required. If no value is bound, the >>>> component will TRY to find a default. The lookup for a default value might >>>> be successful or not". >>>> >>>> For example, imagine you pass a list of Users to AjaxFormLoop and don't >>> bind >>>> a ValueEncoder. If no ValueEncoder for User is contributed, no default can >>>> be found and the component will complain about missing binding. That makes >>>> sense as the parameter is required. >>>> >>>> If you are using Hibernate or JPA integration, there is a ValueEncoder >>>> contributed automatically for every entity. In such a case, the default >>> can >>>> be found even though you didn't contribute any ValueEncoder manually. >>>> >>>> In summary: depending on the configuration of your app, a default >>>> ValueEncoder can be found or not. That's why marking the encoder parameter >>>> as required makes absolutely sense. >>>> >>>> On Sun, Aug 21, 2011 at 3:50 AM, Bob Harner <bobhar...@gmail.com> wrote: >>>> >>>>> my other question would be why the "encoder" >>>>> parameter is marked as "required" for AjaxFormLoop, Hidden and >>>>> RadioGroup. After all, as Robert Z. says, those components seem to >>>>> have the ability to supply the default encoder based on the bound type >>>>> of value. My brain is a little sleep-deprived, so maybe I'm just not >>>>> understanding how this really makes sense. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> >>>> Igor Drobiazko >>>> http://tapestry5.de >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
