-
FEATURED COMPONENTS
First time here? Check out the FAQ!
Don't know whether you'll share my feelings, but I like the BindComposer how it binds the fields with the values of the components, and sometimes there is a need to work with components and being able to change them or get information from them. So the best solution I see at the moment is to use SelectorComposer instead. But I think it would be really great for BindComposer to be able to wire the components as well, and being able to invoke @Listeners also which results in some hybrid.
Is it possible in future releases to have such types of composers being decorated with the ability of other composers? I think this would be a great feature for ZK to have.
If it's possible, ZK developers can create a new Feature in the JIRA and people will vote for it if they think it's a good idea.
Check this. http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/MVVM/Advance/Wire_Components
you could also wire the listener by Selects utility.
Beware of mixing components that controlled by both binder and you code.
Just my two cents: I also had bad experience with mixing data binding and direct component access in ZK5 days.
Until now, I could completely live with BindComposer without wiring components.
Could explain your use case where you need direct component access?
Maybe there is a cleaner solution for that, e.g. you can already get the "relevant" component of a command from the BindContext.
Another side note, more directed to the ZK people: I do not see the big value of SelectorComposer over the good old GenericForwardComposer. Is there some material available which explains why I should use SelectorComposer for "old style" ZK implementation?
My use case is next: I have a layout where there is some menu to the left and a working area. When user presses some of the item, there should a respective panel be shown in the main area where he'll perform his main functions. In order to do this I have a main dispatcher that places respective ZUL inside of the working area which requires this working area to be available as a component.
If you have better solutions, would be great if you share them :)
I had a similar scenario. The working area was a "div" and I called createComponents() to load sub-pages.
But for this use case I didn't even wire the components. I simply did something like
Component central = Path.getComponent("/mainwin/central"); Executions.createComponents(zulFile, central, args);
Asked: 2012-02-20 15:18:13 +0800
Seen: 610 times
Last updated: Feb 21 '12