Hi Joe,
I've also been interested in these discussions, though our earlier
discussions revolved around the old RequestProcessor. I haven't had a
chance to try out the shiny new chain (or is it still rusty and needs
some polishing?), so lately I've been limited to lurking.
That said, I too believe that it would be helpful if Struts provides a
more formal way of initializing the view, including prepopulating
ActionForms. On earlier discussions, you pointed out that a big
consideration should be how they are configured, and I agree. I hope
whatever evolves as you follow through this idea doesn't prevent
further evolution to support prepopulating multiple forms.
The use case I've encountered, which I've also shared before with you,
is when a user edits a record after a search. The requirements may be
that the user should be allowed to either (a) edit the selected
record, or (b) run a modified search. In such a case, the page would
display at least two forms: one with a record ready to edit, and a
form containing the last search query used.
The <render> element you shared in an earlier email listed the form
name along with the path. To support the possibility of multiple
forms, I think the form information can be nested in another element.
from
> <render
> path =".group.SelectDealers"
> type ="x.y.z.webui.GroupRenderer"
> method ="prepareSelectDealers"
> form ="dealerSelectionForm"
> scope ="request"
> />
to
<!-- render a page with one or more forms -->
<render path =".group.SelectDealers">
<form
name ="dealerSelectionForm"
type ="x.y.z.webui.GroupRenderer"
method ="loadUserPreferredDealers"
scope ="request"/>
</render>
<!-- render a page that doesn't need forms -->
<render path =".group.SelectDealers"
type ="x.y.z.webui.GroupRenderer"
method ="prepareSelectDealers"/>
Hubert
On Thu, 6 Jan 2005 10:35:13 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 7:30 AM +0000 1/6/05, [EMAIL PROTECTED] wrote:
> >Ted once suggested to add a 'FrontController'.
> >That class could be optionally plugged into the action mapping, and
> >would do the view preparation.
>
> This is an idea I've been poking at and talking about for quite some
> time, but I am getting the feeling that there isn't much interest, or
> at least no strong feelings. It's been a long time since anyone has
> expressed any preferences for how something like this would be
> implemented.
>
> Now that Chain is in place, we are easing in to a model where this
> can be done with either very little configuration required, or with a
> fair bit of systemic support. I'm looking at splitting the default
> chain into an "action" command (which delegates to most of the
> familiar chain) and a "view" command (which would delegate to a small
> chain, right now just "PerformForward," optionally preceded by
> "TilesPreProcess". The lightest weight approach would be to slip a
> command or two in at the beginning of the view sub-chain which looked
> up an optional ViewController, which would just be a chain Command.
> Something like this would probably simply extract the "path" from the
> active ActionForward and use it as the name of a command to lookup.
> (How to best specify the catalog?)
>
> A slightly heavier approach would be to add configuration properties
> to ForwardConfig and ActionForward which would allow you to specify
> things in your struts-config which would be helpful to a
> ViewController -- for instance, you might want to specify the name
> and scope of a form bean which should be made available to the
> ViewController for pre-populating, and maybe you would want to
> explicitly configure a catalog/command lookup value in the
> struts-config instead of or in addition to the path-based lookup.
>
> Since form pre-population is one of the things I think Struts should
> make easier than it currently does, I'm leaning towards the second
> approach. You could certainly configure your commands with enough
> information that they could find the form to pre-populate themselves,
> but why not make it more consistent. The biggest hitch would be use
> cases in which the destination view actually needs to prepopulate two
> different ActionForms, but this is something I have yet to encounter
> in my own development, so I won't get hung up on it until someone who
> has encountered it speaks up with a better idea!
>
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
