I did look at the demo Geoff posted. How is that going to provide what I
need? I'm sorry, but I fail to see this "easy fix" you mentioned. Maybe you
can be a bit more specific?
On Thu, May 13, 2010 at 1:15 PM, Christian Riedel
<cr.ml...@googlemail.com>wrote:
> Well I agree that some more extensibility could be made here and there.
> That particular problem looks like it's worth a JIRA with a patch from you
> that makes the component extensible to fix that problem :)
>
> On the other hand there is an easy fix. Just look at the demo Geoff posted.
> Why do you insist on the BlankOption thing? Just add your blank option
> directly to the list select-options. Then there is no blank option at all...
>
>
> Am 13.05.2010 um 16:43 schrieb Benny Law:
>
> > 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
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
