getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.
Eelco
On 1/23/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> it would be Component.getModelValue() not Component.getModelObject() i
> think. what this disambiguates is what object you are referring to. the
> problem is that IModel impl itself is an object, so when you say
> component.getModelObject () what do you really want? the model object or the
> object inside the model object?
>
> -igor
>
>
> On 1/23/07, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> >
> > I voted -1, but here is my opinion about the change proper.
> >
> > > public interface IModel<V> extends IDetachable
> > > {
> > > V getValue();
> > > void setValue(V value);
> > > }
> >
> > This would be for the better imo, though I don't hate the original
> > getObject *that* much. It's just what you are used to and I think
> > documentation on how models should be used is a lot more important.
> >
> >
> > > we would also change getModelObject() to getValue() as well as any other
> > > related methods like getModelObjectAsString() to getValueAsString() (or
> > > valueAsString() if preferred). there might be naming conflicts
> somewhere or
> > > other problems, but i don't know of any offhand.
> >
> > Tbh, I actually don't think Component#getValue is for the better. I
> > think Component#getModelObject is way clearer than Component#getValue.
> > In the end I think both value and object are ambiguous, and this
> > should be fixed by documentation and examples.
> >
> > Btw, If there is *anything* I never liked about the whole model
> > business, it is the fact that Component has methods to get the model
> > value in the first place (getModelObject etc).
> >
> > The indirection that IModel provides is something to get used to. It
> > is one of the places where we traded clarity and simplicity for
> > flexibility. I think it'll be hard to grasp for newbies no matter the
> > naming, so the better our documentation and examples are, the quicker
> > they will be able to wrap their head around it.
> >
> > Eelco
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
