You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2005/01/06 17:35:13 UTC
Struts 1.3 ViewController (RE: Coupling, Struts and JSF)
At 7:30 AM +0000 1/6/05, JAN.Cumps@intl.pepsico.com 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
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 ViewController (RE: Coupling, Struts and JSF)
Posted by Joe Germuska <Jo...@Germuska.com>.
>The point of this reply is that you'd want to ensure that your setup
>command gets called as part of the render() lifecycle, so that you can
>do the setup stuff even if your portlet wasn't the one that processed
>this request's form values. It might even mean some thought should be
>put into separating "the" request processing chain into two chains, so
>that you can simulate the same thing for Tiles-based apps (including
>supporting the Tiles Controller interface, which serves the same
>"render setup" purpose).
Thanks. I have not had much chance to get up to speed with portlets.
Separating the chain into two is fundamental to my current vision, so
that the "main" context can be wrapped in API-independent
ActionContext/ViewContext classes. So I think that one could use the
same base chains but with a "portlet-complete" variant instead of a
"servlet-complete", which would address the differences. I'd love to
produce something which is Portlet friendly, but I'm not going to
drop everything to learn all about Portlets to do it, since I have no
plans to be using Portlets.
I think the TilesPreProcessor class should end up causing all tiles
controllers to be invoked, since it's only a light wrapper around the
behavior from the TilesRequestProcessor. In fact, although I don't
use Tiles controllers extensively, I do know that I have some in my
current app which work correctly using the TilesPreProcessor command,
even with a singular request processing chain.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 ViewController (RE: Coupling, Struts and JSF)
Posted by Craig McClanahan <cr...@gmail.com>.
If working in portlets is still an item of interest for a chained
request processor, there's an interesting synergy with the way that
JSR168 defines its request processing lifecycle as well.
When a portlet request comes in, the container passes the request to
the processAction() method of the one-and-only portlet, if any, that
will process this form submit. Then, the container calls the render()
method of every portlet that is on the current page (potentially in
parallel on multiple threads) to ask each portlet to render their own
rectangles -- the container then aggregates the output together into a
single response.
The point of this reply is that you'd want to ensure that your setup
command gets called as part of the render() lifecycle, so that you can
do the setup stuff even if your portlet wasn't the one that processed
this request's form values. It might even mean some thought should be
put into separating "the" request processing chain into two chains, so
that you can simulate the same thing for Tiles-based apps (including
supporting the Tiles Controller interface, which serves the same
"render setup" purpose).
(If you're following the Shale design at all, you'll see that it fits
quite elegantly ... ViewController.prerender() will get called for all
the portlets on a page, because JSF's lifecycle already has the same
separation between "action" processing and "render" processing that
the portlet lifecycle has. And Shale will support ViewController
functionality on subviews at some point too.)
Craig
On Thu, 6 Jan 2005 11:38:27 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 11:03 AM -0600 1/6/05, Hubert Rabago wrote:
> >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.
>
> I would expect that the chain still has some considerable evolution
> ahead of it. I think once we establish "ActionContext" and
> "ViewContext" classes and reorganize things so that these are created
> and populated and passed along to the action and view chains (which
> now simply all get a commons-chain ServletWebContext), then things
> will be essentially stable. In so far as that may change or obsolete
> existing commands, I wouldn't want to promise to maintain backwards
> compatibility, so using this stuff now is pretty much signing up for
> tracking a bit of change.
>
> That said, it works, and it is always helpful to have more people
> using it, testing it, and providing feedback on it!
>
> >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"/>
>
> Remember that I offered these as simply an example of how we are
> doing something like this in an application here -- at the moment I'm
> not too hot on adding a whole new config element (render), but let's
> see what we need.
>
> Just to clarify, I think this is the form that your variant syntax would take:
>
> <render path =".group.SelectDealers"
> type ="x.y.z.webui.GroupRenderer"
> method ="loadUserPreferredDealers">
> <form
> name ="dealerSelectionForm"
> scope ="request"/>
> </render>
>
> (The type and method are relevant to the renderer, not the form.)
> This would support multiple forms per render config, but if you could
> simply have multiple render configs, you might not need that. Our
> existing solution supports a list of render configs.
>
> My preference now would be to try to extend the "forward" element
> rather than add a new "render" element, since I think logically they
> will always march together. One problem with providing multiple
> forms to any small chunk of code would be "how does the chunk know
> which form to use?" Having only one solves the problem!
>
> However, while you can simply postulate that a single view/response
> can have multiple renderers or commands, it can only have one
> forward. So if we try to hook this to the forward element, we have
> to handle multiple forms some other way.
>
> Now, if we gave the ViewContext object the ability to look up a form
> based on its name and scope, then we could simply let those two
> configuration parameters pass to a chain command, and if you had two
> forms, you'd put two commands in your preprocessing chain. This
> seems kind of promising, and it minimizes the changes we have to make
> to the ForwardConfig (which is also nice because the ForwardConfig
> doesn't go out into the wild, so any changes we make to it have to be
> passed along to the ActionForward which is constructed based upon it,
> which is one more step compared to ActionConfigs, which are passed
> directly in to the executing action (as ActionMappings).
>
> Making this an interaction between each command and the ViewContext
> is nice, because then you really could reuse the form-prep command in
> multiple chains with minimal reconfiguration. We could even provide
> a base implementation of this class which had a getForm(Context)
> method.
>
> Now, one thing is that I would like for ViewContext (and
> ActionContext) to have no dependencies on the Servlet API. We can
> make subclasses which expose those when necessary, but by avoiding
> them, we help continue to set ourselves up for more general uses. If
> we say this, then I wonder whether there's any issue in passing in
> the "scope". Since it's only a string, I'd say not, since we can
> imagine that other execution environments would also have scopes,
> particularly a distinction between "request" and "session", and in
> any case, if they are only strings, then we're not really binding to
> the Servlet API.
>
> I'm liking the way this is unfolding...
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 ViewController (RE: Coupling, Struts and JSF)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:03 AM -0600 1/6/05, Hubert Rabago wrote:
>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.
I would expect that the chain still has some considerable evolution
ahead of it. I think once we establish "ActionContext" and
"ViewContext" classes and reorganize things so that these are created
and populated and passed along to the action and view chains (which
now simply all get a commons-chain ServletWebContext), then things
will be essentially stable. In so far as that may change or obsolete
existing commands, I wouldn't want to promise to maintain backwards
compatibility, so using this stuff now is pretty much signing up for
tracking a bit of change.
That said, it works, and it is always helpful to have more people
using it, testing it, and providing feedback on it!
>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"/>
Remember that I offered these as simply an example of how we are
doing something like this in an application here -- at the moment I'm
not too hot on adding a whole new config element (render), but let's
see what we need.
Just to clarify, I think this is the form that your variant syntax would take:
<render path =".group.SelectDealers"
type ="x.y.z.webui.GroupRenderer"
method ="loadUserPreferredDealers">
<form
name ="dealerSelectionForm"
scope ="request"/>
</render>
(The type and method are relevant to the renderer, not the form.)
This would support multiple forms per render config, but if you could
simply have multiple render configs, you might not need that. Our
existing solution supports a list of render configs.
My preference now would be to try to extend the "forward" element
rather than add a new "render" element, since I think logically they
will always march together. One problem with providing multiple
forms to any small chunk of code would be "how does the chunk know
which form to use?" Having only one solves the problem!
However, while you can simply postulate that a single view/response
can have multiple renderers or commands, it can only have one
forward. So if we try to hook this to the forward element, we have
to handle multiple forms some other way.
Now, if we gave the ViewContext object the ability to look up a form
based on its name and scope, then we could simply let those two
configuration parameters pass to a chain command, and if you had two
forms, you'd put two commands in your preprocessing chain. This
seems kind of promising, and it minimizes the changes we have to make
to the ForwardConfig (which is also nice because the ForwardConfig
doesn't go out into the wild, so any changes we make to it have to be
passed along to the ActionForward which is constructed based upon it,
which is one more step compared to ActionConfigs, which are passed
directly in to the executing action (as ActionMappings).
Making this an interaction between each command and the ViewContext
is nice, because then you really could reuse the form-prep command in
multiple chains with minimal reconfiguration. We could even provide
a base implementation of this class which had a getForm(Context)
method.
Now, one thing is that I would like for ViewContext (and
ActionContext) to have no dependencies on the Servlet API. We can
make subclasses which expose those when necessary, but by avoiding
them, we help continue to set ourselves up for more general uses. If
we say this, then I wonder whether there's any issue in passing in
the "scope". Since it's only a string, I'd say not, since we can
imagine that other execution environments would also have scopes,
particularly a distinction between "request" and "session", and in
any case, if they are only strings, then we're not really binding to
the Servlet API.
I'm liking the way this is unfolding...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3 ViewController (RE: Coupling, Struts and JSF)
Posted by Hubert Rabago <hr...@gmail.com>.
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 <Jo...@germuska.com> wrote:
> At 7:30 AM +0000 1/6/05, JAN.Cumps@intl.pepsico.com 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
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org