Sorry for jumping in, but I've been lurking on this thread
and I use this pattern quite frequently.
SetupAction ===> page ===> ProcessAction ===> page
I have a dynamic form defined in my struts config file and
mapped to both SetupAction and ProcessAction. I don't have
to manually create the form because Struts does this for me.
Its actually very simple:
In SetupAction:
ActionForward forward = mapping.findForward("success");
DynaBean input = (DynaBean)form;
// populate input
return forward
Upon validation failure, my ProcessAction input attribute is set to the
action mapping for SetupAction. I can see how this could be seen as a bit
of a hack, but its just using the existing framework to meet my
requirements.
If the data to display is static I just place it in ServletContext
when the application starts up and there is no need to necessarily have
a SetupAction.
Upon validation, you can simply forward directly to the input page.
How is that clumsy? Am I missing something?
robert
> -----Original Message-----
> From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 18, 2003 1:44 PM
> To: 'Struts Users Mailing List'
> Subject: RE: [repost] Special view information -> ActionForm or request?
>
>
> As far as the forms are concerned, I whole-heartedly agree that
> the current
> notion of populating the form "one the way" to getting mapped to the view
> seems pretty clumsy. I would almost advocate having the forms to be
> "pulled" (as above) out of some persistant service thingy (highly
> technical
> term). Of course, it would then require that we have some sort
> of populate
> or load method that will do something before we process anything.
> It seems
> also like a variation of how the dispatchaction works would be kinda cool.
> Allowing, either based on URL or some other request info, you to determine
> if you are doing a read or a write "before" you even get to the
> action would
> be the better way to go.
>
> Of course, that's just my perspective, but, your notion of the
> clumsiness of
> stuffing data into the form in the Action (especially after the
> request data
> has already been stuffed in there once) struck a chord with me.
>
> Evidently the development in struts is a little more active than
> I thought,
> I may have to start pulling down snapshots...
>
> -----Original Message-----
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 18, 2003 1:29 PM
> To: Struts Users Mailing List
> Subject: RE: [repost] Special view information -> ActionForm or request?
>
>
> I don't have a very strong opinion, but for form *choices*, I've
> always preferred to put them into some page-accessible context before
> dispatching to a page.
>
> I wrote a class called DigestingPlugIn which was added to Struts
> after the 1.1 release which is designed to make it easy to put a menu
> like this into the application context so that it's always available
> to all your pages, even if they don't go through an action before
> display. Of course, if the choices are dynamic and specific to the
> request or the session, this doesn't work, but for things like
> sharing a menu of states or countries, it works pretty well. If you
> aren't comfortable using unreleased Struts code, you can get a
> library version of this class from http://demo.jgsullivan.com/struts/
>
> Another alternative for request/session-specific options would be to
> extend the OptionsCollection tag to be smarter about how it gets the
> collection for iteration -- this would allow you to route people
> directly to the JSP without needing to go through an action class.
>
> We've been having a vigorous discussion over the last couple of days
> about the best way to prefill form *values* in a pre-validation
> context, and to be honest, I feel like this is a use case which
> Struts doesn't address very well. It feels clumsy to fool around
> with creating an ActionForm and populating it "on the way" to the
> view; should I just get over that? Or is this something about Struts
> that deserves a closer look with an eye towards addressing the use
> case more directly? I've been meaning to search the archives to see
> what discussions have come up, but since I'm sending this message, I
> guess I'll just dump it out there and see what people think...
>
> Joe
>
>
>
>
> At 12:35 -0400 9/18/03, Mainguy, Mike wrote:
> >I also would like other's opinion on this. Right now, use a service
> >locator style class to stuff all my lookup stuff into the request
> >object manually. I have, however, used collections in the formbeans for
> >this. I can't, off the top of my head, think of any significant
> >advantages to using a form bean. One disadvantage, however, is you can
> >only have 1 form bean per action, so lookups across multiple actions
> >will need to have duplicate code.
> >
> >
> >-----Original Message-----
> >From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, September 18, 2003 10:15 AM
> >To: Struts Users Mailing List
> >Subject: [repost] Special view information -> ActionForm or request?
> >
> >
> >Sorry for the repost. Has this already been discussed? I couldn't
> >find it in the archives.
> >
> >Original message:
> >
> >Sometimes views need special information to display correctly, like a
> >bean with the values needed to render a dropdown list. Is it
> >considered a Struts best-practice to include this information in the
> >ActionForm or should the Action which prepares this information store
> >the information in the request instead?
> >
> >Thanks,
> >
> >Matt
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >This message and its contents (to include attachments) are the
> >property of Kmart Corporation (Kmart) and may contain confidential
> >and proprietary information. You are hereby notified that any
> >disclosure, copying, or distribution of this message, or the taking
> >of any action based on information contained herein is strictly
> >prohibited. Unauthorized use of information contained herein may
> >subject you to civil and criminal prosecution and penalties. If you
> >are not the intended recipient, you should delete this message
> >immediately.
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "If nature worked that way, the universe would crash all the time."
> --Jaron Lanier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message and its contents (to include attachments) are the
> property of Kmart Corporation (Kmart) and may contain
> confidential and proprietary information. You are hereby notified
> that any disclosure, copying, or distribution of this message, or
> the taking of any action based on information contained herein is
> strictly prohibited. Unauthorized use of information contained
> herein may subject you to civil and criminal prosecution and
> penalties. If you are not the intended recipient, you should
> delete this message immediately.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
