Thanks Scott - a follow up clarification for you or anyone else that may be able to
help.
We understand that Intake leaves data in the request (RunData in our case) so
that our Action class can do something with the data. Every example we have
seen has an action class with code that is basically:
if (valid data)
setTemplate(show a success template)
else (it is invalid data)
setTemplate(reshow the form we are processing)
Our flow looks more like...
if (valid data)
save the valid data in the session
redirect to a bookmarkable URL for a different page
else (if invalid data)
save the invalid data in the session
redirect to a bookmarkable URL for the original form we are processing
By 'bookmarkable URL', we mean something like:
machine:8080/turbine?param1=foo¶m2=bar
Versus the URL that you have after a form POST submission normally is just:
machine:8080/turbine
Has anybody else come up with a good methodology for handling POST submissions
and ending up at a bookmarkable URL?
Our flow outlined above depends on being able to save the valid or invalid data
from one request to another, which so far is proving to be not easy with Intake,
because Intake likes to recycle the Groups/Fields/IntakeTool objects between
requests. (Which is great for avoiding object creation/gc, but not great when
we want to keep one of the Groups/Fields/IntakeTool objects around for a later
request...)
Ideas?
Pat, Erich, et al
Scott Eade wrote:
> Intake does leave the data in the request - this allows for the page to be
> redisplayed if you detect an error and return to the same page.
>
> The data is stored in the request within the group used on the data entry
> page. Are you attempting to use this same group on the subsequent page?
>
> A normal turbine based application would follow these steps:
> 1. User enters data on page
> 2. Action validates data, if invalid return to input page, if valid save the
> data to the database and tell turbine to go to the next page
> 3. Next page re-retrieves the data from the database for display (outside of
> the context of intake).
>
> HTH,
>
> Scott
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
> > From: "Pat Ryan" <[EMAIL PROTECTED]>
> > Reply-To: "Turbine Users List" <[EMAIL PROTECTED]>
> > Date: Tue, 15 Oct 2002 17:33:36 -0500
> > To: Turbine Users List <[EMAIL PROTECTED]>
> > Subject: Intake and carrying around data / data validation
> >
> >
> > Hello Intake Wizards! :-)
> >
> > We are using Intake (or trying to) in our web application that is
> > Jetspeed-based, and therefore has Turbine, Intake, etc for free because they
> > come with Jetspeed...
> >
> > We are trying to understand how to properly use Intake for data validation.
> > The
> > basic problem we are having is that there does not seem to be any way to
> > 'carry
> > forward' Intake data from one request to another, or from one page to another.
> >
> > For example, how about a form that you fill in a few fields, and submit it,
> > and
> > then a 'form' Action class wants to save the data you submitted into the
> > session
> > and redirect you to a different URL where a 'view' Action class will pull the
> > saved data out of the session, and put it into the context so that a velocity
> > template can render it.
> >
> > Problems that come up include...
> > * We tried saving the IntakeTool itself from request to request, since it
> > contains the Groups & Fields, but the Pull service wants to recycle it after
> > each request so it works once and then the data goes away
> > * We tried to pull our intake Group out of the IntakeTool and carry that
> > forward, but IntakeTool.removeGroup() recycles the Group, which blows the data
> > away
> >
> > Our last idea was to make a business object and do the
> > mapToObject/setProperties
> > thing, but that craps out when a form is submitted with invalid data, because
> > formGroup.setProperties(bizObj) throws an exception when trying to set the
> > values from formGroup into the bizObj.
> >
> > So.
> >
> > Has anybody figured out how to use Intake with a lifespan of longer than a
> > single request? Thanks!!!
> >
> > Pat, Erich, et al
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
