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 required in the docs - sometimes the code that supplied a good default value was added in later versions... perhaps that could be better addressed - what would you suggest? On Sun, Aug 21, 2011 at 04:50, Bob Harner <bobhar...@gmail.com> wrote: > 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 default encoder based on the bound type > of value. My brain is a little sleep-deprived, so maybe I'm just not > understanding how this really makes sense. > > On Sat, Aug 20, 2011 at 6:52 PM, Robert Zeigler > <robert.zeig...@roxanemy.com> wrote: >> 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've also bound the "value" parameter... which is usually). The >> components take advantage of the fact that if the user has bound the value, >> whatever type is bound must be universally applicable to all items in the >> list. >> >> Again, AjaxFormLoop already does this. There's no reason Palette couldn't >> do something like that as well.. supply the defaultEncoder based on the >> bound type of the value. >> I haven't looked over Checklist, but I suspect a similar case can be made >> there. >> >> Robert >> >> On Aug 20, 2011, at 8/206: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 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 parameter were principal. But what if you have different types of >>> objects in the list? >>> >>> On Sat, Aug 20, 2011 at 3:56 AM, Bob Harner <bobhar...@gmail.com> 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)? >>>> >>>> The following components nicely allow the "encoder" parameter to be >>>> optional: >>>> >>>> Grid, GridRows, Loop, Select, Upload: >>>> >>>> But the following make you provide the encoder parameter (even if you >>>> have a ValueEncoder configured in your AppModule for the appropriate >>>> type): >>>> >>>> AjaxFormLoop, Palette, Checklist, Hidden, RadioGroup >>>> >>>> Maybe there's some subtle reason for this? >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> >>> Igor Drobiazko >>> http://tapestry5.de >> >> >> --------------------------------------------------------------------- >> 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 > > -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Apache Tapestry PMC / http://chesstu.be owner Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
