lets discuss this when we start working on 1.5 -igor
On Thu, Apr 30, 2009 at 3:51 AM, Willis Blackburn <[email protected]> wrote: > 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 >>>>> >>>>> >>>> >>> >>> >> > >
