commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [scxml] Spring Web Flow
Date Mon, 08 May 2006 21:24:34 GMT
On 5/8/06, Jacob Kjome <hoju@visi.com> wrote:
>
> I just read on TheServerside about the 1.0-RC1 release of Spring Web Flow.  It
> seems like it is using similar concepts to SCXML, but with their own syntax.
<snip/>

Yes, but SCXML was probably not a viable option before Commons SCXML
graduated sandbox (couple of weeks ago), and a lot of these
declarative notations (used in Spring Web Flow, Shale Dialogs, JBoss
Seam pageflow etc.) predate SCXML and therefore, their existence is
completely understandable. What Commons SCXML attempts to provide is a
library that will encourage frameworks (and individual users alike) to
use a "standard" notation, that in the end, helps everybodys learning
curves, tooling needs, various plugin supports, interoperabilities and
so on ...

Otherwise, everyone has to come up with YASCN (Yet Another State Chart
Notation), a sentiment echoed in my post here [1], which is probably a
sub-optimal alternative for developers and users alike.


> Can someone comment on where the similarities end?
<snap/>

I cannot, since I haven't looked at the Spring Web Flow code, but it
will probably be a fair statement that Commons SCXML provides a
generic mechanism to work with state charts and activity diagrams that
Spring Web Flow provides tied to a specific (SWF) implementation. This
also means that given the availability of the right kind of glue [2],
which there seems interest in creating [3], the SCXML notation may be
used to drive Spring Web Flows like the usecase where it drives Shale
dialogs.


>  I have followed some of the
> SCXML discussion, but haven't looked into it in depth yet.
<snip/>

The user guide [4] may be a good starting point. Suggestions from
improvement are welcome.


> Would Spring Web
> flow functionality be akin to the Shale usecase example?
<snip/>

It terms of the role Commons SCXML can play, yes, they are similar.
But there is more than just Web Flow where Commons SCXML applies to in
terms of Spring integration.


>  That is, is the
> following true?...
>
> SCXML + Shale
>    Equivalent to...
> Spring Web Flow
>
<snip/>

No. Shale has its own notation for describing dialogs [5], which was
inspired in turn by Spring Web Flow. In the Shale usecase for Commons
SCXML, this Shale-specific notation was replaced by SCXML by tying the
generic Commons SCXML engine to Shale's internal processing for its
dialogs.

When I look at SWF closely, I can probably put forth meaningful
equalities in such an email.

But for starters, the advantage of using Commons SCXML for the
specific use case of cross-page navigation in a web application
framework are vaguely similar to the advantages of:

 * Using well-behaved JSF component libraries over JSP tag libraries
 * Using Commons Logging in library code
 * Using JAXP over a particular XML processing implementation

Ofcourse, being a generic state chart engine, cross-page navigation
then, becomes merely one usecase where you may use Commons SCXML.

-Rahul

[1] http://marc.theaimsgroup.com/?l=myfaces-dev&m=114359263814344&w=2
[2] http://jakarta.apache.org/commons/scxml/guide/using-commons-scxml.html
[3] http://marc.theaimsgroup.com/?l=jakarta-commons-user&w=2&r=1&s=scxml+spring&q=b
[4] http://jakarta.apache.org/commons/scxml/guide.html
[5] http://struts.apache.org/struts-shale/features-dialog-manager.html


>
> Jake
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message