Why are you wanting to change the "auto" behavior in the first place?
In the few cases where there is no "sensible" default value, is using the
"blankLabel" and "blankOption" parameters so excruciatingly onerous? If so, why
not not simply wrap the select component in a custom select component that
provides the values you want? You would have to provide parameters in your
wrapper that passed through to the underlying select, but this is certainly
doable.
In fact, this particular case could be handled (I think?) in 5.2 in a very
clean way. 5.2 introduces the possibility for mixins to bind and manipulate
the containing component's parameters. So you could, in theory, write a mixin
that sets the appropriate values for you. Basically, you would have something
like this:
public class Blank {
@BindParameter
private boolean required;
@BindParameter
private BlankOption blankOption;
@BindParameter
private blankLabel blankLabel;
void beforeRender() {//this will happen before the select's before render...
if (//whatever condition you want....) {
blankOption=ALWAYS;//we've now overridden the default check in
showBlankOption() b/c by the time that renders, showBlankOption will see
"blankOption" as being ALWAYS instead of AUTO.
blankLabel="Select one...";
} else {
blankOption=NEVER;
}
}
}
Which you could then use like:
<t:select ... t:mixins="blank"/>
which seems very non-onerous to me. :)
Robert
On May 13, 2010, at 5/1312:56 PM , Benny Law wrote:
> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
