I can definitively see the problem here, and I think Button should
better *never* use any compound model. What crazy usecase would it be
that you want to set the button's label based on the property of some
object? *If* someone would have that crazy use case, let him just
provide an explicit model to do that.
I propose to override initModel in Button and leave it blank, and
adjust the javadocs so that we are clear about it.
Eelco
On 3/13/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Why not just give youre button and empty model?
> If you really don't want it to use the model value of youre compound.
>
>
> johan
>
>
>
> On 3/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I'm using the standard Wicket and custom components (from extensions and
> written by me) and I've never run into a similar problem.
> CompoundPropertyModels are a great concept and I see no 'danger' in them.
> >
> > The problem with Button is its missing definition: does it use its Model
> for the value attribute or does it not?
> >
> > Sven
> >
> > >imho, this is an inherent danger of using compound property models.this
> >can happen with more components then just the button. any
> >reusablecomponent that you put into the form might inherit a model >without
> yourealizing. imho you just have to watch out for stuff like >that.
> > >
> > >-Igor
> > >
> > >>On 3/12/06, Sven Meier <[EMAIL PROTECTED]> wrote:This week I ran into a
> >>problem, where a button suddenly changed its
> > >>inscription which was supposed to be specified in the HTML template.
> > >>
> > >>Reason for this was that we added a new property to one of our model
> > >>objects. We're using CompoundPropertyModels (who doesn't?) and the value
> > >>of the property was rendered because as chance would have it the button
> > >>has an identical wicket:id :(.
> >
> > >>I found the origin of this unexpected behavior in
> > >>Button#onComponentTag(ComponentTag) :
> > >>
> > >> try
> > >> {
> > >> String value = getModelObjectAsString();
> > >> if (value != null && !"".equals(value))
> > >> {
> > >> tag.put("value", value);
> > >> }
> > >> }
> > >> catch (Exception e)
> > >> {
> > >> // ignore.
> > >> }
> > >>
> > >>IMHO this code is problematic in either way:
> > >>- if the value attribute should stay untouched as specified in the HTML,
> > >>you carefully have to watch out for collision of property name and
> >>wicket:id
> > >>- if the value attribute should be generated, you won't get an error if
> > >>the property is misspelt.
> > >>
> > >>I propose to formalize the behaviour of Button with a new method, say:
> > >>
> > >> Button#setOutputMarkupValue(boolean)
> > >>
> > >>If you wonder, the name of this method was inspired by
> > >>Component#setOutputMarkupId().
> > >>
> > >>What do you think?
> > >>
> > >>Sven
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > that extends applications into web and mobile media. Attend the live
> webcast
> > and join the prime developer group breaking into this new coding
> territory!
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
