Thanks Geoff, but no, it doesn't. Your example shows how the Select
component works as is. What I need is a smarter interpretation of
BlankOption.AUTO. Basically, if you look at the showBlankOption() method in
the Select class, you see this:
switch (blankOption)
{
case ALWAYS:
return true;
case NEVER:
return false;
default:
return !isRequired();
}
What I want is this:
switch (blankOption) {
case ALWAYS:
return true;
case NEVER:
return false;
// AUTO: Decide based on model size, current value, and required or
not.
default:
List<OptionModel> options = model.getOptions();
if (options.size() == 1) {
return !isRequired();
}
if (options.size() == 0 || value == null) {
return true;
}
if (value != null) {
for (OptionModel option: options) {
if (option.getValue().equals( value )) {
return !isRequired();
}
}
}
return true;
}
I hope it's clear what I want to achieve with the enhanced logic for AUTO.
Regards,
Benny
On Thu, May 13, 2010 at 10:29 AM, Geoff Callender <
geoff.callender.jumpst...@gmail.com> wrote:
> Does this help at all?
>
>
> http://jumpstart.doublenegative.com.au/jumpstart/examples/select/varied/$N/$N/$N/$N
>
> Cheers,
>
> Geoff
>
> On 14/05/2010, at 12:11 AM, Benny Law wrote:
>
> > We are talking about subclassing a Tapestry component here. To give you
> an
> > example, I wanted to subclass the Select component to override how
> > BlankOption.AUTO is interpreted. I wanted the logic to not just look at
> the
> > required property but also to consider how many options are available and
> > whether there is a current value. (I find the current logic lacking
> because,
> > for example, the first option will always be selected as default if
> required
> > is true, but there may not be a meaningful default for the field.) All I
> > needed to do was to override the showBlankOption() method, but I couldn't
> > because it's a private method. I ended up making a duplicate of the
> Select
> > component with a modified showBlankOption() method. It just didn't feel
> > right. I don't think all this talk about capturing common logic in a base
> > class or creating a service for it applies here.
> >
> > In my opinion, a good framework should provide the option for extending
> its
> > components easily. I believe that with proper design and careful
> > consideration, inheritance can still be very useful. Developers should
> > understand any potential risks involved in subclassing, but closing the
> door
> > to subclassing for the sake of backward-compatibility may be an overkill
> > IMHO. Everything has pros and cons, and the developer is ultimately
> > responsible for weighing them and choosing what's best for their
> situation.
> >
> > BTW, if anyone can think of a clean way to solve my problem with the
> Select
> > component, please let me know. Thanks.
> >
> > Benny
>
>
