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 (athena.apache.org: domain of xtian@stonescape.net
 designates 70.91.84.41 as permitted sender)
From: Christian Stone <xtian@stonescape.net>
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: multipart/alternative; boundary=Apple-Mail-17-979564178
Subject: Re: The future of sitemesh integration with struts 2...
Date: Fri, 23 Oct 2009 11:35:54 -0400
In-Reply-To: <310BF252-B144-47C1-ACA8-73A256E014E8@pontarelli.com>
To: "Struts Developers List" <dev@struts.apache.org>
References: <d8bdeb6f0910201606v7793d760x22b3ed9fb149ba3d@mail.gmail.com>
 <475B9A42-800F-4F99-914D-97924817F5CC@stonescape.net>
 <4ADF3014.9010709@newfield.org>
 <755E2D55-5C70-4059-8BC0-89AD4FE19B8E@stonescape.net>
 <4AE07E28.2000500@newfield.org>
 <3B39A774-6F59-4591-BA66-987E9AFEF73C@stonescape.net>
 <d8bdeb6f0910221208j10580414v69c1a6c1a83d07f2@mail.gmail.com>
 <2262D824-2B48-44FF-A593-E0FA4CD342A7@stonescape.net>
 <d8bdeb6f0910221300x48d2a170o64c0a9223da8f1ab@mail.gmail.com>
 <49B4A6A0-4326-450E-9993-7B567D660B56@stonescape.net>
 <310BF252-B144-47C1-ACA8-73A256E014E8@pontarelli.com>
Message-Id: <5AD06465-DDF4-430D-ACF7-E3303D4E8BBB@stonescape.net>

--Apple-Mail-17-979564178
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes

There is some time before SiteMesh 3 comes prime time, so there is  
plenty of time for thought here.  I do love the idea of wiring it up  
directly...

However, since SiteMeshFilter requires the dispatcher to handle  
requests, you would have to incorporate the SiteMesh filter directly  
into the struts filter chain, and I think this would require struts to  
absorb much of the sitemesh codebase (unless the SiteMesh developer  
were to refactor the code a whole lot more to allow it to plug in to  
other filters and not be a filter on its own).  The same thing would  
go for the dispatchers, since struts would have to insert them on the  
chain as well.  It does seem like a lot of work without a noticeable  
benefit to the users (they still have to configure a decorators file,  
etc., and which filters/dispatchers are potentially causing conflicts  
would be hidden from the user).  Additionally, they still would have  
to configure the dispatcher, at least for the request mapping, and I  
think it is less intuitive to put it into a struts config file than  
web.xml where they are used to such configurations (again, at this  
time).

With all that said, if you want to take on the task of working with  
SiteMesh 3 and making it truly pluggable and modular (such as a  
JCatapult module), that would be awesome.  Once that happens the work  
on the Struts side shouldn't be so bad (presuming the core  
architecture is in place)!  If the convention of Struts is to  
configure and deploy everything, including JSP dispatcher, etc. then I  
love the idea!

-- Christian


On Oct 23, 2009, at 11:13 AM, Brian Pontarelli wrote:

> I was never big on the Servlet or Filter models. It seems to me that  
> Struts2 is moving heavily towards conventions and the more things  
> are just "pluggable" the easier it will be for users. I feel that  
> the best approach would be for Struts2 to discover SiteMesh in the  
> class path and wire it up automatically. I'd also wonder if this  
> could be another case for some additional annotations in addition to  
> XML configuration for defining templates.
>
> Anyways, this is how I would proceed and leverage SiteMesh 3. This  
> is my plan for JCatapult.
>
> -bp
>

-- 
            _,--"
cws        `-._        ________-_______         "----
        _----'--'--------------------------------'--'----_
       //_| | \ Christian Stone, Software Engineer / | |_\\
      (_____|_|__=     xtian@stonescape.net     =__|_|_____)
      _\_____=__   http://xtian.stonescape.net/        ___/_
        \/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/


--Apple-Mail-17-979564178--