this looks very promising!!
that is what I was asking for and would solve at least my problem :)
So with mixins you do/can not override a method, you build a execution
chain instead?
Andreas
Robert Zeigler wrote:
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
