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
