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: workflow - Re: integration with other app
Date Sat, 27 Sep 2003 19:58:14 GMT
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


Mime
View raw message