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
>>>
>>>
>>
>
>
