Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (hermes.apache.org: domain of craigmcc@gmail.com designates
 64.233.170.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=QUe7dZIyJlR4Wl+oSHQrhI3uLGszAXx359s8eIR3s2xpEzMaxUxbElBe/Ud+bZD5k5koKrEu1IXBK8j96Tl9aGEF8u9wgO89BfJdrtm2i3qW6adfzmhrLo2M0ucaKhM5BMJt4jPIdccv7Siv96vnGBatssv9tKq+rflaaP5z+8Y=
Message-ID: <f8b39ace05010610215885359f@mail.gmail.com>
Date: Thu, 6 Jan 2005 10:21:46 -0800
From: Craig McClanahan <craigmcc@gmail.com>
Reply-To: craigmcc@apache.org
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: Struts 1.3 ViewController (RE: Coupling, Struts and JSF)
Cc: Hubert Rabago <hrabago@gmail.com>
In-Reply-To: <a0620071dbe03213727d5@192.168.2.93>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <70040413C055E64198177733CAE9F5D711F6E7@pepwmu00057.cww.pep.pvt>
	 <a0620071cbe0315a77234@192.168.2.93>
	 <7b809eef050106090333624dd7@mail.gmail.com>
	 <a0620071dbe03213727d5@192.168.2.93>

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 <Joe@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