--- Joe Germuska <[EMAIL PROTECTED]> wrote:
> ForwardConfig could have a "form" or "formName" property (since
> 'name' is already taken), and using that, the "output" form would be
> looked up more or less the way forms are now, taking advantage of
> some recent refactorings so that you no longer require an
> ActionMapping to get a form. This would give the Renderer something
> it could pre-populate using whatever logic and system information it
> needed, should it care to.
>
> The renderer could return the same ForwardConfig which was passed to
> it, or it could create a new one: for example, the new one might
> rewrite the path to include localization information (as described in
> the post mentioned above.)
I'd be concerned about associating a form with a ForwardConfig. It's
possible that the resulting view could contain more than one form needing
prepopulation, and we don't want to limit the entire response chain to only
prepopulate one of them, or at least imply that that's the limit.
Following the use case you mentioned on the user list, where the action
accepted the search keys and displays search results, the resulting view
could include both the search result in a form for editing, and a form to
allow the user to run another search (abandoning the current record). I
personally have come across this scenario multiple times in multiple web apps
I've been involved in.
In such a case, (A) do we facilitate it by letting the function return
another ForwardConfig which is associated with another form? Or (B) should
the method just use the new createActionForm to create new forms and store
them in the right scope?
(A) If we use another ForwardConfig, we could reuse the one used by the
original search form. It could be declared as a global forward which could
be reused in all pages needing that form. Sure sounds like Tiles. This
echoes the intentions mentioned in earlier threads, which is to provide this
functionality to the core. This requires chaining a ForwardConfig for each
form a view will need.
(B) If we use createActionForm with an additional RequestUtils
(ResponseUtils? oops, deprecated.) method to "set" a form. RequestUtils
creates the blank form, the PageController populates it, and a RequestUtils
method sets the form in the proper scope using the proper attribute name.
Either way, it's looking like it might make sense to move the scope setting
to the form definition, or at least allow a default setting there which will
be honored if an action mapping doesn't specify a form scope. (Could be a
topic for another thread)
Could we instead define the forms as children of ForwardConfig? This seems
to make more sense and doesn't imply that a view is limited to one form.
<form-beans>
<form name="form1"
type="o.a.s.a.DynaActionForm"
renderer="com.corp.Renderer1">
<form-property .../>
</form>
<form name="form2"
type="com.corp.MyActionForm"
renderer="com.corp.Renderer2"/>
</form-beans>
<action ...>
<forward name="view1">
<form name="form1"/>
</forward>
<forward name="view2">
<form name="form1"/>
<form name="form2"/>
</forward>
<forward name="view3" type="com.corp.PageController1"/>
</action>
The PageController would then concentrate on non-form data needed by the
view.
Also, maybe we can call the Renderer's method "render".
> Like I said, this is just something to shoot down... so fire away!
>
> Joe
Line this up among those to shoot down.
Hubert
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
