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
