On Wed, Jul 2, 2008 at 4:28 AM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote: > On Tue, 01 Jul 2008, Matej Knopp wrote: >> There is one thing that helped me quite a lot when migration the >> project I'm working out. I've created GenericPanel, >> GenericWebMarkupContainer and GenericFragment classes. In most cases >> the only change was renaming Panel<MyClass> to GenericPanel<MyClass>. > > Maybe the names could be TypedPanel / ModelContainingPanel > or something like that? I still don't see what's wrong with GenericPanel. It's certainly much easier to type than ModelContainingPanel. > > Or maybe start with the original component name so that they > would pop up more easily in the IDE, for example > PanelWithType / PanelWithModel? > >> I was wondering, even though those classes were farily simple, we >> might want to include them in Wicket anyway, for the sake of >> consistency and convenience. > > I thought about this and I think that it might be better to > not include them after all. In 1.5 it would be great to > separate IModel and Component more thoroughly, getting rid > of the defaultModel* accessors. Then it would make less > sense to have the convenience classes with those model and > modelObject accessors. I strongly disagree. There are good reasons for Wicket to bind model and component together and I think what we have in 1.4 right now is a balanced compromise. Also if we don't provide the convenience classes people will bound to write their own (because it's the only reasonable way to migrate project that already uses generics).
> > In cases where two components share the same model, it would > make sense to make the IModel field in each component final. > Then setModel() does not make sense any more; all it could > do would be throw an exception or be a confusing no-op. > Likewise, sometimes you never do setModelObject() or > getModelObject() from outside the class. You don't have to use those methods, there are for convenience only. > > Leaner APIs and less methods per objects are good things. > Hence it's better to add methods as you need them, instead > of providing a lot of convenience stuff that is only used a > part of the time. Surely each Component subclass has anyway > a lot of methods, and MarkupContainers even more, but you > have got to start somewhere :) I don't buy this. Our components have a lot of methods, but most of them are not part of public API. I plan to prefix those methods with a common prefix for 1.5 so they don't confuse regular users. But I really don't see how removing four methods (*defaultModel) improves our api. We will always need some kind of utility methods for manipulating models in component. Models have always been conceptually bound to component. Right now the problem of our API is not that we have a model slot in component. It is that we have exactly one model slot. This doesn't work well for all components, since some don't need model at all and some need more than one. Unfortunately the component <-> model contract is quite complicated as we have compound models, componentassignedmodels, etc so a simple property for model doesn't really cut it. We still need some kind of model manipuation methods. Something like current setDefaultModel,... but more flexible. And when we do have it, having GenericPanel,Fragment,... might make the migration for users lot esier. Now thinking about it, the name should really suggest that there is one model per component. Maybe PanelWithModel could be the name after all :) -Matej > > This is not a big deal though, either way is fine by me. > > Best wishes, > Timo > > -- > Timo Rantalaiho > Reaktor Innovations Oy <URL: http://www.ri.fi/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
