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 jer...@wickettraining.com 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
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 jer...@wickettraining.com 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
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 checke...@gmail.comwrote: 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 jer...@wickettraining.com 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
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/
1.4.16 - adding methods to IBehavior
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*
