You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Solovyev, Kirill" <So...@peacetech.com> on 2005/09/28 17:29:05 UTC
[Shale Dialog suggestions]
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.
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.
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
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?
Thank you,
Kirill
Re: [Shale Dialog suggestions]
Posted by Duncan Mills <du...@oracle.com>.
On the security issue there is a project on SourceForge on this one now :
http://sourceforge.net/projects/jsf-security
I have a working implementation for some JSF EL extensions to allow
things like role evaluation. The initial version should be in CVS by the
end of the weekend. I just have to do a bit of work on the pluggability
aspects as we intend to make it possible to derive security information
from JAAS or elsewhere as well as Container Security.
Duncan
Alex Roytman wrote:
>Hello Craig,
>
>Thank you very much for considering our proposal. We feel that Shale can be a very good foundation for any number of light weight in-house specialized frameworks ranging from GUI components to persistence and transaction management aligned with dialog workflow system:
>
>
>Hear are some use cases which call for extension:
>- Security: declarative role based security, other security related attributes to be used at runtime to validate transition
>- GUI support: various attributes to facilitate presentation of dialogs and transitions ? presentation component, name, order, bubble help for actions (whether it is menu, list or tabs ?)
>- Transaction demarcation
>- Resource allocation/de-allocation on transition
>- Anything else which makes sense to be done on dialog system level rather then inside each specific dialog
>
>It would be nice to replace DTD with XML schema designed for extensibility and use name spaces for various extensions
>
>These use cases will produce metadata which will be
>- Centralized repository of state transitions and associated transaction, persistence, resource management rather then spread over many action classes
>- Can be easily visualized and reported from ? part of documentation
>
>
>
>As far as needed extensions I would say we need two levels ? firstly, slightly enhanced interfaces and default implementations should be considered metadata for several systems rather than a single locked down state machine (e.g. ability to specify attributes for each artifact) and secondly, ability to supply and instantiate custom implementations for various artifacts and instantiate them using digester
>
>Here are some examples
>
>1. Provide more flexible default implementation
> - Design for extensibility ? people will be extending them do not hide any useful methods but make them read-only instead. Please treat it as metadata on which not only state machine but other applications can be built
> - At building time dialog must be fully mutable (again no private methods) and then switched to read-only mode
> - Provide ability to specify attributes for each artifact of dialog system and make it part of the interface. Extend DTD to support it e.g.:
> <dialog ?>
> <attr name=?roles? value=?admin,manager? factory=?public static method to instantiate, String if omitted?/>
> <attr name=?transaction? value=?required?/>
> <attr name=?gui.? value=?required?/>
>
>2. Enhance ability to supply custom implementations for all dialog related artifacts
> - Allow specifying default implementations for various dialog related interfaces on document level to avoid endless class=??..? for each and every xml element retain ability to override defaults using class=??? attribute. It can take form of <implement interface=??? implementation=???/> at the top of metadata file
> - Expose digester and digester building process so additional digester instructions can be added. It would be great to achieve flexibility of Ant where any sub elements can be specified and realized as appropriate beans by ant content handler
>- Allow to build entire dialog system using API without need of XML
>
> Thank you very much for your help
>
>Alex Roytman
>Peace Technology
>
>
>-------------------------------------------------------------------
><a href="http://Struts_Developers_List.roomity.com">roomity.com</a>
>roomity.com is broadband internet. ~~1127945326258~~
>-------------------------------------------------------------------
>
>
>
--
Regards
Duncan Mills
Senior Principal Product Manager
Oracle Application Development Tools
Duncan.Mills@oracle.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re:[Shale Dialog suggestions]
Posted by Alex Roytman <ma...@roomity.com>.
Hello Craig,
Thank you very much for considering our proposal. We feel that Shale can be a very good foundation for any number of light weight in-house specialized frameworks ranging from GUI components to persistence and transaction management aligned with dialog workflow system:
Hear are some use cases which call for extension:
- Security: declarative role based security, other security related attributes to be used at runtime to validate transition
- GUI support: various attributes to facilitate presentation of dialogs and transitions ? presentation component, name, order, bubble help for actions (whether it is menu, list or tabs ?)
- Transaction demarcation
- Resource allocation/de-allocation on transition
- Anything else which makes sense to be done on dialog system level rather then inside each specific dialog
It would be nice to replace DTD with XML schema designed for extensibility and use name spaces for various extensions
These use cases will produce metadata which will be
- Centralized repository of state transitions and associated transaction, persistence, resource management rather then spread over many action classes
- Can be easily visualized and reported from ? part of documentation
As far as needed extensions I would say we need two levels ? firstly, slightly enhanced interfaces and default implementations should be considered metadata for several systems rather than a single locked down state machine (e.g. ability to specify attributes for each artifact) and secondly, ability to supply and instantiate custom implementations for various artifacts and instantiate them using digester
Here are some examples
1. Provide more flexible default implementation
- Design for extensibility ? people will be extending them do not hide any useful methods but make them read-only instead. Please treat it as metadata on which not only state machine but other applications can be built
- At building time dialog must be fully mutable (again no private methods) and then switched to read-only mode
- Provide ability to specify attributes for each artifact of dialog system and make it part of the interface. Extend DTD to support it e.g.:
<dialog ?>
<attr name=?roles? value=?admin,manager? factory=?public static method to instantiate, String if omitted?/>
<attr name=?transaction? value=?required?/>
<attr name=?gui.? value=?required?/>
2. Enhance ability to supply custom implementations for all dialog related artifacts
- Allow specifying default implementations for various dialog related interfaces on document level to avoid endless class=??..? for each and every xml element retain ability to override defaults using class=??? attribute. It can take form of <implement interface=??? implementation=???/> at the top of metadata file
- Expose digester and digester building process so additional digester instructions can be added. It would be great to achieve flexibility of Ant where any sub elements can be specified and realized as appropriate beans by ant content handler
- Allow to build entire dialog system using API without need of XML
Thank you very much for your help
Alex Roytman
Peace Technology
-------------------------------------------------------------------
<a href="http://Struts_Developers_List.roomity.com">roomity.com</a>
roomity.com is broadband internet. ~~1127945326258~~
-------------------------------------------------------------------
Re: [Shale Dialog suggestions]
Posted by Sean Schofield <se...@gmail.com>.
> 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
I don't know about laughing at you ... more like "I told you so" ;-)
Obviously we could write our own configuration stuff but the existing
configuration code is 99.9% of what we need so that seems like a
shame. I will continue to try and play with specifiying the DTD in my
XML to see if I can get that to work (although I've had problems so
far.)
If that ends up working, then there's no need for modifying Shale.
BTW, is it possible that Shale is overriding the DTD that I specify in
my XML?
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Shale Dialog suggestions]
Posted by Craig McClanahan <cr...@apache.org>.
On 9/28/05, Solovyev, Kirill <So...@peacetech.com> 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