[dialog] Styling the dialog-config to SCXML
As step 0 of SHALE-263 [1], here [2] is an initial cut of the stylesheet for producing the needed SCXML documents from Shale dialog configuration files. That directory [2] also contains the result of styling the dialog-config.xml that comes with the Shale usecases application (log on / edit profile). Probably easiest to try via the command line: %java org.apache.xalan.xslt.Process -IN dialog-config.xml -XSL dialogconfig2scxml.xsl -OUT scxml-config.xml Caveats: * To produce multiple output documents, we either need processor specific XSLT extensions (if on XSLT 1.0, which pretty much all of us are) or we need a XSLT 2.0 processor. I'm currently using a xalan-specific extension (xalan:write), so the above will only work on JDK 1.4 (or 1.5 with xalan on classpath -- only if Sun 1.5). Will explore better solutions, wanted to get the initial cut of the stylesheet out there. * Quick sketch, may not be bullet proof yet (if you can try it out on your dialog-configs that'd be great). Notes about style results: * The event name faces.outcome and the variable name outcome are arbitrarily chosen (its the job of the SCXML NavigationHandler to trigger the event, we can choose whatever names we like) * The SCXML invoke element in view states can go away. It has to do with the state-activity separation in state charts. There are multiple ways to achieve this (some do not involve adding to the XML vocabulary -- similar to the ViewResolvers used in Spring MVC -- thats more of a C/C approach). I'm not proposing that new applications use invoke. -Rahul [1] https://issues.apache.org/struts/browse/SHALE-263 [2] http://people.apache.org/~rahul/shale/style-dialogs/
Re: [dialog] Name attribute best practice
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/25/06, Rahul Akolkar [EMAIL PROTECTED] wrote: I would like to propose a best practice for the name attribute used in various bits of the XML vocabulary for Shale dialogs that recommends restricting these to alphanumeric characters (no spaces etc.) I suppose there's a technical reason for this ... I really like the readability of these if we can keep them and it was why I chose name instead of id' for that attribute in the first place. snip/ Yes, the state IDs are meant to be IDREFs in space separated lists on transition targets when the SCXML parallel element is used, where it will be possible to have more than one transition target, as long as the targets belong to the regions of the same parallel. Ofcourse, when using a space separated list, having spaces in individual tokens will throw a wrench in the works. -Rahul Craig Commons SCXML v0.5 is accomodating in that it will allow spaces for state IDs (which is what the name attribute maps to) but there are good reasons why we will shy away from this in some future release be it at the cost of some legibility (driven by changes to that spec draft). I will produce a patch over the weekend such that the usecase application follows this best practice (ofcourse, unless someone has a good reason why we can't do without spaces here). -Rahul
Re: [dialog] className attribute
On 8/25/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Ah, missed this in the earlier post about styling, but perhaps it needs a new thread anyway. That style [1] does not process the className attribute of all the legal dialog config elements. The className attribute came in through SHALE-120 [2]. Essentially, this lets you customize the configuration objects that model the internals of the dialog. Sean had a particular use case that he can comment on ... but I imagine that this kind of thing would require the application to access and customize the SCXML configuration beans instead. What I don't know yet: * Is this possible/convenient? * Is this a good idea? From watching what people have done customizing the configuration beans of Struts 1.x, it has enabled adding a lot of power. But it sure feels like we're exposing an internal implementation detail. Craig Its basically an open door. Now I'm trying to make some sense of it for the SCXML port. In the absence of className, we could be ready to try out using Commons SCXML for the dialog internals in about a week, possibly. In the longer run, it might be possible for most of the stuff in the dialog package [3] (and its child packages) to disappear after a regular deprecate / remove cycle if we (you ;-) decide to go the SCXML route. Not sure how to handle the className attribute, perhaps interim its best to somehow watch for it and fall back to the existing digester and dialog engine if present. Comments? @Sean - I take it you are using this attribute? Any ideas here? Can you please explain (again) how you use it? There may be other ways to achieve the desired results, from an SCXML PoV. Ofcourse, that will only be applicable for new applications. -Rahul [1] http://people.apache.org/~rahul/shale/style-dialogs/ [2] https://issues.apache.org/struts/browse/SHALE-120 [3] http://svn.apache.org/repos/asf/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/dialog/
[dialog] How to use a common view with different dialog managed beans?
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different. How
would this be done with dialog managed beans?
As an example the AbstractPayment class has a CreditCard and a Check
implementation. Both the Pay By Check and Pay by CreditCard share a
common view that collects the billing address information. In the
current implementation, that view uses #{dialog.data.billingZipCode} to
pass the billing zip code regardless of the actual class. With dialog
managed beans their will be a check and creditCard bean so how would the
billing zip code be referenced in the common view? So unless their is a
way to alias the beans in the dialog configuration, the billing address
view can not be shared.
Dialog configuration show the common view getBillingAddress.
dialog name=Pay By CreditCard start=getBillingAddress
view name=getBillingAddress viewId=/getBillingAddress.jsp
transition outcome=next target=getCreditCardNumber/
/view
view name=getCreditCardNumber viewId=/getCreditCardNumber.jsp
transition outcome=next target=processPayment/
/view
action name=processPayment method=#{creditCard.processPayment}
transition outcome=success target=paymentAccepted/
transition outcome=rejected target=paymentRejected/
/action
end name=paymentAccepted view=/paymentAccepted.jsp/
end name=paymentRejected view=/paymentRejected.jsp/
/dialog
dialog name=Pay By Check start=getBillingAddress
view name=getBillingAddress viewId=/getBillingAddress.jsp
transition outcome=next target=getAccountNumber/
/view
view name=getAccountNumber viewId=/getCheckingAccountNumber.jsp
transition outcome=next target=processPayment/
/view
action name=processPayment method=#{check.processPayment}
transition outcome=success target=paymentAccepted/
transition outcome=rejected target=paymentRejected/
/action
end name=paymentAccepted view=/paymentAccepted.jsp/
end name=paymentRejected view=/paymentRejected.jsp/
/dialog
Paul Spencer
Re: [dialog] How to use a common view with different dialog managed beans?
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different. How
would this be done with dialog managed beans?
As an example the AbstractPayment class has a CreditCard and a Check
implementation. Both the Pay By Check and Pay by CreditCard share a
common view that collects the billing address information. In the
current implementation, that view uses #{dialog.data.billingZipCode} to
pass the billing zip code regardless of the actual class. With dialog
managed beans their will be a check and creditCard bean so how would the
billing zip code be referenced in the common view? So unless their is a
way to alias the beans in the dialog configuration, the billing address
view can not be shared.
You are limited to a single instance of #{dialog.data}, but that bean itself
can have properties that are, in fact , beans ... and you can nest as deeply
as you like. So, your Payment class (the one you use as the data bean for
one of the processes could have a property of type AddressBean, and you
could therefore have binding expressions like #{dialog.data.address.zipCode}
to talk to it. The only collaboration that would be needed here is that all
of the 'outer data beans that used an AddressBean would need to store it
under the same property name. You don't have to worry if the type of the
data bean is different, because the EL machinery takes care of all of that
for you.
snip/
And IIU your class diagram correctly, having the zip in the
AbstractPayment automatically takes care of this. All you would then
need to do is populate #{dialog.data} with either the CreditCard or
the Check bean via the setup action state in the corresponding
dialog.
-Rahul
Paul Spencer
Craig
Re: [dialog] How to use a common view with different dialog managed beans?
Rahul,
This was not a how to do I do this question. It was in reference to
the current Dialog Manager design effort.
Paul Spencer
Rahul Akolkar wrote:
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different.
How
would this be done with dialog managed beans?
As an example the AbstractPayment class has a CreditCard and a Check
implementation. Both the Pay By Check and Pay by CreditCard
share a
common view that collects the billing address information. In the
current implementation, that view uses #{dialog.data.billingZipCode} to
pass the billing zip code regardless of the actual class. With dialog
managed beans their will be a check and creditCard bean so how would
the
billing zip code be referenced in the common view? So unless their
is a
way to alias the beans in the dialog configuration, the billing address
view can not be shared.
You are limited to a single instance of #{dialog.data}, but that bean
itself
can have properties that are, in fact , beans ... and you can nest as
deeply
as you like. So, your Payment class (the one you use as the data bean
for
one of the processes could have a property of type AddressBean, and you
could therefore have binding expressions like
#{dialog.data.address.zipCode}
to talk to it. The only collaboration that would be needed here is
that all
of the 'outer data beans that used an AddressBean would need to store it
under the same property name. You don't have to worry if the type of the
data bean is different, because the EL machinery takes care of all
of that
for you.
snip/
And IIU your class diagram correctly, having the zip in the
AbstractPayment automatically takes care of this. All you would then
need to do is populate #{dialog.data} with either the CreditCard or
the Check bean via the setup action state in the corresponding
dialog.
-Rahul
Paul Spencer
Craig
Re: [dialog] Using SCXML to describe Shale dialogs
I have few initial concerns after looking over the excellent documentation and examples on the Commons SCXML site. So far, my concerns are as follows: 1.) I'm not wild about having to run an XSL transform on dialogs during compile time but the SCXML approach to configuring dialogs seems to involve excessive XML if you're not using UML. Don't get me wrong. Its a very cool concept but I'm not sure going from UML to dialog config is the most important feature in a dialog solution. 2.) Each dialog needs its own SCXML file. In one extreme use case where you have a ten step dialog and you want to have individual single step dialogs for each of ten steps, you'd need 11 SCXML files. 3.) Global transitions need to be configured in each of the SCXML files (is that right?) While I realize these should be ideally coming from the UML, the reality is a lot of people will not be using SC to design their dialogs. I haven't made up my mind on SCXML - in fact I seem to be swinging back and forth. Even if we don't go with it right away, I think it merits further study (and a place in our sandbox.) I'm curious as to what others think. Sean On 8/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Yes, the UML notation on a transition is: event[guard_condition] Simply put, the states that have faces.outcome listed as the event are view states (wait for the postback event) and the others are action states. snap/ Sorry, the above should read: ... the states that have faces.outcome listed as the event *on outbound transitions* are view states ... -Rahul You can skip the event, the guard condition or both on a transition. Eventless transitions get evaluated as soon as executable content onentry for that state is done. The symbol and text label under the checkCookie state label implies execute that method binding expression on entering the state (which gives us the logical outcome to choose the outbound transition). -Rahul
Re: [dialog] className attribute
@Sean - I take it you are using this attribute? Any ideas here? Can you please explain (again) how you use it? There may be other ways to achieve the desired results, from an SCXML PoV. Ofcourse, that will only be applicable for new applications. Basically there were a bunch of shortcoming in Shale dialog (many of which we are talking about addressing now) so I had need to subclass DialogImpl with my own class. The configuration stuff that shipped with shale assumed that your dialogs would be the DialogImpl class which was inconvenient. So following the DRY principle, I asked Craig to patch in the classname attribute so that users could take advantage of the digester rules, etc. I would say this would be a useful feature to have in any future direction of Shale dialogs. The fact that Dialog is an interface would suggest its expected that users might provide their own impl. It would suck for users to have to provide their own configuration when the default one was 99.9% sufficient. -Rahul Sean
Re: [dialog] Using SCXML to describe Shale dialogs
On 8/25/06, Sean Schofield [EMAIL PROTECTED] wrote: I have few initial concerns after looking over the excellent documentation and examples on the Commons SCXML site. So far, my concerns are as follows: 1.) I'm not wild about having to run an XSL transform on dialogs during compile time but the SCXML approach to configuring dialogs seems to involve excessive XML if you're not using UML. Don't get me wrong. Its a very cool concept but I'm not sure going from UML to dialog config is the most important feature in a dialog solution. Do you agree that we should continue to support a simplified configuration format like the current dialog-config style? Besides backwards compatibility (which is an issue), I'm thinking we want to offer an alternative that is easier for hand coders. The need goes down for this when there are GUI tools to assist you in setting it up (or a tool that translates a real UML state diagram). 2.) Each dialog needs its own SCXML file. In one extreme use case where you have a ten step dialog and you want to have individual single step dialogs for each of ten steps, you'd need 11 SCXML files. The states that represent your subdialog can be nested inside the state that represents each step, so they can all live in the same file. That only works if you don't need to resuse them, in which case a separate file (perhaps included via XML entities or something if you need the semantics of nested states) would seem like the way to go. 3.) Global transitions need to be configured in each of the SCXML files (is that right?) While I realize these should be ideally coming from the UML, the reality is a lot of people will not be using SC to design their dialogs. If I'm understanding Section 3.3.1 of the spec right, nesting the states of your subdialogs would deal with this as well ... the transition out of a substate can use a target state that is defined by a parent -- essentially behaving like a global transition. I haven't made up my mind on SCXML - in fact I seem to be swinging back and forth. Even if we don't go with it right away, I think it merits further study (and a place in our sandbox.) I'm definitely in favor of doing some experiments. My gut is that I'd rather focus on mapping a generic state machine to the web world than having to do that and maintain the state machine engine itself. In addition, an SCXML state engine has lots more power than the bare bones one that dialogs currently has. And things like the ability to use an EL expression on a cond (a guard condition on a transition) lets you express lots more complicated decisions without having to write any Java code. I'm curious as to what others think. Likewise. Sean Craig On 8/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Yes, the UML notation on a transition is: event[guard_condition] Simply put, the states that have faces.outcome listed as the event are view states (wait for the postback event) and the others are action states. snap/ Sorry, the above should read: ... the states that have faces.outcome listed as the event *on outbound transitions* are view states ... -Rahul You can skip the event, the guard condition or both on a transition. Eventless transitions get evaluated as soon as executable content onentry for that state is done. The symbol and text label under the checkCookie state label implies execute that method binding expression on entering the state (which gives us the logical outcome to choose the outbound transition). -Rahul
Re: [dialog] How to use a common view with different dialog managed beans?
I think Paul was commenting on an earlier idea that I had about
scrapping #{dialog.data} in favor of a managed bean type solution. If
I'm reading his message correctly he raises some good points. I think
we're past that idea now though in favor of keeping #{dialog.data} but
no longer blowing away the context when entering a subdialog.
Sean
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
Rahul,
This was not a how to do I do this question. It was in reference to
the current Dialog Manager design effort.
Paul Spencer
Rahul Akolkar wrote:
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different.
How
would this be done with dialog managed beans?
As an example the AbstractPayment class has a CreditCard and a Check
implementation. Both the Pay By Check and Pay by CreditCard
share a
common view that collects the billing address information. In the
current implementation, that view uses #{dialog.data.billingZipCode} to
pass the billing zip code regardless of the actual class. With dialog
managed beans their will be a check and creditCard bean so how would
the
billing zip code be referenced in the common view? So unless their
is a
way to alias the beans in the dialog configuration, the billing address
view can not be shared.
You are limited to a single instance of #{dialog.data}, but that bean
itself
can have properties that are, in fact , beans ... and you can nest as
deeply
as you like. So, your Payment class (the one you use as the data bean
for
one of the processes could have a property of type AddressBean, and you
could therefore have binding expressions like
#{dialog.data.address.zipCode}
to talk to it. The only collaboration that would be needed here is
that all
of the 'outer data beans that used an AddressBean would need to store it
under the same property name. You don't have to worry if the type of the
data bean is different, because the EL machinery takes care of all
of that
for you.
snip/
And IIU your class diagram correctly, having the zip in the
AbstractPayment automatically takes care of this. All you would then
need to do is populate #{dialog.data} with either the CreditCard or
the Check bean via the setup action state in the corresponding
dialog.
-Rahul
Paul Spencer
Craig
[dialog] Multple dialogs per page?
On the wiki[1], we've got mandatory requirement #9 talking about support for
Support for multiple active dialog instances within a single page (i.e.
more than one instance within a particular JSF view. Thinking about this
further, I'm not sure we really need that ... and Seam doesn't support it
either. Seam passes around a single conversationId for the entire request,
although this identifier gives you access to a stack of nested active
conversations somewhat like what we currently do with subdialogs.
One implication of this is if we wanted to build a special variable resolver
that resolved, say, context to the Context object for the current dialog.
If there is guaranteed to be at most one active dialog instance on a single
view, then this is pretty straightforward ... just go grab the value for the
dialog identifier (from however you passed it back and forth), and map it to
the corresponding Context instance that was cached in session scope. If
there is the possibility of more than one dialog in the current view, then
the VariableResolver doesn't have enough context (err, sorry :-) to figure
out which one to select when it evaluates an expression like '#{context}.
We clearly need to be able to support individual dialogs active in different
windows or frames (mandatory requirement 10), but those are each individual
views so it shouldn't cause grief. But, do we really need multiple dialogs
active *within* a single window or frame?
Craig
[1] http://wiki.apache.org/shale/DialogManagerFeature
Re: [dialog] Using SCXML to describe Shale dialogs
On 8/25/06, Sean Schofield [EMAIL PROTECTED] wrote: I have few initial concerns after looking over the excellent documentation and examples on the Commons SCXML site. So far, my concerns are as follows: 1.) I'm not wild about having to run an XSL transform on dialogs during compile time snip/ Yes, sub-optimal, though an exercise in the following: * Making sure the dialogs can actually map to SCXML * Support two XML vocabularies with one engine but the SCXML approach to configuring dialogs seems to involve excessive XML if you're not using UML. snap/ Correct. Character-to-character, it has higher verbosity. But, at the notation level, it does satisfy this -- simple things should be simple, other things should be possible. It does useful things, to name a few: * Allow executing content on a transition * Allow arbitrary levels of recursion in composite states (without breaking into a subdialog) * Allow parallelism Don't get me wrong. snip/ Please don't worry about that. All constructive criticism is highly welcome, and can only benefit all projects involved. So, please don't hold back ;-) Its a very cool concept but I'm not sure going from UML to dialog config is the most important feature in a dialog solution. snap/ I do this for every dialog. I do understand others may not. 2.) Each dialog needs its own SCXML file. In one extreme use case where you have a ten step dialog and you want to have individual single step dialogs for each of ten steps, you'd need 11 SCXML files. snip/ Correct, valid point. As part of this process, we can explore ways to alleviate this, but nothing jumps at me right now. 3.) Global transitions need to be configured in each of the SCXML files (is that right?) snap/ The notations are very symmetric. If you would define global transitions in more than one dialogs, then you need them in more than one SCXML files. If you define them in one dialog, you need them in one SCXML file (and so on ...). As a bonus, SCXML gives you local transitions, global transitions and many layers in between (depending on how you nest the states -- again, this goes beyond the current dialog notation). While I realize these should be ideally coming from the UML, the reality is a lot of people will not be using SC to design their dialogs. I haven't made up my mind on SCXML - in fact I seem to be swinging back and forth. Even if we don't go with it right away, I think it merits further study (and a place in our sandbox.) snip/ As I've said before, and opened a JIRA ticket for it, I'm happy to take this experiment to some sort of conclusion over the coming weeks. There is always going to be inertia when a new notation comes into picture. IMO, the current notation definitely deserves credit and does its job given the usecases its seen till date. However, when I look out into the distance, I see many more reasons why supporting SCXML makes sense as outlined on the top of this thread. Its a traveling weekend, see you on its other side. -Rahul I'm curious as to what others think. Sean snap/
Re: Maven dependencies
On 8/25/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/24/06, Craig McClanahan [EMAIL PROTECTED] wrote: That would be good. But I also ran into something else post-1.0.3 ... apparently profiles are not inherited the way I thought they were either, so having the JSFRI-versus-MyFaces decision being done in shale-apps-parent might also not be the best long term solution (at least until Maven2 changes). Is this what you're referring to? http://www.nabble.com/Re%3A-Profile-Inheritance-p5803559.html Yep. Thinking out loud... We still need to be able to build and test the framework against different JSF implementations, so the profiles will be in shale-parent (or possibly shale-core), but all of those dependencies will be marked 'provided'. Then I think those profiles will be repeated in shale-apps-parent, this time with the dependencies in compile scope, so they will be included in WEB-INF/lib. That seems like it should work. It's a pain for us as framework developers, but I'd *really* like to avoid the need tor downstream developers of apps based on Shale to have to be pedantic about dependencies. Ideally, they could rely on shale-apps-parent (for whatever version of Shale they happen to use) to pull all the right stuff in. -- Wendy Craig
Re: Is Commons SCXML 0.5 published in a Maven repository somewhere?
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote: Rahul, I'm trying to set up a quick Shale Sandbox project where we can experiment with the SCXML integration we've been discussing on the Shale Dev list. snip/ Cool, should be fun. I notice that you've released version 0.5, but I don't see the JAR file available in any Maven repository anywhere. snap/ I did put it in the m1-rsync repo [1] and it seems to have been mirrored on ibiblio [2] but last time I checked I couldn't get it into another m1 build so I might need to ping the Maven folks about that. And nothing m2 yet. Could you publish it to the Apache snapshot repository at /www/people.apache.org/repo/m2-snapshot-repository on people.apache.org? If you need any help figuring out how/what to do just holler. snip/ Sure, my m2 is just getting started, but I should be able to read my way through it. If not, I'll take you up on the offer, thanks! (I'm on the road till Sun evening). -Rahul [1] http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-scxml/ [2] http://www.ibiblio.org/maven/commons-scxml/ In the mean time, I'll build 0.5.1-SNAPSHOT from source and install it locally, but it'll help other people experimenting with this code not to have to do that. Craig
