From dev-return-42447-apmail-struts-dev-archive=struts.apache.org@struts.apache.org Mon Jan 02 01:57:00 2006 Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 22197 invoked from network); 2 Jan 2006 01:56:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Jan 2006 01:56:59 -0000 Received: (qmail 13931 invoked by uid 500); 2 Jan 2006 01:56:47 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 13914 invoked by uid 500); 2 Jan 2006 01:56:47 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 13903 invoked by uid 99); 2 Jan 2006 01:56:47 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Jan 2006 17:56:47 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates 64.233.184.203 as permitted sender) Received: from [64.233.184.203] (HELO wproxy.gmail.com) (64.233.184.203) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Jan 2006 17:56:46 -0800 Received: by wproxy.gmail.com with SMTP id i3so80557wra for ; Sun, 01 Jan 2006 17:56:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references; b=CvrZq7fHpjCLm+M7jDqRIk2e1czn1cTpenxwFBux88aY/TFDgg6kHjvfB7fc0eayI9FdPAp/OlWY1eq5Iuu2wcPdLPcSCDyWZDKlkSShMyPp8kOOMEWAm3Qjf/BJr+CI1bPZlw3pt7lZA3106QCr4kQNJn/z1lXsww6MA/nnnoc= Received: by 10.64.151.12 with SMTP id y12mr96547qbd; Sun, 01 Jan 2006 17:56:25 -0800 (PST) Received: by 10.65.15.17 with HTTP; Sun, 1 Jan 2006 17:56:25 -0800 (PST) Message-ID: Date: Sun, 1 Jan 2006 17:56:25 -0800 From: Craig McClanahan Sender: craigmcc@gmail.com To: Struts Developers List Subject: Re: [shale] Overall requirements for "remoting" feature In-Reply-To: <2387fbc50601011644t7c2d1df9rf1ae4a6bcc5aa804@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6113_23737505.1136166985392" References: <2387fbc50601011644t7c2d1df9rf1ae4a6bcc5aa804@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_6113_23737505.1136166985392 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 1/1/06, Sean Schofield wrote: > > > * (Optional) alternative dynamic execution mapping to execute a Commons > > Chain command > > (essentially equivalent to the current functionality, and/or a tie-in > to > > Struts Action Framework 1.3.x > > type processing logic). > > David has some good points about Chain being a bit of overkill. I > didn't have much problem with it but then again I'm pretty familiar > with Shale and Chain. And when you think about it, he's right. A lot > of situations don't really call for a complex chain. > > Having the *option* to call a chain sounds interesting. Can you give > an example of the URL and the naming conventions here? My general thinking (it's almost done getting coded up) is that a new JSF PhaseListener would gain control at After Restore View (i.e. when the view id has been set into the UIViewRoot component, but it's recognized that there is no state to restore). Assume we've got FacesServlet mapped to "*.faces" as usual. Next, the phase listener would apply another level of mapping (either prefix or suffix) to pick a "processor" that will take responsibility for producing all of the output for this response (if no processor is selected, the request is handled as usual by JSF). Now, assum= e we have mappings like this for some sample processors: * "/chain/*" maps to a processor that treats the remainder of the URL as the name of a Commons command or chain. It sets up a ShaleWebContext and executes the command, like the current remote support does. Amusingly, I'll bet the URLs would be identical to today's version if this were mapped to "*.remote" instead of "/chain/*". * "/execute/*" maps to a processor that treats the remainder of the URL as a method binding (after doing the syntax transformation described below). This is the easier-to-use thing David is asking for. * "/webapp/*" maps to a processor that treats the remainder of the URL as a path to a class loader resource accessed via the webapp class loader (i.e. from WEB-INF/classes or a jar in WEB-INF/lib. Of course, the scheme should be extensible, and the mappings flexible ... although we'll probably want to apply a bit of "convention over configuration" and supply some default mappings if the developer does not. Given the default mappings above, then, the following URLs would get handle= d as follows: * http://localhost:8080/myapp/index.faces Normal JSF handling (no processor mapping matches this) * http://localhost:8080/myapp/chain/list/stateNames.faces Execute the "/list/stateNames" chain from the Use Cases example * http://localhost:8080/myapp/execute/foo/bar.faces Form a method binding expression "#{foo.bar} and execute it, (optionally) loading a managed bean and then executing a method. The method can call FacesContext.getCurrentInstance() because this really is a JSF request, do value binding evaluation, and use whatever mechanism it wants to produce the output (including the usual JSF ResponseWriter that renderers use). * http://localhost:8080/myapp/webapp/org/apache/shale/usecases/view/Bundle.pr= operties.faces Return static resource org/apache/shale/usecases/view/Bundle.properties (which happens to be in WEB-INF/classes of the use cases example app). The same processor could easily extract static resources from a jar file in WEB-INF/lib, perfect for cases like a JSF component that wanted to provide a stylesheet or JavaScript resource without making the developer independently extract and package that resource under the document root. The key ingredient is that the request match the FacesServlet mapping (so that the JSF lifecycle gets invoked, and therefore our phase listener is involved), *and* that the calculated view identifier is then mapped again t= o potential processor modules that will interrupt the normal lifecycle and take responsibility for the output. If no processor is found, it's handled as usual. Craig [snip] > > > * For a context relative URL of the form "/execute/foo/bar", execute th= e > > bar() method on the managed > > bean named "foo". This method will take total responsibility for > > producing the output, so it can do > > whatever it needs. > > I like it. This would be very handy indeed. > > > Craig > > Sean > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > ------=_Part_6113_23737505.1136166985392--