@Parameter already has the "autoconnect" attribute to determine whether the framework will attempt to find a value for the parameter.
The Component Report should be updated to include that information in the "flags" column. Currently the flags for TextField's value parameter read: Required, NOT Allow Null It could be changed to read: Required, AutoConnect, Not Null It would be nice if that HTML was cleaned up a bit as well, those values get squished and being less readable... As a side not; I find "NOT Allow Null" to be... not optimal for easy reading. Are we going to continue using the tapestry-component-report build the doc going forward? Josh On Mon, Aug 22, 2011 at 10:04 AM, Robert Zeigler <robert.zeig...@roxanemy.com> wrote: > I would prefer to keep the required clause. The difference between a required > parameter and one that isn't is that if no value is available for the > required parameter (whether user or framework provided), the component > /cannot/ function. An /optional/ parameter is one where the component /can/ > function, even if there is no value provided (by the user or framework) for > the value. AjaxFormLoop absolutely MUST have a value encoder, or it doesn't > work. Likewise, "value" is required for TextField, even though the framework > will attempt to "autobind" the parameter to a property in the container > matching the component id. As Thiago said, required is from the component > perspective, not from the developer perspective. I do agree that it's a bit > confusing, though, and it would be nice to distinguish between "required, but > framework attempts a default" from "required, and you must provide and > explicit binding". Maybe we could add a new boolean: "defaultAttempted" or > "defaultProvided" to achieve this ternary state? Alternatively, perhaps > "required" could be tweaked to an enum: REQUIRED, REQUIRED_WITH_DEFAULT, > NOT_REQUIRED, with a boolean -> enum converter for backwards compatibility. > False would -> NOT_REQUIRED. Not sure what true would convert to, but > probably REQUIRED_WITH_DEFAULT since that is the majority of required > parameters out there. > > Robert > > On Aug 22, 2011, at 8/2211:09 AM , Bob Harner wrote: > >> We all agree that it is common for one piece of software to require >> something that another piece of software can provide. This is the >> whole idea of the concept of "defaults". The user can provide >> something directly, or he/she can let the software figure out the best >> default value to apply. In those cases, we use the word "optional", >> not the word "required". That much is a universal convention, clear >> and unambiguous to all. >> >> In the case of value encoders, if the component needs one and the user >> doesn't supply one directly via the "value" parameter, then the >> component is expected to figure out the best default to apply. Whether >> the best default is one of Tapestry's coercions or a default value >> encoder the user has established in some other part of the program is >> immaterial to the argument. The documentation says that the parameter >> is required, and yet, it is really only the underlying value encoder >> that is required, not the parameter. >> >> I understand the thinking behind the current usage of the word >> "required" in this case. I really do. It was a carefully-made >> compromise to make a binary value fit what is really a ternary choice. >> But the usage just doesn't fit with well-established conventions, and >> it's an obstacle to users in trying to understand how to use the >> framework. >> >> Theoretically, to fix this, I guess we would just need to remove the >> "required" clause from those several components that use value >> encoders, and then improve the exception message that displays when >> Tapestry can't find a value encoder to use. Anything else? >> >> On Mon, Aug 22, 2011 at 8:47 AM, Thiago H. de Paula Figueiredo >> <thiag...@gmail.com> wrote: >>> On Mon, 22 Aug 2011 07:36:08 -0300, Massimo Lusetti <mluse...@gmail.com> >>> wrote: >>> >>>> BTW I find completely usual having a piece of software requiring >>>> something and having another piece of software providing it. >>>> It seems obvious that the latter could be user's code or another >>>> module of the same software or a third party module too. >>> >>> I don't think this is unusual. It means the component parameter requires a >>> value, regardless where it comes from. This is not the same as saying the >>> user is required to provide a value. The requirement here is from the >>> component parameter view, not the user (developer) one. >>> >>> (Breaking the threading because I mistakenly sent the message just to >>> Massimo instead of to the list and I already deleted the message, so I >>> cannot reply to it directly). >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, >>> and instructor >>> Owner, Ars Machina Tecnologia da Informação Ltda. >>> http://www.arsmachina.com.br >>> >>> --------------------------------------------------------------------- >>> 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: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
