Igor,
I'm glad to hear that!
I hadn't thought of removing the IModel reference from Component, but
that's a good idea. I think that you'd want to keep the model
reference itself inside Component, using the data field as it exists
now, but make the access methods protected.
My original thought a few days ago was that Component should implement
IModel. In other words, make models *optional*. If an app needs an
IModel instance (because the model is detachable or dynamic), then it
uses one, otherwise it just stores the model object itself in
Component's data field. That would eliminate the need to create lots
of plain vanilla Model instances and save memory. However, I tried to
implement this and ran into lots of issues, the least of which is that
Component doesn't know what class of model object its subclasses will
use.
The reason for having Component implement IModel is so that when the
code requires an IModel, the component can stand in. But maybe that's
not necessary. Maybe what would be better is to simply eliminate the
assumption that IModel is necessary for anything. So Component (or a
subclass) is backed up an an object, the class of which depends on the
component, and which may (at runtime) actually be an IModel instance.
Anyway if there are no objections I'd like to add this to the Wiki as
a discussion for 1.5?
W
On Apr 26, 2009, at 1:18 PM, Igor Vaynberg wrote:
actually in 1.5 i was hoping to find a way to get rid of
icomponentassignedmodel or any other automatic model wrapping voodoo.
the idea is that if a user needs a model they add their own imodel<t>
field. this will get rid of the generic mess surrounding
getdefaultmodel/getmodel, etc. so a component wont have a default
model slot any more.
not sure if it will work, but this is something i want to try. so a
heads up.
-igor
On Sun, Apr 26, 2009 at 6:24 AM, Willis Blackburn <[email protected]>
wrote:
Wicket developers,
I've been experimenting with some changes to Wicket's model
handling for a
future release and would like to start a discussion, maybe on the
Wiki page?
But I wanted to run it by you all first to get your opinions.
I have two ideas.
My first idea is to refactor IComponentAssignedModel+IWrapModel.
IComponentAssignedModel is not really a model: it's a model
factory. When
the application passed one to a component, it's the factory-
generated model
that's actually used.
The problem is that developers have to consider
IComponentAssignedModel
every time they use IModel. Every IModel instance must be
"wrapped" before
it can be used because it might be IComponentAssignedModel. This
goes
against the spirit of IModel being a simple indirection interface.
I think something like an IComponentAwareModel with a single method,
setComponent, would work better. The model would be simply
associated with
its component, rather than being used as a factory to generate the
real
model. All IModel references would refer to valid models, even if
they have
not yet been associated with a component. Chained models would
implement
IComponentAwareModel and pass the component to their inner models.
I realize that this change might require some applications to
instantiate a
separate model for each component rather than use the "same" model
over and
over, but that's what's happening behind the scenes anyway. It
doesn't seem
like an onerous change. After all the app is already instantiating
the
components.
I implemented this in a copy of the Wicket 1.4 trunk. It only took
about an
hour, and all of the unit tests passed.
My second idea is to move the IComponentInheritedModel-searching
logic from
Component into an actual IModel implementation. That would allow
applications to *explicitly* assign the searching functionality to a
component, rather than have it implicitly invoked in initModel when
the
component has no model. This is important because currently, the
searching
logic only runs if initModel is actually called.
What I'm trying to do is develop complex, reusable components that
instantiate all of their child components in the constructor. This
is
tricky because in the constructor, the component does not yet know
what its
parent will be, and it may not even know what its model will be. I
want to
allow users of my components to use them as they would labels:
they should
be able to provide an explicit model, or provide no model and have
the
component inherit a model. But because my components are complex
and have
lots of child components, I don't want to explicitly assign a model
to each
child component. I want to wrap the component's model in
CompoundPropertyModel. The two changes that I've suggested would
make it a
lot easier to build complex components in this manner.
Sorry so long. :-)
Regards,
Willis
