Expanding the meaning of "autoconnect" in this way seems beneficial -- better than doing nothing but (to me) not as good as just making "parameter is required" mean "parameter is required" :-)
Continuing to bang my head against the wall (caps are mine)... see if you can follow my reasoning via quotes from Tapestry: "Parameters that are required must be BOUND. A runtime exception occurs if a component has unbound required parameters." (http://tapestry.apache.org/component-parameters.html) "A binding is a connection between a component and its CONTAINER (another component), that allows the embedded component to gain access to resources defined by the container." (http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/Binding.html) "In many cases, a ValueEncoder can be generated automatically from the type of the value parameter. The ValueEncoderSource service provides an encoder in these situations; it can be overriden by binding the encoder parameter, OR extended by contributing a ValueEncoderFactory into the service's configuration." (Select.java) I haven't looked everywhere, but so far I can't find any reference in Tapestry that uses the "binding a parameter" concept to refer to an act like providing a ValueEncoder by contributing it to the configuration. Instead, "binding a parameter" seems to consistently refer to the more obvious act of linking together a component's parameter with field of the containing component. Or maybe this use of the "bind" concept is just not documented, or maybe I missed it in my search. Note that "ComponentDefaultProvider" is not named "ComponentDefaultParameterBinder" :-) On Mon, Aug 22, 2011 at 2:07 PM, Josh Canfield <joshcanfi...@gmail.com> wrote: > @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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
