Igor, I wonder if this may actually be an indication that Component is in fact being used as a convenience for implementation inheritance rather than as a clean, cohesive abstraction and true super type? And, maybe the name is not exactly representative of what Component currently is. But, it is so well accepted and ingrained that it may be hard to think of things being different at such a fundamental level.
Maybe in 1.5 we can have 2 (I think) interfaces that "Component"s that do have models implement; one for components that have models because they use them and a second for components that just carry a model around for their children eg as a CPM for the kids (CPM is a indeed a nice convenience to reduce code but these conveniences/shortcuts for application developers are probably one of the root causes of some uncomfortable design decisions). Some components may implement both interfaces. The level at which these interfaces are introduced into the hierarchy would be the interesting question in such a design (even architectural) refactoring. Clearly this all would need to be properly thought through and it could potentially break quite a lot of stuff, but not necessarily if the right bits are pulled out of Component (or whatever it becomes called), up or sideways, and introduced high enough above "concrete" components. Do you think it makes any sense? Regards - Cemal http://jWeekend.co.uk igor.vaynberg wrote: > > all components have a "default" model slot. this model is not used by > the component, it is just a container that is provided that provides > convinience such as detaching, etc. > > compare a webmarkupcontainer to a formcomponent: > > webmarkupcontainer does nothing with the model, but it is convinient > to still have a slot so users can easily set a model used by > subclasses or other usecases. > > formcomponents actually use their model, eg they do not work without > it, thus they have a get/setmodel methods (in addition to > get/setdefaultmodel). in a formcomponent get/setmodel, however, are > generified because that information is known and useful. > > in an ideal world we would not have the default model slot. you would > simply create an imodel field for a component if it needed a model, > but because of the way our compound models work this is a bit > tricky...something to think about for 1.5. > > -igor > > On Thu, Aug 28, 2008 at 7:30 AM, jWeekend <[EMAIL PROTECTED]> > wrote: >> >> In Wicket 1.4m3, what does the "Default" in Component's new >> getDefaultModel() >> method mean. >> I don't want to reignite the generics debate; this is just a question >> about >> good naming. This name makes it sound like all components are initialised >> with a "default" model in place, or it could possibly be >> taken/interpreted >> in other, misleading/confusing ways. >> >> Regards - Cemal >> http://jWeekend.co.uk http://jWeekend.co.uk >> -- >> View this message in context: >> http://www.nabble.com/getDefaultModel-tp19201841p19201841.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> 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] > > > -- View this message in context: http://www.nabble.com/getDefaultModel-tp19201841p19204284.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
