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
