|
My proposal would be to supply the mechanism for applications to provide their own dialog aware buttons. In other words, provide a hook for EL expressions so you can have something like:
<h:commandButton action"next" value="Next" rendered="#{someBean.isNextAvailable}"/> This way we don't have to be involved with the look and feel of buttons, etc. We just provide an easy way for developers to design their own. If the ability to determine whether the buttons should be rendered became available, it would be easy to provide your own reusable button panel and layout using Tiles, Facelets, Clay or whatever. The new event handling support addresses the requirement to provide an application with enough information to support this feature. If you make the "data" object you provide implement DialogContextListener, it will be automatically registered as a listener for interesting events, including state transitions within the dialog. In turn, this makes it very easy for the dialog to provide boolean functions to which you can bind, say, the "rendered" or "disabled" properties of the navigation buttons in the view, since only the application can tell you for sure whether a particular control should be rendered (or disabled) or not.
For use cases where a common pattern is implemented (such as "wizard dialogs"), it is straightforward for the application developer to provide a common base class for "data" beans that implements the common behavior for first/previous/next/last type controls, or the like. |
||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Minor
[shale] Create "Dialog Aware" button panel component
from being "another library of JSF components", but components that tie directly
to framework features are still fair game.