Re: 1.4.16 - adding methods to IBehavior
why not just introduce that interface and the impl in component? So why also alter abstract behavior? Because that would mean that suddenly almost all the behaviors that are used are suddenly also IComponentConfigurationBehavior And 99.9% of them don't do anything. On Sat, Feb 19, 2011 at 04:17, Jeremy Thomerson wrote: > What does everyone think about the following patch [1] to add two methods to > IBehavior? Obviously, it's not added directly to IBehavior since that would > be a breaking API change. It's added to a sub-interface that can optionally > be implemented by IBehaviors and is implemented by AbstractBehavior by > default. > > It's for the purpose of allowing behaviors to contribute to things like the > visibility and enabled status of a component, which they can't currently do > in beforeRender because that happens during the render cycle, at which time > such changes are not allowed. > > [1] - http://mysticpaste.com/view/8231 > > -- > Jeremy Thomerson > http://wickettraining.com > *Need a CMS for Wicket? Use Brix! http://brixcms.org* >
Re: 1.4.16 - adding methods to IBehavior
Hi Jeremy, That sounds nice. I think this can be used to implement the wicket:for attribute (to automatically set the 'for' attribute on 'label' tags) in a reasonably elegant way. Though this might not be what you had in mind :) Regards, Erik. Op 19-02-11 04:17, Jeremy Thomerson wrote: What does everyone think about the following patch [1] to add two methods to IBehavior? Obviously, it's not added directly to IBehavior since that would be a breaking API change. It's added to a sub-interface that can optionally be implemented by IBehaviors and is implemented by AbstractBehavior by default. It's for the purpose of allowing behaviors to contribute to things like the visibility and enabled status of a component, which they can't currently do in beforeRender because that happens during the render cycle, at which time such changes are not allowed. [1] - http://mysticpaste.com/view/8231 -- Sent from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: 1.4.16 - adding methods to IBehavior
I suppose it could, although I hadn't really thought about that part of it. I'm not sure that would be a wise idea, but we're not blocking it that I know of. On Sun, Feb 20, 2011 at 10:45 PM, Clint Checketts wrote: > So in theory a behavior implementing this could add additional > components to the page? Or is the hierarchy frozen at this point? > > On Friday, February 18, 2011, Jeremy Thomerson > wrote: > > What does everyone think about the following patch [1] to add two methods > to > > IBehavior? Obviously, it's not added directly to IBehavior since that > would > > be a breaking API change. It's added to a sub-interface that can > optionally > > be implemented by IBehaviors and is implemented by AbstractBehavior by > > default. > > > > It's for the purpose of allowing behaviors to contribute to things like > the > > visibility and enabled status of a component, which they can't currently > do > > in beforeRender because that happens during the render cycle, at which > time > > such changes are not allowed. > > > > [1] - http://mysticpaste.com/view/8231 > > > > -- > > Jeremy Thomerson > > http://wickettraining.com > > *Need a CMS for Wicket? Use Brix! http://brixcms.org* > > > -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: 1.4.16 - adding methods to IBehavior
So in theory a behavior implementing this could add additional components to the page? Or is the hierarchy frozen at this point? On Friday, February 18, 2011, Jeremy Thomerson wrote: > What does everyone think about the following patch [1] to add two methods to > IBehavior? Obviously, it's not added directly to IBehavior since that would > be a breaking API change. It's added to a sub-interface that can optionally > be implemented by IBehaviors and is implemented by AbstractBehavior by > default. > > It's for the purpose of allowing behaviors to contribute to things like the > visibility and enabled status of a component, which they can't currently do > in beforeRender because that happens during the render cycle, at which time > such changes are not allowed. > > [1] - http://mysticpaste.com/view/8231 > > -- > Jeremy Thomerson > http://wickettraining.com > *Need a CMS for Wicket? Use Brix! http://brixcms.org* >
