Re: [Shale Dialog suggestions]

[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