with generic when we get on the 1.5 trail (i think wicket 2.0) this
problem will vanish because we then have compile time checks on imodel
when needed.
The difference between swing en wicket sit in its core. In wicket all
components have a model. (Starting from component) this is not the case
in swing
And because of that to get or set an object from what ever component is
always the same.
For example populating form components can now always be done by
setModelObject() or validation will always work with getModelObject()
if this wasn't the case then we had to introduce another interface like
setValue and getValue which all the form components have to map to there
own models..
Also it is very easy now to have shared models over all components.
(like the PropertyModels or CompoundModels)
So i think in the end it isn't that bad. and the only strange onces are
the onces that need a specific object inside the imodel (Like List)
johan
Jonathan Locke wrote:
yeah, this would make a good FAQ entry. we struggled with naming this
class for quite a while and i can understand your unhappiness with the
name. unfortunately, i think it's too late to change this one now.
Christian Essl wrote:
Hi Juergen,
I think Wicket has a great design. Escpecially I like the use of
classes in favour of interfaces where no alternative implementations
are realy useful.
You mentioned you would simplifiy the API even further. You mentioned
IModel. Anything else that comes into your mind?
In the beginning I was also a bit confused of IModel. Trained from
Swing in my mind a model, was the 'data-store' for a component and
different components have different demands on their data and
'data-stores'.
I expected that a label would need something like getText(). A
TextField, TextArea something like setValue() and getValue(). So far
IModel works fine. However in my experience the model interface for
ListView should have looked different and for Trees, DropDownChoices
and Checkboxes it should again look different. For the later ones
IModel is more like an IModelProvider and this made the api a bit
indirect and unclear to me with my Swing background and at least
until generics are added.
I am sure you have your reasons to have a generic IModel interface
for all components. But maybe you could make the difference between a
Wicket model and a traditional Java model, and the reasons for this
difference more clear.
Thanks,
Christian
___________________________________________________________ Gesendet
von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
