You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Craig Tataryn <Cr...@morganstanley.com> on 2001/06/05 18:28:51 UTC
Work flow RFC
Hi, I would like your comments for the workflow item on our TODO list.
Currently this is how I've envisioned the workflow project:
1) A nice GUI type Applet or Application that has visual constructs
which can be connected in a Visio type manner to create an Activity
diagram or some other type of flow diagram.
2) This diagram will be persisted in an XML file which holds meta data
for the elements in diagram (position, type of construct (controller,
flat html page, cgi script, flow arrow, etc..)).
3) The diagram can be exported to a struts config file via XSLT (i.e.
workflow.xml -> workflow2struts.xsl -> struts-config.xml)
4) A diagram can also be imported from a struts-config.xml file via XSLT
(i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
course some sort of "pretty layout" code would have to be used to
un-jumble the mess of constructs that are sucked out of the
struts-config.xml file (i.e. take a guess at proper positioning
information).
The GUI should employ some sort of extensibility mechanism like BSF
(http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell
(http://www.beanshell.org/) to allow users to plug-in their own
functionality (i.e. validation code) without jeopardizing the core code
(what I call the Emeril Lagasse technique -- BAM!).
I realize this is a very high level look at the TODO but I think as we
get more comments we will get more granular and can start dishing out
segments.
Let me know what you think.
<tataryn:craig/>
Re: Work flow RFC
Posted by Craig Tataryn <Cr...@morganstanley.com>.
Thanks Jonathan, I haven't been monitoring the list for a while so this is news
to me!
Keep 'em coming!
Craig T.
Jonathan wrote:
> Again, Ive got to say look at the Barracuda project. They have one of these
> gui configurers. Check it out at
> http://barracuda.enhydra.org/Barracuda/GetBConfig.event
>
> ----- Original Message -----
> From: "Craig Tataryn" <Cr...@morganstanley.com>
> To: <st...@jakarta.apache.org>
> Sent: Tuesday, June 05, 2001 12:28 PM
> Subject: Work flow RFC
>
> > Hi, I would like your comments for the workflow item on our TODO list.
> > Currently this is how I've envisioned the workflow project:
> >
> > 1) A nice GUI type Applet or Application that has visual constructs
> > which can be connected in a Visio type manner to create an Activity
> > diagram or some other type of flow diagram.
> >
> > 2) This diagram will be persisted in an XML file which holds meta data
> > for the elements in diagram (position, type of construct (controller,
> > flat html page, cgi script, flow arrow, etc..)).
> >
> > 3) The diagram can be exported to a struts config file via XSLT (i.e.
> > workflow.xml -> workflow2struts.xsl -> struts-config.xml)
> >
> > 4) A diagram can also be imported from a struts-config.xml file via XSLT
> > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
> > course some sort of "pretty layout" code would have to be used to
> > un-jumble the mess of constructs that are sucked out of the
> > struts-config.xml file (i.e. take a guess at proper positioning
> > information).
> >
> > The GUI should employ some sort of extensibility mechanism like BSF
> > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell
> > (http://www.beanshell.org/) to allow users to plug-in their own
> > functionality (i.e. validation code) without jeopardizing the core code
> > (what I call the Emeril Lagasse technique -- BAM!).
> >
> > I realize this is a very high level look at the TODO but I think as we
> > get more comments we will get more granular and can start dishing out
> > segments.
> >
> > Let me know what you think.
> >
> > <tataryn:craig/>
> >
Re: Work flow RFC
Posted by Ted Husted <hu...@apache.org>.
David W did a nice job of integrating Validation into Struts by adding a
servlet and hooking it to the ActionForm.
I wonder if we could do the same thing with the ActionServlet by hooking
it to an ApplicationGateway servlet that was also initialized in the
web.xml?
It would be very cool if we could add Baracuda style event handling as a
standard option just by using an subclassed ActionServlet (and then
using listeners, and so forth, through your application).
Christian Cryder wrote:
> a) an event model might provide a good foundation for a workflow engine
> b) Barracuda has a robust event model implementation
> c) it could probably be integrated with Struts
RE: Work flow RFC
Posted by Christian Cryder <ch...@enhydra.org>.
Hi Jeff,
> Interesting - sounds like its modeled after Group of 4, Decorator
> Pattern... These event listeners - are they passive or do they muck
> with the result stream?
Well, it doesn't correspond directly with the Decorator pattern (although
there's certainly some similarity). It's really modeled much more closely
after event models like you'd find in Swing, although specifically tailored
for the req/resp paradigm of Http.
Event listeners can be whatever you want them to be. They just get notified
that something happened; its up to the implementater to determine how to
respond. Generally, a ControlEvent handler will muck with the model and then
fire a ViewEvent, which actually renders the view.
I didn't mention that all control events that come through the
ApplicationGateway servlet (that's the HTTP entry point) _must_ have a
ViewEvent generated at some point in the cycle (after all, HTTP dicates that
for every request there must be a response, right?).
Just as the ControlEvents implement Polymorphic interface, the ViewEvents
implement an interface called Exceptional. When a view event is fired, (and
if there is no view event fired it will use a default view event) it tells
the dispatcher that someone _must_ handle it; if not, this represents an
exceptional circumstance, and as such the event dispatcher should fire the
parent event, just like with exceptions. This causes view events to fire up
the chain and guarantees that eventually someone will handle the request to
generate a view. This ensures that a response always gets sent to the client
and handles situations where a programmer might have forgotten to handle
certain view events, etc.
For more details, you really should look at the Barracuda site (I don't want
to getting any further off topic here, since this is the Struts list after
all). The gist of both of my emails is basically that:
a) an event model might provide a good foundation for a workflow engine
b) Barracuda has a robust event model implementation
c) it could probably be integrated with Struts
Hope that helps...
Christian
------------------------------------------------
Christian Cryder [christianc@enhydra.org]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: Jeff Trent [mailto:jtrent@structsoft.com]
> Sent: Wednesday, June 06, 2001 10:09 AM
> To: struts-dev@jakarta.apache.org
> Subject: Re: Work flow RFC
>
>
> Interesting - sounds like its modeled after Group of 4, Decorator
> Pattern...
> These event listeners - are they passive or do they muck with the result
> stream?
>
> -jeff
>
>
> ----- Original Message -----
> From: "Christian Cryder" <ch...@enhydra.org>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, June 06, 2001 11:37 AM
> Subject: RE: Work flow RFC
>
>
> > > The lead on the Barracuda project is a subscriber to the Struts list!
> > > Christian Cryder (christianc@enhydra.org). He was the one who said he
> > > likes to "lurk" and spoke about security
> >
> > Yes, I lurk. Too much to on my plate to be more actively involved ;-)
> >
> > As didge pointed out:
> >
> > > From Barracuda's Scope Summary (see,
> > > http://barracuda.enhydra.org/Barracuda/docs/scope_summary.html#2.4),
> > > Barracuda's scope explicitly excludes application flow control.
> >
> > This is correct. Barracuda does not force any particular workflow on a
> > system. That said, it was designed from the get-go so as not to preclude
> it
> > either...I know we've already had at least one person build an
> XML driven
> > workflow engine on top of Barracuda (I don't think it was
> public though).
> >
> > Basically, what Barracuda gives you is this:
> >
> > 1. Event model - converts HTTP Requests into true, first class event
> > objects, which can then be dispatched to all interested listeners.
> > Additional events can be fired, etc.
> >
> > 2. Component model - a suite of strongly typed, Swing-like MVC
> components
> > that can be used to manipulate DOM objects, instead of using
> the DOM apis.
> >
> > 3. Form mapping & Validation framework - Automatically convert HTTP Req
> > params to first class objects and apply any number of
> validation rules to
> > them.
> >
> > 4. Localization services - automatically localize *ML templates
> (based on
> > property files) and create XMLC objects from them; ability to load the
> > proper template based on a Locale (much like ResourceBundles,
> it finds the
> > closest match)
> >
> > Each of these sub-systems are self contained and can be used
> independently
> > from one another. In the case of work flow, its the event model portion
> that
> > would prove particularly useful. Here's how it could be applied (I think
> > this is described in the Barracuda docs somewhere but I
> couldn't locate it
> > this morning, so here's a brief summary)
> >
> > In Barracuda, there are two types of events: ControlEvents and
> ViewEvents
> > (which nicely map to the Http Req/Resp paradigm). When the user does
> > something on the client that results in an HttpRequest, that
> request will
> > get translated to a ControlEvent, which then gets delivered to
> listeners.
> > However, there's more to the event dispatch process than might
> first meet
> > the eye.
> >
> > Control events implement a nifty little interface called
> Polymorphic. This
> > tells the dispatcher "hey, before you dispatch me, dispatch all
> my parent
> > events too (since I am after all an _instance_ of those events
> as well").
> So
> > if the event hierarchy looks something like this:
> >
> > AuthorizedEvent
> > HREvent
> > FireEmployee
> > HireEmployee
> >
> > If the client generates a HireEmployee event, this system will
> first fire
> an
> > AuthorizedEvent, then an HREvent, then the actual HireEmployee
> event. This
> > allows me to install a listener on AuthorizedEvent or HREvent to first
> > _validate_ that the client actually has the necessary authority
> to invoke
> > the event they're trying to fire. If they don't, I can wipe the event
> queue
> > and completely redirect the application flow simply by firing a
> different
> > event. For instance, if they're not already logged in, I could fire a
> > GetLoginEvent to redirect them to the login screen.
> >
> > This process can be applied to workflow quite easily. Basically all you
> have
> > to do to define a workflow system is create a mechanism for indicating
> which
> > events can be fired for a given user state. This could take a number of
> > different forms: you might have a mechanism that controls event firing
> based
> > on user roles, or a statechart engine, or an XML schema approach...there
> are
> > a tons of different options (which btw, is why we didn't just build a
> > workflow engine directly into Barracuda...there are two many
> ways of doing
> > workflow, so we didn't want to lock anyone into one particular
> approach).
> >
> > At any rate, hopefully this better explains how "No, Barracuda does not
> > provide a workflow engine but Yes, its event model mechanism is
> very well
> > suited to that problem domain".
> >
> > The other question is "Could Barracuda be used to glue a workflow engine
> > into Struts". I think the answer is yes, but I'm not a Struts guru so I
> > won't try and offer any details. Basically, the Barracuda event model
> > provides Model 2 flow control...your event handlers would have
> to be done
> > with Barracuda style code, but I don't see any reason why your
> view event
> > handlers couldn't just redirect to the appropriate JSP page.
> >
> > Ok, I'll shut up now ;-)
> >
> > Christian
> > (See why I just lurk? Its too time consuming when I get involved in
> > discussions! ;-)
> > ------------------------------------------------
> > Christian Cryder [christianc@enhydra.org]
> > Barracuda - MVC Component Framework for Webapps
> > http://barracuda.enhydra.org
> > ------------------------------------------------
> > "What a great time to be a Geek"
> >
> >
> > > -----Original Message-----
> > > From: Jonathan [mailto:jasbell@i-2000.com]
> > > Sent: Tuesday, June 05, 2001 11:10 AM
> > > To: struts-dev@jakarta.apache.org
> > > Subject: Re: Work flow RFC
> > >
> > >
> > > The lead on the Barracuda project is a subscriber to the Struts list!
> > > Christian Cryder (christianc@enhydra.org)
> > > He was the one who said he likes to "lurk" and spoke about security on
> > > Monday May 7, "RE: Potential Security Flaw in Struts MVC"
> > >
> > >
> > > ----- Original Message -----
> > > From: "Ted Husted" <hu...@apache.org>
> > > To: <st...@jakarta.apache.org>
> > > Sent: Tuesday, June 05, 2001 12:48 PM
> > > Subject: Re: Work flow RFC
> > >
> > >
> > > > I'm still fuzzy on the mechanism we would use to represent
> and enforce
> > > > the workflow. There has been mention of things like command tokens,
> but
> > > > are any code samples available.
> > > >
> > > > Can anyone explain how Barracuda implements their workflow, and
> whether
> > > > it could be mapped to the Struts Actions/ActionMappings model?
> > > >
> > > > I believe Barracuda and Struts are complementary in most
> ways, and it
> > > > would be in our best interest to adopt and adapt rather than
> > > > roll-our-own, if feasible.
> > > >
> > > > Jonathan wrote:
> > > > >
> > > > > Again, Ive got to say look at the Barracuda project.
> They have one
> of
> > > these
> > > > > gui configurers. Check it out at
> > > > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
> > > >
> > >
> >
> >
>
Re: Work flow RFC
Posted by Jeff Trent <jt...@structsoft.com>.
Interesting - sounds like its modeled after Group of 4, Decorator Pattern...
These event listeners - are they passive or do they muck with the result
stream?
-jeff
----- Original Message -----
From: "Christian Cryder" <ch...@enhydra.org>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 06, 2001 11:37 AM
Subject: RE: Work flow RFC
> > The lead on the Barracuda project is a subscriber to the Struts list!
> > Christian Cryder (christianc@enhydra.org). He was the one who said he
> > likes to "lurk" and spoke about security
>
> Yes, I lurk. Too much to on my plate to be more actively involved ;-)
>
> As didge pointed out:
>
> > From Barracuda's Scope Summary (see,
> > http://barracuda.enhydra.org/Barracuda/docs/scope_summary.html#2.4),
> > Barracuda's scope explicitly excludes application flow control.
>
> This is correct. Barracuda does not force any particular workflow on a
> system. That said, it was designed from the get-go so as not to preclude
it
> either...I know we've already had at least one person build an XML driven
> workflow engine on top of Barracuda (I don't think it was public though).
>
> Basically, what Barracuda gives you is this:
>
> 1. Event model - converts HTTP Requests into true, first class event
> objects, which can then be dispatched to all interested listeners.
> Additional events can be fired, etc.
>
> 2. Component model - a suite of strongly typed, Swing-like MVC components
> that can be used to manipulate DOM objects, instead of using the DOM apis.
>
> 3. Form mapping & Validation framework - Automatically convert HTTP Req
> params to first class objects and apply any number of validation rules to
> them.
>
> 4. Localization services - automatically localize *ML templates (based on
> property files) and create XMLC objects from them; ability to load the
> proper template based on a Locale (much like ResourceBundles, it finds the
> closest match)
>
> Each of these sub-systems are self contained and can be used independently
> from one another. In the case of work flow, its the event model portion
that
> would prove particularly useful. Here's how it could be applied (I think
> this is described in the Barracuda docs somewhere but I couldn't locate it
> this morning, so here's a brief summary)
>
> In Barracuda, there are two types of events: ControlEvents and ViewEvents
> (which nicely map to the Http Req/Resp paradigm). When the user does
> something on the client that results in an HttpRequest, that request will
> get translated to a ControlEvent, which then gets delivered to listeners.
> However, there's more to the event dispatch process than might first meet
> the eye.
>
> Control events implement a nifty little interface called Polymorphic. This
> tells the dispatcher "hey, before you dispatch me, dispatch all my parent
> events too (since I am after all an _instance_ of those events as well").
So
> if the event hierarchy looks something like this:
>
> AuthorizedEvent
> HREvent
> FireEmployee
> HireEmployee
>
> If the client generates a HireEmployee event, this system will first fire
an
> AuthorizedEvent, then an HREvent, then the actual HireEmployee event. This
> allows me to install a listener on AuthorizedEvent or HREvent to first
> _validate_ that the client actually has the necessary authority to invoke
> the event they're trying to fire. If they don't, I can wipe the event
queue
> and completely redirect the application flow simply by firing a different
> event. For instance, if they're not already logged in, I could fire a
> GetLoginEvent to redirect them to the login screen.
>
> This process can be applied to workflow quite easily. Basically all you
have
> to do to define a workflow system is create a mechanism for indicating
which
> events can be fired for a given user state. This could take a number of
> different forms: you might have a mechanism that controls event firing
based
> on user roles, or a statechart engine, or an XML schema approach...there
are
> a tons of different options (which btw, is why we didn't just build a
> workflow engine directly into Barracuda...there are two many ways of doing
> workflow, so we didn't want to lock anyone into one particular approach).
>
> At any rate, hopefully this better explains how "No, Barracuda does not
> provide a workflow engine but Yes, its event model mechanism is very well
> suited to that problem domain".
>
> The other question is "Could Barracuda be used to glue a workflow engine
> into Struts". I think the answer is yes, but I'm not a Struts guru so I
> won't try and offer any details. Basically, the Barracuda event model
> provides Model 2 flow control...your event handlers would have to be done
> with Barracuda style code, but I don't see any reason why your view event
> handlers couldn't just redirect to the appropriate JSP page.
>
> Ok, I'll shut up now ;-)
>
> Christian
> (See why I just lurk? Its too time consuming when I get involved in
> discussions! ;-)
> ------------------------------------------------
> Christian Cryder [christianc@enhydra.org]
> Barracuda - MVC Component Framework for Webapps
> http://barracuda.enhydra.org
> ------------------------------------------------
> "What a great time to be a Geek"
>
>
> > -----Original Message-----
> > From: Jonathan [mailto:jasbell@i-2000.com]
> > Sent: Tuesday, June 05, 2001 11:10 AM
> > To: struts-dev@jakarta.apache.org
> > Subject: Re: Work flow RFC
> >
> >
> > The lead on the Barracuda project is a subscriber to the Struts list!
> > Christian Cryder (christianc@enhydra.org)
> > He was the one who said he likes to "lurk" and spoke about security on
> > Monday May 7, "RE: Potential Security Flaw in Struts MVC"
> >
> >
> > ----- Original Message -----
> > From: "Ted Husted" <hu...@apache.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Tuesday, June 05, 2001 12:48 PM
> > Subject: Re: Work flow RFC
> >
> >
> > > I'm still fuzzy on the mechanism we would use to represent and enforce
> > > the workflow. There has been mention of things like command tokens,
but
> > > are any code samples available.
> > >
> > > Can anyone explain how Barracuda implements their workflow, and
whether
> > > it could be mapped to the Struts Actions/ActionMappings model?
> > >
> > > I believe Barracuda and Struts are complementary in most ways, and it
> > > would be in our best interest to adopt and adapt rather than
> > > roll-our-own, if feasible.
> > >
> > > Jonathan wrote:
> > > >
> > > > Again, Ive got to say look at the Barracuda project. They have one
of
> > these
> > > > gui configurers. Check it out at
> > > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
> > >
> >
>
>
RE: Work flow RFC
Posted by Christian Cryder <ch...@enhydra.org>.
> The lead on the Barracuda project is a subscriber to the Struts list!
> Christian Cryder (christianc@enhydra.org). He was the one who said he
> likes to "lurk" and spoke about security
Yes, I lurk. Too much to on my plate to be more actively involved ;-)
As didge pointed out:
> From Barracuda's Scope Summary (see,
> http://barracuda.enhydra.org/Barracuda/docs/scope_summary.html#2.4),
> Barracuda's scope explicitly excludes application flow control.
This is correct. Barracuda does not force any particular workflow on a
system. That said, it was designed from the get-go so as not to preclude it
either...I know we've already had at least one person build an XML driven
workflow engine on top of Barracuda (I don't think it was public though).
Basically, what Barracuda gives you is this:
1. Event model - converts HTTP Requests into true, first class event
objects, which can then be dispatched to all interested listeners.
Additional events can be fired, etc.
2. Component model - a suite of strongly typed, Swing-like MVC components
that can be used to manipulate DOM objects, instead of using the DOM apis.
3. Form mapping & Validation framework - Automatically convert HTTP Req
params to first class objects and apply any number of validation rules to
them.
4. Localization services - automatically localize *ML templates (based on
property files) and create XMLC objects from them; ability to load the
proper template based on a Locale (much like ResourceBundles, it finds the
closest match)
Each of these sub-systems are self contained and can be used independently
from one another. In the case of work flow, its the event model portion that
would prove particularly useful. Here's how it could be applied (I think
this is described in the Barracuda docs somewhere but I couldn't locate it
this morning, so here's a brief summary)
In Barracuda, there are two types of events: ControlEvents and ViewEvents
(which nicely map to the Http Req/Resp paradigm). When the user does
something on the client that results in an HttpRequest, that request will
get translated to a ControlEvent, which then gets delivered to listeners.
However, there's more to the event dispatch process than might first meet
the eye.
Control events implement a nifty little interface called Polymorphic. This
tells the dispatcher "hey, before you dispatch me, dispatch all my parent
events too (since I am after all an _instance_ of those events as well"). So
if the event hierarchy looks something like this:
AuthorizedEvent
HREvent
FireEmployee
HireEmployee
If the client generates a HireEmployee event, this system will first fire an
AuthorizedEvent, then an HREvent, then the actual HireEmployee event. This
allows me to install a listener on AuthorizedEvent or HREvent to first
_validate_ that the client actually has the necessary authority to invoke
the event they're trying to fire. If they don't, I can wipe the event queue
and completely redirect the application flow simply by firing a different
event. For instance, if they're not already logged in, I could fire a
GetLoginEvent to redirect them to the login screen.
This process can be applied to workflow quite easily. Basically all you have
to do to define a workflow system is create a mechanism for indicating which
events can be fired for a given user state. This could take a number of
different forms: you might have a mechanism that controls event firing based
on user roles, or a statechart engine, or an XML schema approach...there are
a tons of different options (which btw, is why we didn't just build a
workflow engine directly into Barracuda...there are two many ways of doing
workflow, so we didn't want to lock anyone into one particular approach).
At any rate, hopefully this better explains how "No, Barracuda does not
provide a workflow engine but Yes, its event model mechanism is very well
suited to that problem domain".
The other question is "Could Barracuda be used to glue a workflow engine
into Struts". I think the answer is yes, but I'm not a Struts guru so I
won't try and offer any details. Basically, the Barracuda event model
provides Model 2 flow control...your event handlers would have to be done
with Barracuda style code, but I don't see any reason why your view event
handlers couldn't just redirect to the appropriate JSP page.
Ok, I'll shut up now ;-)
Christian
(See why I just lurk? Its too time consuming when I get involved in
discussions! ;-)
------------------------------------------------
Christian Cryder [christianc@enhydra.org]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: Jonathan [mailto:jasbell@i-2000.com]
> Sent: Tuesday, June 05, 2001 11:10 AM
> To: struts-dev@jakarta.apache.org
> Subject: Re: Work flow RFC
>
>
> The lead on the Barracuda project is a subscriber to the Struts list!
> Christian Cryder (christianc@enhydra.org)
> He was the one who said he likes to "lurk" and spoke about security on
> Monday May 7, "RE: Potential Security Flaw in Struts MVC"
>
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Tuesday, June 05, 2001 12:48 PM
> Subject: Re: Work flow RFC
>
>
> > I'm still fuzzy on the mechanism we would use to represent and enforce
> > the workflow. There has been mention of things like command tokens, but
> > are any code samples available.
> >
> > Can anyone explain how Barracuda implements their workflow, and whether
> > it could be mapped to the Struts Actions/ActionMappings model?
> >
> > I believe Barracuda and Struts are complementary in most ways, and it
> > would be in our best interest to adopt and adapt rather than
> > roll-our-own, if feasible.
> >
> > Jonathan wrote:
> > >
> > > Again, Ive got to say look at the Barracuda project. They have one of
> these
> > > gui configurers. Check it out at
> > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
> >
>
Re: Work flow RFC
Posted by Jonathan <ja...@i-2000.com>.
The lead on the Barracuda project is a subscriber to the Struts list!
Christian Cryder (christianc@enhydra.org)
He was the one who said he likes to "lurk" and spoke about security on
Monday May 7, "RE: Potential Security Flaw in Struts MVC"
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Tuesday, June 05, 2001 12:48 PM
Subject: Re: Work flow RFC
> I'm still fuzzy on the mechanism we would use to represent and enforce
> the workflow. There has been mention of things like command tokens, but
> are any code samples available.
>
> Can anyone explain how Barracuda implements their workflow, and whether
> it could be mapped to the Struts Actions/ActionMappings model?
>
> I believe Barracuda and Struts are complementary in most ways, and it
> would be in our best interest to adopt and adapt rather than
> roll-our-own, if feasible.
>
> Jonathan wrote:
> >
> > Again, Ive got to say look at the Barracuda project. They have one of
these
> > gui configurers. Check it out at
> > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
>
Re: Work flow RFC
Posted by Joshua Yip <jo...@time.net.my>.
basically my company is working on a workflow app. to make sure that the
workflow engine is interoperable, we follow the wfmc stds. XML plays a vital
role in defining the process of a workflow. XML is also used to define
organisation units, work list and other stuff. So base on these defined xml
document type, the workflow engine interacts with all other application
currently used in a company. For instance, if a bank is already using some
application, the engine should be able to invoke the application for a
particular user base on his accesslevel and permission defined in an xml
doc.
Hope this helps. I am also looking to hear from any one doing other workflow
app too! Thanks
XML is the future!
Joshua Yip
Software Developer
IB-DOCS.COM
Intelligent Business Document dot Com
Office email: joshuayip@time.net.my
Personal Email:joshuayip@yahoo.com
YahooID: joshuayip
ICQ:8657630
----- Original Message -----
From: "Jonathan Asbell" <ja...@i-2000.com>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 06, 2001 11:16 AM
Subject: Re: Work flow RFC
> Well Josh, if you have an idea please share it. I am all ears. How would
> you do workflow with xml?
>
>
> ----- Original Message -----
> From: "Joshua Yip" <jo...@time.net.my>
> To: <st...@jakarta.apache.org>
> Sent: Tuesday, June 05, 2001 10:53 PM
> Subject: Re: Work flow RFC
>
>
> > Are you trying to develop an workflow application using purely servlets
> and
> > jsp?
> >
> > XML is the future!
> >
> > Joshua Yip
> > Software Developer
> > IB-DOCS.COM
> > Intelligent Business Document dot Com
> > Office email: joshuayip@time.net.my
> > Personal Email:joshuayip@yahoo.com
> > YahooID: joshuayip
> > ICQ:8657630
> >
> > ----- Original Message -----
> > From: "Ted Husted" <hu...@apache.org>
> > To: <st...@jakarta.apache.org>
> > Sent: Wednesday, June 06, 2001 12:48 AM
> > Subject: Re: Work flow RFC
> >
> >
> > > I'm still fuzzy on the mechanism we would use to represent and enforce
> > > the workflow. There has been mention of things like command tokens,
but
> > > are any code samples available.
> > >
> > > Can anyone explain how Barracuda implements their workflow, and
whether
> > > it could be mapped to the Struts Actions/ActionMappings model?
> > >
> > > I believe Barracuda and Struts are complementary in most ways, and it
> > > would be in our best interest to adopt and adapt rather than
> > > roll-our-own, if feasible.
> > >
> > > Jonathan wrote:
> > > >
> > > > Again, Ive got to say look at the Barracuda project. They have one
of
> > these
> > > > gui configurers. Check it out at
> > > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
> >
>
Re: Work flow RFC
Posted by Jonathan Asbell <ja...@i-2000.com>.
Well Josh, if you have an idea please share it. I am all ears. How would
you do workflow with xml?
----- Original Message -----
From: "Joshua Yip" <jo...@time.net.my>
To: <st...@jakarta.apache.org>
Sent: Tuesday, June 05, 2001 10:53 PM
Subject: Re: Work flow RFC
> Are you trying to develop an workflow application using purely servlets
and
> jsp?
>
> XML is the future!
>
> Joshua Yip
> Software Developer
> IB-DOCS.COM
> Intelligent Business Document dot Com
> Office email: joshuayip@time.net.my
> Personal Email:joshuayip@yahoo.com
> YahooID: joshuayip
> ICQ:8657630
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, June 06, 2001 12:48 AM
> Subject: Re: Work flow RFC
>
>
> > I'm still fuzzy on the mechanism we would use to represent and enforce
> > the workflow. There has been mention of things like command tokens, but
> > are any code samples available.
> >
> > Can anyone explain how Barracuda implements their workflow, and whether
> > it could be mapped to the Struts Actions/ActionMappings model?
> >
> > I believe Barracuda and Struts are complementary in most ways, and it
> > would be in our best interest to adopt and adapt rather than
> > roll-our-own, if feasible.
> >
> > Jonathan wrote:
> > >
> > > Again, Ive got to say look at the Barracuda project. They have one of
> these
> > > gui configurers. Check it out at
> > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
>
Re: Work flow RFC
Posted by Ted Husted <hu...@apache.org>.
I suppose it's the details of "setting up your config files" that I was
wondering about.
Craig Tataryn wrote:
>
> I was thinking that it would be an applet or application. Something rich.
>
> Ted, as for "enforcing" the workflow, I hadn't even considered it. The goal of
> the TODO is just to make a graphical tool that allows you to define a workflow
> and automate the process of setting up your config files to support the
> workflow. Atleast that's how I read it.
Re: Work flow RFC
Posted by Ted Husted <hu...@apache.org>.
It's possible we're talking about two different things. Something that
comes up a lot is the idea of a frame of reference longer than a request
but shorter than a session, since there are many tasks which cannot be
resolved in a single request, and are also interdependant.
* Form Wizards
* "Are you sure?" confirmations
* Logging-in from a page and returning to that page
* Starting to add a record, going off and looking up a related record,
and being automatically returned to the add-form when the related record
is selected. (Disconnected picklist.)
I was thinking this part was covered by the "(including flow control and
iteration support)" part, but maybe you are thinking of something else.
Of course, an event queue (or stack) may also help with this.
Craig Tataryn wrote:
> Ted, as for "enforcing" the workflow, I hadn't even considered it. The goal of
> the TODO is just to make a graphical tool that allows you to define a workflow
> and automate the process of setting up your config files to support the
> workflow. Atleast that's how I read it.
>
> <tataryn:craig/>
Re: Work flow RFC
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 6 Jun 2001, Craig Tataryn wrote:
> Ted, as for "enforcing" the workflow, I hadn't even considered it. The goal of
> the TODO is just to make a graphical tool that allows you to define a workflow
> and automate the process of setting up your config files to support the
> workflow. Atleast that's how I read it.
>
That's one worthy goal.
I've actually been thinking that it would be nice to have a workflow
runtime environment that Struts interacted with, keeping track of where in
the flow the user was, and therefore managing the overall
navigation. Just as a trivially simple example, this would make doing
wizard-type interactions very simple.
> <tataryn:craig/>
>
Craig McClanahan
Re: Work flow RFC
Posted by Craig Tataryn <Cr...@morganstanley.com>.
I was thinking that it would be an applet or application. Something rich.
Ted, as for "enforcing" the workflow, I hadn't even considered it. The goal of
the TODO is just to make a graphical tool that allows you to define a workflow
and automate the process of setting up your config files to support the
workflow. Atleast that's how I read it.
<tataryn:craig/>
Joshua Yip wrote:
> Are you trying to develop an workflow application using purely servlets and
> jsp?
>
> XML is the future!
>
> Joshua Yip
> Software Developer
> IB-DOCS.COM
> Intelligent Business Document dot Com
> Office email: joshuayip@time.net.my
> Personal Email:joshuayip@yahoo.com
> YahooID: joshuayip
> ICQ:8657630
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: <st...@jakarta.apache.org>
> Sent: Wednesday, June 06, 2001 12:48 AM
> Subject: Re: Work flow RFC
>
> > I'm still fuzzy on the mechanism we would use to represent and enforce
> > the workflow. There has been mention of things like command tokens, but
> > are any code samples available.
> >
> > Can anyone explain how Barracuda implements their workflow, and whether
> > it could be mapped to the Struts Actions/ActionMappings model?
> >
> > I believe Barracuda and Struts are complementary in most ways, and it
> > would be in our best interest to adopt and adapt rather than
> > roll-our-own, if feasible.
> >
> > Jonathan wrote:
> > >
> > > Again, Ive got to say look at the Barracuda project. They have one of
> these
> > > gui configurers. Check it out at
> > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
Re: Work flow RFC
Posted by Joshua Yip <jo...@time.net.my>.
Are you trying to develop an workflow application using purely servlets and
jsp?
XML is the future!
Joshua Yip
Software Developer
IB-DOCS.COM
Intelligent Business Document dot Com
Office email: joshuayip@time.net.my
Personal Email:joshuayip@yahoo.com
YahooID: joshuayip
ICQ:8657630
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Wednesday, June 06, 2001 12:48 AM
Subject: Re: Work flow RFC
> I'm still fuzzy on the mechanism we would use to represent and enforce
> the workflow. There has been mention of things like command tokens, but
> are any code samples available.
>
> Can anyone explain how Barracuda implements their workflow, and whether
> it could be mapped to the Struts Actions/ActionMappings model?
>
> I believe Barracuda and Struts are complementary in most ways, and it
> would be in our best interest to adopt and adapt rather than
> roll-our-own, if feasible.
>
> Jonathan wrote:
> >
> > Again, Ive got to say look at the Barracuda project. They have one of
these
> > gui configurers. Check it out at
> > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
Re: Work flow RFC
Posted by Ted Husted <hu...@apache.org>.
I'm still fuzzy on the mechanism we would use to represent and enforce
the workflow. There has been mention of things like command tokens, but
are any code samples available.
Can anyone explain how Barracuda implements their workflow, and whether
it could be mapped to the Struts Actions/ActionMappings model?
I believe Barracuda and Struts are complementary in most ways, and it
would be in our best interest to adopt and adapt rather than
roll-our-own, if feasible.
Jonathan wrote:
>
> Again, Ive got to say look at the Barracuda project. They have one of these
> gui configurers. Check it out at
> http://barracuda.enhydra.org/Barracuda/GetBConfig.event
Re: Work flow RFC
Posted by Craig Tataryn <Cr...@morganstanley.com>.
Is this a workflow editor or just a configuration editor (which would be nice
for struts)?
craig.
Jonathan wrote:
> Again, Ive got to say look at the Barracuda project. They have one of these
> gui configurers. Check it out at
> http://barracuda.enhydra.org/Barracuda/GetBConfig.event
>
> ----- Original Message -----
> From: "Craig Tataryn" <Cr...@morganstanley.com>
> To: <st...@jakarta.apache.org>
> Sent: Tuesday, June 05, 2001 12:28 PM
> Subject: Work flow RFC
>
> > Hi, I would like your comments for the workflow item on our TODO list.
> > Currently this is how I've envisioned the workflow project:
> >
> > 1) A nice GUI type Applet or Application that has visual constructs
> > which can be connected in a Visio type manner to create an Activity
> > diagram or some other type of flow diagram.
> >
> > 2) This diagram will be persisted in an XML file which holds meta data
> > for the elements in diagram (position, type of construct (controller,
> > flat html page, cgi script, flow arrow, etc..)).
> >
> > 3) The diagram can be exported to a struts config file via XSLT (i.e.
> > workflow.xml -> workflow2struts.xsl -> struts-config.xml)
> >
> > 4) A diagram can also be imported from a struts-config.xml file via XSLT
> > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
> > course some sort of "pretty layout" code would have to be used to
> > un-jumble the mess of constructs that are sucked out of the
> > struts-config.xml file (i.e. take a guess at proper positioning
> > information).
> >
> > The GUI should employ some sort of extensibility mechanism like BSF
> > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell
> > (http://www.beanshell.org/) to allow users to plug-in their own
> > functionality (i.e. validation code) without jeopardizing the core code
> > (what I call the Emeril Lagasse technique -- BAM!).
> >
> > I realize this is a very high level look at the TODO but I think as we
> > get more comments we will get more granular and can start dishing out
> > segments.
> >
> > Let me know what you think.
> >
> > <tataryn:craig/>
> >
Re: Work flow RFC
Posted by Jonathan <ja...@i-2000.com>.
Again, Ive got to say look at the Barracuda project. They have one of these
gui configurers. Check it out at
http://barracuda.enhydra.org/Barracuda/GetBConfig.event
----- Original Message -----
From: "Craig Tataryn" <Cr...@morganstanley.com>
To: <st...@jakarta.apache.org>
Sent: Tuesday, June 05, 2001 12:28 PM
Subject: Work flow RFC
> Hi, I would like your comments for the workflow item on our TODO list.
> Currently this is how I've envisioned the workflow project:
>
> 1) A nice GUI type Applet or Application that has visual constructs
> which can be connected in a Visio type manner to create an Activity
> diagram or some other type of flow diagram.
>
> 2) This diagram will be persisted in an XML file which holds meta data
> for the elements in diagram (position, type of construct (controller,
> flat html page, cgi script, flow arrow, etc..)).
>
> 3) The diagram can be exported to a struts config file via XSLT (i.e.
> workflow.xml -> workflow2struts.xsl -> struts-config.xml)
>
> 4) A diagram can also be imported from a struts-config.xml file via XSLT
> (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
> course some sort of "pretty layout" code would have to be used to
> un-jumble the mess of constructs that are sucked out of the
> struts-config.xml file (i.e. take a guess at proper positioning
> information).
>
> The GUI should employ some sort of extensibility mechanism like BSF
> (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell
> (http://www.beanshell.org/) to allow users to plug-in their own
> functionality (i.e. validation code) without jeopardizing the core code
> (what I call the Emeril Lagasse technique -- BAM!).
>
> I realize this is a very high level look at the TODO but I think as we
> get more comments we will get more granular and can start dishing out
> segments.
>
> Let me know what you think.
>
> <tataryn:craig/>
>
Re: Work flow RFC
Posted by Craig Tataryn <Cr...@morganstanley.com>.
Ahhh, thanks Dan. I didn't realize it spat out a workflow file....
Thanks,
Craig.
Dan - Blue Lotus Software wrote:
> I think you misunderstood me. I'm not suggesting any SOAP interfaces or
> anything. I'm simply suggesting using Visio's workflow editor to create
> workflows that can be imported for Struts workflows. This should be able to
> be done by simply creating 2 XSL files: one to convert Visio's workflows
> into Strut's, and one to convert Strut's into Visio's.
>
> My primary point was to say that the next release of Visio has a workflow
> editor, it outputs an XML file, and the XML format will likely be public.
>
> -dan
>
> -----Original Message-----
> From:
> struts-dev-return-3146-dan=bluelotussoftware.com@jakarta.apache.org
> [mailto:struts-dev-return-3146-dan=bluelotussoftware.com@jakarta.apache.
> org]On Behalf Of Craig Tataryn
> Sent: Tuesday, June 05, 2001 6:52 PM
> To: Dan - Blue Lotus Software
> Cc: struts-dev@jakarta.apache.org
> Subject: Re: Work flow RFC
>
> I don't want to be platform specific though w.r.t. any tools generated from
> this TODO. However, if someone wanted to create a Visio addin for the
> front-end and some SOAP interfaces to the support objects I wouldn't oppose
> it.
>
> Craig.
>
> Dan - Blue Lotus Software wrote:
>
> > It would be nice if we could integrate directly with Visio. Microsoft is
> > pushing Visio as their workflow editor for BizTalk. Basically, it allows
> > Visio models to be connected to real code through the use of XML files,
> > pretty much as you have suggested (except without the XSL stage--the file
> > format Visio writes is read directly).
> >
> > At the XML One conference in London a few months back, I asked the two
> > Microsoft guys that were demoing a beta of the Visio workflow stuff (from
> > the upcoming .NET version) if they planned to publish the DTD. They
> didn't
> > really know. However, given their commitment to open standards with XML
> > (yes, I said that with a straight face), the DTD will likely be released
> to
> > a standards body.
> >
> > If this is the case, building XSL documents to handle the conversion each
> > way should be straightforward.
> >
> > -dan
> >
> > -----Original Message-----
> > From:
> > struts-dev-return-3136-dan=bluelotussoftware.com@jakarta.apache.org
> > [mailto:struts-dev-return-3136-dan=bluelotussoftware.com@jakarta.apache.
> > org]On Behalf Of Craig Tataryn
> > Sent: Tuesday, June 05, 2001 5:29 PM
> > To: struts-dev@jakarta.apache.org
> > Subject: Work flow RFC
> >
> > Hi, I would like your comments for the workflow item on our TODO list.
> > Currently this is how I've envisioned the workflow project:
> >
> > 1) A nice GUI type Applet or Application that has visual constructs
> > which can be connected in a Visio type manner to create an Activity
> > diagram or some other type of flow diagram.
> >
> > 2) This diagram will be persisted in an XML file which holds meta data
> > for the elements in diagram (position, type of construct (controller,
> > flat html page, cgi script, flow arrow, etc..)).
> >
> > 3) The diagram can be exported to a struts config file via XSLT (i.e.
> > workflow.xml -> workflow2struts.xsl -> struts-config.xml)
> >
> > 4) A diagram can also be imported from a struts-config.xml file via XSLT
> > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
> > course some sort of "pretty layout" code would have to be used to
> > un-jumble the mess of constructs that are sucked out of the
> > struts-config.xml file (i.e. take a guess at proper positioning
> > information).
> >
> > The GUI should employ some sort of extensibility mechanism like BSF
> > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell
> > (http://www.beanshell.org/) to allow users to plug-in their own
> > functionality (i.e. validation code) without jeopardizing the core code
> > (what I call the Emeril Lagasse technique -- BAM!).
> >
> > I realize this is a very high level look at the TODO but I think as we
> > get more comments we will get more granular and can start dishing out
> > segments.
> >
> > Let me know what you think.
> >
> > <tataryn:craig/>
RE: Work flow RFC
Posted by Dan - Blue Lotus Software <da...@bluelotussoftware.com>.
I think you misunderstood me. I'm not suggesting any SOAP interfaces or
anything. I'm simply suggesting using Visio's workflow editor to create
workflows that can be imported for Struts workflows. This should be able to
be done by simply creating 2 XSL files: one to convert Visio's workflows
into Strut's, and one to convert Strut's into Visio's.
My primary point was to say that the next release of Visio has a workflow
editor, it outputs an XML file, and the XML format will likely be public.
-dan
-----Original Message-----
From:
struts-dev-return-3146-dan=bluelotussoftware.com@jakarta.apache.org
[mailto:struts-dev-return-3146-dan=bluelotussoftware.com@jakarta.apache.
org]On Behalf Of Craig Tataryn
Sent: Tuesday, June 05, 2001 6:52 PM
To: Dan - Blue Lotus Software
Cc: struts-dev@jakarta.apache.org
Subject: Re: Work flow RFC
I don't want to be platform specific though w.r.t. any tools generated from
this TODO. However, if someone wanted to create a Visio addin for the
front-end and some SOAP interfaces to the support objects I wouldn't oppose
it.
Craig.
Dan - Blue Lotus Software wrote:
> It would be nice if we could integrate directly with Visio. Microsoft is
> pushing Visio as their workflow editor for BizTalk. Basically, it allows
> Visio models to be connected to real code through the use of XML files,
> pretty much as you have suggested (except without the XSL stage--the file
> format Visio writes is read directly).
>
> At the XML One conference in London a few months back, I asked the two
> Microsoft guys that were demoing a beta of the Visio workflow stuff (from
> the upcoming .NET version) if they planned to publish the DTD. They
didn't
> really know. However, given their commitment to open standards with XML
> (yes, I said that with a straight face), the DTD will likely be released
to
> a standards body.
>
> If this is the case, building XSL documents to handle the conversion each
> way should be straightforward.
>
> -dan
>
> -----Original Message-----
> From:
> struts-dev-return-3136-dan=bluelotussoftware.com@jakarta.apache.org
> [mailto:struts-dev-return-3136-dan=bluelotussoftware.com@jakarta.apache.
> org]On Behalf Of Craig Tataryn
> Sent: Tuesday, June 05, 2001 5:29 PM
> To: struts-dev@jakarta.apache.org
> Subject: Work flow RFC
>
> Hi, I would like your comments for the workflow item on our TODO list.
> Currently this is how I've envisioned the workflow project:
>
> 1) A nice GUI type Applet or Application that has visual constructs
> which can be connected in a Visio type manner to create an Activity
> diagram or some other type of flow diagram.
>
> 2) This diagram will be persisted in an XML file which holds meta data
> for the elements in diagram (position, type of construct (controller,
> flat html page, cgi script, flow arrow, etc..)).
>
> 3) The diagram can be exported to a struts config file via XSLT (i.e.
> workflow.xml -> workflow2struts.xsl -> struts-config.xml)
>
> 4) A diagram can also be imported from a struts-config.xml file via XSLT
> (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
> course some sort of "pretty layout" code would have to be used to
> un-jumble the mess of constructs that are sucked out of the
> struts-config.xml file (i.e. take a guess at proper positioning
> information).
>
> The GUI should employ some sort of extensibility mechanism like BSF
> (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell
> (http://www.beanshell.org/) to allow users to plug-in their own
> functionality (i.e. validation code) without jeopardizing the core code
> (what I call the Emeril Lagasse technique -- BAM!).
>
> I realize this is a very high level look at the TODO but I think as we
> get more comments we will get more granular and can start dishing out
> segments.
>
> Let me know what you think.
>
> <tataryn:craig/>
Re: Work flow RFC
Posted by Craig Tataryn <Cr...@morganstanley.com>.
I don't want to be platform specific though w.r.t. any tools generated from
this TODO. However, if someone wanted to create a Visio addin for the
front-end and some SOAP interfaces to the support objects I wouldn't oppose it.
Craig.
Dan - Blue Lotus Software wrote:
> It would be nice if we could integrate directly with Visio. Microsoft is
> pushing Visio as their workflow editor for BizTalk. Basically, it allows
> Visio models to be connected to real code through the use of XML files,
> pretty much as you have suggested (except without the XSL stage--the file
> format Visio writes is read directly).
>
> At the XML One conference in London a few months back, I asked the two
> Microsoft guys that were demoing a beta of the Visio workflow stuff (from
> the upcoming .NET version) if they planned to publish the DTD. They didn't
> really know. However, given their commitment to open standards with XML
> (yes, I said that with a straight face), the DTD will likely be released to
> a standards body.
>
> If this is the case, building XSL documents to handle the conversion each
> way should be straightforward.
>
> -dan
>
> -----Original Message-----
> From:
> struts-dev-return-3136-dan=bluelotussoftware.com@jakarta.apache.org
> [mailto:struts-dev-return-3136-dan=bluelotussoftware.com@jakarta.apache.
> org]On Behalf Of Craig Tataryn
> Sent: Tuesday, June 05, 2001 5:29 PM
> To: struts-dev@jakarta.apache.org
> Subject: Work flow RFC
>
> Hi, I would like your comments for the workflow item on our TODO list.
> Currently this is how I've envisioned the workflow project:
>
> 1) A nice GUI type Applet or Application that has visual constructs
> which can be connected in a Visio type manner to create an Activity
> diagram or some other type of flow diagram.
>
> 2) This diagram will be persisted in an XML file which holds meta data
> for the elements in diagram (position, type of construct (controller,
> flat html page, cgi script, flow arrow, etc..)).
>
> 3) The diagram can be exported to a struts config file via XSLT (i.e.
> workflow.xml -> workflow2struts.xsl -> struts-config.xml)
>
> 4) A diagram can also be imported from a struts-config.xml file via XSLT
> (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
> course some sort of "pretty layout" code would have to be used to
> un-jumble the mess of constructs that are sucked out of the
> struts-config.xml file (i.e. take a guess at proper positioning
> information).
>
> The GUI should employ some sort of extensibility mechanism like BSF
> (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell
> (http://www.beanshell.org/) to allow users to plug-in their own
> functionality (i.e. validation code) without jeopardizing the core code
> (what I call the Emeril Lagasse technique -- BAM!).
>
> I realize this is a very high level look at the TODO but I think as we
> get more comments we will get more granular and can start dishing out
> segments.
>
> Let me know what you think.
>
> <tataryn:craig/>
RE: Work flow RFC
Posted by Dan - Blue Lotus Software <da...@bluelotussoftware.com>.
It would be nice if we could integrate directly with Visio. Microsoft is
pushing Visio as their workflow editor for BizTalk. Basically, it allows
Visio models to be connected to real code through the use of XML files,
pretty much as you have suggested (except without the XSL stage--the file
format Visio writes is read directly).
At the XML One conference in London a few months back, I asked the two
Microsoft guys that were demoing a beta of the Visio workflow stuff (from
the upcoming .NET version) if they planned to publish the DTD. They didn't
really know. However, given their commitment to open standards with XML
(yes, I said that with a straight face), the DTD will likely be released to
a standards body.
If this is the case, building XSL documents to handle the conversion each
way should be straightforward.
-dan
-----Original Message-----
From:
struts-dev-return-3136-dan=bluelotussoftware.com@jakarta.apache.org
[mailto:struts-dev-return-3136-dan=bluelotussoftware.com@jakarta.apache.
org]On Behalf Of Craig Tataryn
Sent: Tuesday, June 05, 2001 5:29 PM
To: struts-dev@jakarta.apache.org
Subject: Work flow RFC
Hi, I would like your comments for the workflow item on our TODO list.
Currently this is how I've envisioned the workflow project:
1) A nice GUI type Applet or Application that has visual constructs
which can be connected in a Visio type manner to create an Activity
diagram or some other type of flow diagram.
2) This diagram will be persisted in an XML file which holds meta data
for the elements in diagram (position, type of construct (controller,
flat html page, cgi script, flow arrow, etc..)).
3) The diagram can be exported to a struts config file via XSLT (i.e.
workflow.xml -> workflow2struts.xsl -> struts-config.xml)
4) A diagram can also be imported from a struts-config.xml file via XSLT
(i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
course some sort of "pretty layout" code would have to be used to
un-jumble the mess of constructs that are sucked out of the
struts-config.xml file (i.e. take a guess at proper positioning
information).
The GUI should employ some sort of extensibility mechanism like BSF
(http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell
(http://www.beanshell.org/) to allow users to plug-in their own
functionality (i.e. validation code) without jeopardizing the core code
(what I call the Emeril Lagasse technique -- BAM!).
I realize this is a very high level look at the TODO but I think as we
get more comments we will get more granular and can start dishing out
segments.
Let me know what you think.
<tataryn:craig/>