struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam L" <adam_l_lev...@hotmail.com>
Subject Re:[PARTLY SOLVED] workflow - Re: integration with other app
Date Sun, 28 Sep 2003 02:27:19 GMT
Okay.. the back button going to the prior screen.. you'd think i've never
done webapps before.. my no-cache headers were missing. that's resolved.

I've begun to grok the workflow pattern a bit more, and here's what i've
come up with

  I was picturing the overall task as a workflow.  However, if you look at
each discrete unit of work in the entire task, each unit is actually its own
workflow.  And, the pieces/steps of that unit are what you should use to
define individual "workflows" in the sense of the extension.
 Ergo, task 1 has steps 1, 2 and 3.  which gives you workflow1, workflow2,
and workflow3.
    each workflow<n> should likely have 2 steps:   display the page (enter
the workflow), and submit data from that page (end of workflow).  along with
these 2 steps, there is also a possible workflow violation, which, ideally,
should flow you to the 'display the page' step.   Each end(termination) of a
workflow's primary flow will lead into the next step's 2ndary workflow
chain.

  granted, this is a very simplistic overview, and not applicable for all
tasks.. but, it's a nice foundation step that wasn't readily obvious in the
documentation (or I was just being horribly dense).

 So, have I grokked this properly ?  Is there something else I"m missing?

-- adam



----- Original Message -----
From: "Adam L" <adam_l_levine@hotmail.com>
To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
Sent: Saturday, September 27, 2003 2:58 PM
Subject: Re: workflow - Re: integration with other app


> Matthias:
>
>    I've been dinking with this workflow extension for awhile, amidst other
> madness, and here's what I've come to observe.   Please let me know if my
> observations are correct, and if there's not a "better/easier" way to
> achieve my goals:
>
>    I have a logical process flow for achieving the task of entering new
> data.  This requires 7 different screens on input information, as each
> subsequent entry page requires info from the prior.     I originally
defined
> this as one primary "workflow".  Everything flows from one page to the
next,
> so long as I don't use the browser back button and change prior
information.
> If I do this (hit browser back, change  a form field, submit),  the next
> page ends up blank; granted, I haven't added any "back button" links to
the
> page.  This is obviously due to a workflow violation exception being
thrown.
> That's fine.    However, in order for the workflow engine to redirect the
> user to the proper page,  it appears i'm going to have to break down my
one
> workflow into 7 individual "workflows", each leading to eachother using
> primary and secondary flows, and then adding in a global foward for a
> violation for each one of those new 7 segments.   Is this correct?  It
seems
> like a lot of work for a simple process, and I'm afraid I'm missing
> something.
>
>    Also, back to the browser back button.  In running the demo, I can see
> that hitting the browser back from wizard page 2 will continually redirect
> me back to wizard page 2.  yet, in my application, hitting the back button
> just takes me to the prior screen.  Is this a result of not having the
> violation logic in place?  If so, why isn't there a blank screen like I
> described above?
>
>    Thank you for any insight you can provide.
>
> -- adam
>
>
> ----- Original Message -----
> From: "Matthias Bauer" <matthias.bauer@livinglogic.de>
> To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> Sent: Monday, September 15, 2003 1:59 AM
> Subject: Re: workflow - Re: integration with other app
>
>
> > Fortunately I am far enough away to avoid your kiss ;-)
> >
> > Please let me know, if you believe something is missing. I am sure I can
> > give you some more hints on how to solve a specific task. The Struts
> > Workflow Extension is a very powerful, yet low-level framework. Thus, it
> > offers very much flexibility but sometimes the right way to achieve a
> > solution is not as apparent as desired.
> >
> > Just in case you are interested: We are also offering commercial support
> > for this extension and Struts itself.
> >
> > --- Matthias
> >
> >
> > Adam Levine wrote:
> >
> > > Matthias:
> > >  I could kiss you!   I've been struggling with this issue and have
> > > been going bald over the last week doing a lot of my own engine
> > > work.   I can't wait to try this out and see if it doesn't work for me
> > > as cleanly as it looks.
> > >
> > >
> > >
> > >
> > > From: Matthias Bauer <matthias.bauer@livinglogic.de>
> > > Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > > To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > > Subject: Re: workflow - Re: integration with other app
> > > Date: Fri, 12 Sep 2003 08:35:36 +0200
> > >
> > > Martin,
> > >
> > > the Struts Workflow Extension http://www.livinglogic.de/Struts/
> > > addresses some of the issues you raise. Especially the thing about a
> > > workflow scope. But it is also easily possible to build reusable
> > > action sequences: Consider for instance a confirmation dialog that
> > > demands the user to press a "Yes" and "No" button. You will need this
> > > multiple times within an application, but you normally want to code
> > > the necessary actions only once and reuse them in different contexts
> > > (i. e. with a customized question and return action).
> > >
> > > Please let me know, when you have any questions related to the Struts
> > > Workflow Extension.
> > >
> > > --- Matthias
> > >
> > > Martin Naskovski wrote:
> > >
> > >> One thing I find particularly cumbersome in Struts is web page
> > >> workflow. Currently, if I want to push "Cancel" for instance, or
> > >> "Submit" on a certain page, in the Action itself, I have to hard code
> > >> where to go next and/or pass any dynamically generated parameters
> > >> through the request scope or the query string (if doing a
> > >> sendRedirect). I also have to use hidden form fields to tell each
> > >> submission button on a form, where to go next, depending on where I
> > >> came from (a certain action mapping, e.g.).
> > >>
> > >> Is there a better way to do this, where the flow of the screens can
be
> > >> specified statically, or maybe if not statically at least within a
> > >> screen workflow module that each action will tell that module where
> > >> to go next, depending on what button was pushed on that form?
> > >>
> > >> Does JSF address this perhaps? Or has someone independently made a
> > >> Struts pluggable module that can control screen flow? It seems there
> > >> almost is a need for some sort of a 'workflow' scope, where when I
> > >> start a certain use-case from one of the menus in the application,
the
> > >> 'workflow scope' is preserved throughout the use-case lifetime, and
if
> > >> for some reason this flow is broken by the user, the workflow scope
> > >> should be destroyed.
> > >>
> > >> I've been able to immitate a workflow scope with the session scope,
> > >> but it isn't as elegant as I want it to be, or rather, as delimited
> > >> from the application logic as I'd like it to be... Plus stuff in the
> > >> session scope hangs around much longer than as if I had a workflow
> > >> scope.
> > >>
> > >> I've been wondering if there's any solutions already to this - it
> > >> seems that is the _only_ thing Struts is lacking in.
> > >>
> > >> Thanks.
> > >>
> > >> Martin
> > >> --
> > >>
> > >>
> > >> Thursday, September 11, 2003, 4:31:29 PM, you wrote:
> > >>
> > >> TH> This seems more in scope for some of the ServerSide forums than
> > >> Struts.
> > >>
> > >> TH> http://www.theserverside.com/home/index.jsp
> > >>
> > >> TH> Our framework ends where the database begins -:0)
> > >>
> > >> TH> Tiles is sufficient for customizating layout and such.
> > >>
> > >> TH> -Ted.
> > >>
> > >> TH> Gregory Seidman wrote:
> > >>
> > >> TH> <snip/>
> > >>
> > >>
> > >>
> > >>>> My purpose in posting this to the list is to get the benefit of
the
> > >>>> membership's collective experience. Is Torque a good choice? Is
> > >>>> creating a
> > >>>> separate database for each user unacceptable from the point of
view
> > >>>> of a
> > >>>> website which provides services on a per-user basis? Is Tiles
> > >>>> sufficient
> > >>>> for customizing layout and such? Any suggestions, tales of woe,
or
> > >>>> design
> > >>>> critiques are appreciated.
> > >>>>
> > >>>> Please do not CC me; I am subscribed to the list.
> > >>>> --Greg
> > >>>>
> > >>>>
> >
>>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > >>>> For additional commands, e-mail:
> > >>>> struts-user-help@jakarta.apache.org
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> > > _________________________________________________________________
> > > Get a FREE computer virus scan online from McAfee.
> > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>

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


Mime
View raw message