Re: Palette and Checklist don't use contributed value encoder?

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

Re: Palette and Checklist don't use contributed value encoder?

On Sun, Aug 21, 2011 at 2:20 PM, 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

Re: Palette and Checklist don't use contributed value encoder?

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

Re: Palette and Checklist don't use contributed value encoder?

I agree with Bob on this point. IMHO a parameter is 'required' if you must provide a value. In case tapestry will provide a default value, we can keep it optional with a comment, Default value will only be used if found/contributed ... But as far as correct English and developers are concerned,

Re: Palette and Checklist don't use contributed value encoder?

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

Re: Palette and Checklist don't use contributed value encoder?

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

Re: Palette and Checklist don't use contributed value encoder?

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

Re: Palette and Checklist don't use contributed value encoder?

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

Re: Palette and Checklist don't use contributed value encoder?

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???

Re: Palette and Checklist don't use contributed value encoder?

Checklist, Palette and AjaxFormLoop operate on a list of objects (SelectModel or Iterable) while the other component take only a single value. Providing a default ValueEncoder would mean that you need to get the first element in the list and check its type. This would probably work if the model

Re: Palette and Checklist don't use contributed value encoder?

A list with mixed types seem like an edge case well worth ignoring, right? Bob Harner On Aug 20, 2011 7:54 AM, Igor Drobiazko igor.drobia...@gmail.com wrote: Checklist, Palette and AjaxFormLoop operate on a list of objects (SelectModel or Iterable) while the other component take only a single

Re: Palette and Checklist don't use contributed value encoder?

Um... last time I checked, Grid, GridRows, and Loop all operate on lists of objects, so if this is the argument, then the philosophy is inconsistently applied. In fact, Grid makes it's determination based on the row parameter. And AjaxFormLoop /does/ provide a default value encoder (iff

Re: Palette and Checklist don't use contributed value encoder?

Apart from the question of why Palette and Checklist don't yet support a default encoder, 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

Re: Palette and Checklist don't use contributed value encoder?

I remember having the same question when documenting some T4 components way back! Many had required parameters, but if you didn't supply one, Tapestry would supply a default value - so, to the user they really looked as non required parameters. In any case, it was then decided to mark them an

Palette and Checklist don't use contributed value encoder?

Does anyone know why half of the built-in Tapestry 5 components that take an encoder parameter are NOT set up to be able to use a contributed ValueEncoder (that is, one configured with contributeValueEncoderSource() in AppModule class)? The following components nicely allow the encoder parameter

Re: Palette and Checklist don't use contributed value encoder?

On Aug 19, 2011, at 8/198:56 PM , Bob Harner wrote: Does anyone know why half of the built-in Tapestry 5 components that take an encoder parameter are NOT set up to be able to use a contributed ValueEncoder (that is, one configured with contributeValueEncoderSource() in AppModule class)?