--- Joe Germuska <[EMAIL PROTECTED]> wrote:
> However, I can see using the contents of the forward element as a way
> to provide more than one form bean to the renderer. I'll think about
> this some more. How would you actually make them available to the
> renderer? Via a map? Expect the renderer to fish them out of
> request or session scope?
I was thinking we could have one renderer per form. This way, if a form gets
reused by different views, the renderer can be reused as well. With this, a
slightly modified version of your initial draft for the renderer's method
signature could be used:
public void render(ForwardConfig config, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception;
I would also suggest giving the method access to the ServletContext and/or
ModuleConfig. Somehow. It could be argued that even if the
one-ForwardConfig-instance implementation is preserved, a ForwardConfig
instance only applies to one module, so it could carry the ServletContext and
ModuleConfig into the render method.
> >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)
>
> I don't think I agree with this, or at least, I think you have to
> preserve the possibility that different actions would want to use the
> same form definition in different scopes. I don't think that would
> be a very good design, because of the risk of confusion, but I'm not
> ready to say we should block it.
>
> Obviously we can't move the scope setting without sacrificing
> backwards compatibility -- that is, we can't move it at all, since we
> won't sacrifice compatibility -- although we could have a default
> scope on the form bean if that were helpful. I'm not sure I see that
> it is, but we can see...
I agree about the backward compatibility concern. The issue I see is how the
RequestProcessor will store the "output" form that the Renderer prepopulated.
Right now, the scope is dictated by the Action receiving the form. How
would the RP know what that is? Even if the point of prepopulation is to
allow the form to be rendered, thus making it possible for the RP to store it
in request scope and be discarded once the view is rendered, a session scoped
form might be prepopulated with fields that the immediate view will not use
but needs to be preserved for a later purpose. Storing that in request scope
by default wouldn't work. I'm not sure I'm comfortable with the other option
either, which is to store the "output" form in session scope, since the
receiving Action could've only specified the request scope. I wouldn't mind
being enlightened, though.
- 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]
