On 9/28/05, Solovyev, Kirill <[EMAIL PROTECTED]> wrote: > > > > We have the following Use Case for the Shale Dialog Framework: > > > > Define all Application navigation through shale dialogs and use Custom > Application Level JSF Tab(Menu) Navigation component working on top of > Shale Dialog.
That's an interesting idea, and not one I would have contemplated. It's kind of outside the bounds of what Dialog was intended to support, but I guess that's the nature of the beast with general purpose frameworks. We propose the following enhancements for the shale framework: > > 1. We would like to enumerate over dialogs transitions (states) to > draw our tab menu. We think it would be a good idea for the Dialog > Interface to provide a readonly list view of transitions and states. > Currently, they can only be accessed by Name. That makes sense ... I'll add appropriate accessors. 2. We'd like Dialog artifacts (Dialog, Transition, and State) to > support custom attributes. In our Navigation Component, we need the > following attributes for Transition( Current Dialog transitions > represented by Tabs on page): > > 1. Order -Tab order(1,2,3...) > 2. Role Security- to Hide/Show Tab based on user role > permission Sean Schoefield is probably laughing at me as he reads this :-). He filed a Bugzilla issue asking for similar flexibility, and I've been pushing back on it without compelling use cases. You might want to keep an eye on: http://issues.apache.org/bugzilla/show_bug.cgi?id=36439 In particular, today you can couple the use of your own implementation classes for the dialog configuration objects (see next response) with creating a customized DTD that adds extra attributes to correspond to your extra fields. However, you might not want to expend that effort unless you're in a big hurry ... it's looking more and more reasonable to add a general mechanism to set properties on the configuration objects to the standard DTD. 3. Since all dialog artifacts are interfaces. Is it possible for us > to plugin our own implementations of the interfaces? Currently, the > only way we can find to do this is by using our own versions of > ConfigurationInit, ConfigurationParser(Digester Rules Code) and > inserting our implementation classes? Can this process be metadata > driven? You can already specify your own implementation classes for each configuration object ... use the "className" attribute on each element to specify the fully qualified class name of the class to use for that element. However, without an alternative DTD (or a general mechanism in the standard DTD), this won't help you set additional properties on your configuration objects, which would naturally be something you'd want to do for your use case. Thank you, > > > > Kirill Craig
