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
de
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 wrote:
> Required means that the value is required for t
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 Harne
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
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,
On Mon, 22 Aug 2011 07:36:08 -0300, Massimo Lusetti
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
On Sun, Aug 21, 2011 at 2:20 PM, Bob Harner 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
> elsewhere". An
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???
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 cont
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 requ
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 def
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 you'
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" wrote:
> Checklist, Palette and AjaxFormLoop operate on a list of objects
> (SelectModel or Iterable) while the other component take only a single
> value. Providing a d
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 par
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 clas
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" param
16 matches
Mail list logo