Igor,
I'd be all for that. But there was a discussion in JIRA a few months
ago about how the data-array approach was more efficient in terms of
memory utilization.
https://issues.apache.org/jira/browse/WICKET-1862
Making the model visible through the public interface only in
subclasses but maintaining the reference itself in Component's data
array would be having the memory-savings cake and eating it too. Of
course anyone who wrote a subclass of Component would not be
*prohibited* from creating their own IModel field. So maybe for high-
usage components like Label, we take the Component-data-array
approach, while for other components, we create a field in the
subclass for clarity.
W
On Apr 28, 2009, at 1:23 PM, Igor Vaynberg wrote:
actually it wouldnt be stored in the data field, thats the great
advantage of it. you are forced to declare it with the correct type
and provide correct getters and setters
eg
class edituserpanel extends panel {
private imodel<user> model;
// getter setter
}
-igor
On Tue, Apr 28, 2009 at 3:19 AM, Willis Blackburn <[email protected]>
wrote:
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
