On 9/25/06, Ingo Düppe <[EMAIL PROTECTED]> wrote:
We are just shaking down some big improvements and bugfixes in the Dialog stuff ... if you want to try it, grab the shale-dialog2 and shale-dialog2-legacy modules from the "sandbox" directory under the nightly builds. This will likely get pushed back into the main codeline (replacing the current dialog implementation) fairly quickly.
The dialog feature does indeed give you the opportunity to save state for the duration of a dialog, which will typically be longer than a request but shorter than a session. The place you store this state is referenced in an _expression_ by "#{ dialog2.data}" (will be "#{dialog.data}" once it goes back into the main codeline. By default, Shale provides you a Map instance here, so you can do simple name/value pairs. However, it will also be common practice for the authors of dialogs to provide a custom JavaBean that has all the relevant properties you want to keep track of. This is easier ( i.e. less error prone) than using map keys to retrieve the values -- plus you can take advantage of the fact that JSF will do conversions for you automatically.
The "shale-test-dialog2-legacy" module is a simple webapp with a wizard dialog, which illustrates using this approach. It addresses many of the outstanding bugs in the original implementation (you can have multiple dialogs active in different frames and windows, even multiple instances of the same dialog definition) plus adds a feature designed to support popup windows that can pull data from their parent, do some stuff, and then push data back again.
Conceptually, this is somewhat similar to Seam's conversations, although the technical details of how you do things is quite a bit different. In Seam, you start a conversation by executing an action method with a particular annotation, and the conversation stays active until you execute an action method with a different annotation to end it. State is kept (generally) in a stateful session bean, although this is not required. Seam doesn't really have the concept of an external configuration for a state machine underneath the dialog, but it shares the ability to have multiple conversations active at once.
In general, security frameworks that try to mimic container managed security only do their checks on the initial request URI, not on RequestDispatcher.forward() calls. A couple of approaches to consider:
* If you are running on a Servlet 2.4 or later container,
you can configure the filter to run on forwards as well
as the initial request. I don't know if AcegiSecurity is
set up to work in this manner, but it's worth a try.
* Conceptually, it sounds like you are trying to apply
access control on the destination of a navigation rule.
One way to implement this might be to do a custom
NavigationHandler that delegates to the standard one,
then examines the new viewId and sees if it is acceptable
for this user.
I know Spring works fine with Shale. I've heard scattered reports of problems with Facelets, and that's high on my list of things to evaluate. I haven't tried AcegiSecurity yet, but there's nothing in Shale that should make it work any differently than it does with MyFaces directly.
Lastly, now that MyFaces 1.1.4 is out, we will be testing and updating the dependency (for the nightly builds of Shale) to use 1.1.4 instead of 1.1.1 --- so that will get a lot of attention. (Shale doesn't care what component library you use, so Tomahawk shouldn't be an issue unless it does wierd things with some of the JSF extension points.)
Well I guess you are totally right. I have to rethink my design and
maybe I should take a deep look at shale. What is your opinion, is shale
production ready, cause I'm in a really tight time schedule. Does the
Dialog feature safe the state over several request, for instance for a
registration process that exists of several pages(views). Is it similar
to the conversation scope of jboss seam?
We are just shaking down some big improvements and bugfixes in the Dialog stuff ... if you want to try it, grab the shale-dialog2 and shale-dialog2-legacy modules from the "sandbox" directory under the nightly builds. This will likely get pushed back into the main codeline (replacing the current dialog implementation) fairly quickly.
The dialog feature does indeed give you the opportunity to save state for the duration of a dialog, which will typically be longer than a request but shorter than a session. The place you store this state is referenced in an _expression_ by "#{ dialog2.data}" (will be "#{dialog.data}" once it goes back into the main codeline. By default, Shale provides you a Map instance here, so you can do simple name/value pairs. However, it will also be common practice for the authors of dialogs to provide a custom JavaBean that has all the relevant properties you want to keep track of. This is easier ( i.e. less error prone) than using map keys to retrieve the values -- plus you can take advantage of the fact that JSF will do conversions for you automatically.
The "shale-test-dialog2-legacy" module is a simple webapp with a wizard dialog, which illustrates using this approach. It addresses many of the outstanding bugs in the original implementation (you can have multiple dialogs active in different frames and windows, even multiple instances of the same dialog definition) plus adds a feature designed to support popup windows that can pull data from their parent, do some stuff, and then push data back again.
Conceptually, this is somewhat similar to Seam's conversations, although the technical details of how you do things is quite a bit different. In Seam, you start a conversation by executing an action method with a particular annotation, and the conversation stays active until you execute an action method with a different annotation to end it. State is kept (generally) in a stateful session bean, although this is not required. Seam doesn't really have the concept of an external configuration for a state machine underneath the dialog, but it shares the ability to have multiple conversations active at once.
One more question.
My project is mainly based on Spring 1.2.7, Facelets 1.1.11 ,
AcegiSecurity 1.0 and of cause Myfaces 1.1.4 and Tomahawk. My main
problem was to integrate AcegiSecurity Filter with Facelets due to the
lack of servlet forwards (like jsps) the security filters didn't get
informed if a new view is rendered. So I had to write my own
PhaseListener to explicit redirect each request if the viewId changed
during the lifecycle. Which also solved the browser page address issue.
In general, security frameworks that try to mimic container managed security only do their checks on the initial request URI, not on RequestDispatcher.forward() calls. A couple of approaches to consider:
* If you are running on a Servlet 2.4 or later container,
you can configure the filter to run on forwards as well
as the initial request. I don't know if AcegiSecurity is
set up to work in this manner, but it's worth a try.
* Conceptually, it sounds like you are trying to apply
access control on the destination of a navigation rule.
One way to implement this might be to do a custom
NavigationHandler that delegates to the standard one,
then examines the new viewId and sees if it is acceptable
for this user.
My question now is, are there any experience to integrate these
frameworks with shale?
I know Spring works fine with Shale. I've heard scattered reports of problems with Facelets, and that's high on my list of things to evaluate. I haven't tried AcegiSecurity yet, but there's nothing in Shale that should make it work any differently than it does with MyFaces directly.
Lastly, now that MyFaces 1.1.4 is out, we will be testing and updating the dependency (for the nightly builds of Shale) to use 1.1.4 instead of 1.1.1 --- so that will get a lot of attention. (Shale doesn't care what component library you use, so Tomahawk shouldn't be an issue unless it does wierd things with some of the JSF extension points.)
Regards.
Ingo
Craig
