My thoughts: leave the Model interface and *add* a DefaultModel
to be extended. You get the best of both worlds.
Gili
On Mon, 28 Feb 2005 22:21:32 +0100, Eelco Hillenius wrote:
>The models keep giving problems. Though a powerfull concept, they are
>not perfect yet.
>
>The problem was: as attach() was called in Component.getModel(), it was
>never called for models that were not coupled to components, or that
>were called directly (e.g. when a component holds a reference to the
>model directly itself).
>
>The problem now is: as the calling of attach() is now put in
>AttachableModel.getObject(), the models are not attached automatically
>when a client overrides getObject(). So he has to call attach himself,
>or we should call attach from both Component.getModel() and
>AttachableModel.getObject().
>
>This clearly isn't very nice either.
>
>Maybe we should make it all much simpler. I propose:
>
>1. Loose the interfaces. The starting point is just one Model base class
>that is smart enough to attach itself. Detaching still has to come from
>outside... I can't think of anything nice here (note that if you don't
>couple a model class to a component it will never be detached for you).
>
>2. Model could look like:
>
>public class Model extends AbstractModel
>{
> private Serializable object;
>
> private transient boolean attached = false;
>
> public Model()
> {
> }
>
> public Model(final Serializable object)
> {
> this.object = object;
> }
>
> public final Object getObject()
> {
> attach();
> return doGetObject();
> }
>
> public Object doGetObject() // or any other name; but this one is
>overridable
> {
> return object;
> }
>
> public final void setObject(Object object)
> {
> doSetObject(object);
> }
>
> public void doSetObject(Object object)
> {
> if (object != null)
> {
> if (!(object instanceof Serializable))
> {
> throw new WicketRuntimeException("Model object must be
>Serializable");
> }
> }
>
> setObject((Serializable)object);
> }
>
> public void setObject(Serializable object)
> {
> this.object = object;
> }
>
> public final void attach()
> {
> if (!attached)
> {
> onAttach();
> attached = true;
> }
> }
>
> public final void detach()
> {
> if (attached)
> {
> onDetach();
> attached = false;
> }
> }
>}
>
>Having this class would be enough for most uses. For advanced uses we
>can still have NestedModels etc.
>
>I think having interfaces do not add much to the fun here. Sure it's
>nice for users to be able to implement models with their own root
>inherritence, but it's even better not to have to worry about attaching.
>And, as you can allways write wrappers and such, it's not that by not
>having interface we restrict users.
>
>Thoughts?
>
>Eelco
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Wicket-develop mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
