> The lead on the Barracuda project is a subscriber to the Struts list!
> Christian Cryder ([EMAIL PROTECTED]). 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 [[EMAIL PROTECTED]]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: Jonathan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 05, 2001 11:10 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Work flow RFC
>
>
> The lead on the Barracuda project is a subscriber to the Struts list!
> Christian Cryder ([EMAIL PROTECTED])
> 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" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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
> >
>
