I am Eugene's co-worker. The entire code block would be unreasonable as it
contains alot of business rules that have nothing to do with the technical
issue. The basic code summary is this:
Inside a re-usable panel orgPanel:
final DropDownChoiceStructureL structureDropDown = new
final DropDownChoice struct = (DropDownChoice) orgPanel.get(StructureL);
This way you're breaking the encapsulation of orgPanel :(.
Why doesn't orgPanel offer the #onOfficeChange() hook in the first place?
Sven
On 03/25/2013 04:18 PM, Entropy wrote:
I am Eugene's co-worker. The entire
Yeah, that is what I do with my panels I write. In this case though, I'd
/RATHER/ just add the extra behavior because it means I don't have to alter
any of that orgPanel's code.
The panel build is done within a factory method and the inheritance and
design of it doesn't really make exposing
We have a large panel containing components with multiple Ajax behaviors.
In one context where this panel is used, we need to augment (add) the
existing AjaxBehavior of a certain component by adding extra functionality
to it. It seems that if we add it the usual way (add (new
Hi,
how does the additional behavior break the existing one?
We have a large panel containing components with multiple Ajax behaviors.
In one context where this panel is used, we need to augment (add) the
existing AjaxBehavior of a certain component by adding extra functionality
to it. It
For example, the Panel was showing/hiding some components inside itself,
based on the selection in those components; that was working correctly.
Right now, we're using the Panel on a separate page and have an external
component that needs to respond to the events in one of the Panel's
dropdowns.
Can you show some code or (better) can you replicate your problem in a
quickstart application? In your opinion which are the behaviors in conflict?
For example, the Panel was showing/hiding some components inside itself,
based on the selection in those components; that was working correctly.
