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