Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 37176 invoked from network); 23 Apr 2006 22:35:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 Apr 2006 22:35:41 -0000 Received: (qmail 44277 invoked by uid 500); 23 Apr 2006 22:35:39 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 44260 invoked by uid 500); 23 Apr 2006 22:35:38 -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 44249 invoked by uid 99); 23 Apr 2006 22:35:38 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Apr 2006 15:35:38 -0700 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.162.201 as permitted sender) Received: from [64.233.162.201] (HELO nz-out-0102.google.com) (64.233.162.201) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Apr 2006 15:35:38 -0700 Received: by nz-out-0102.google.com with SMTP id o37so861170nzf for ; Sun, 23 Apr 2006 15:35:15 -0700 (PDT) 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=OeCyrOFCpnGO/MR9ynrM39iqgKLeC+Xrlulj+YdZTMmImeAjTL5oT+M8Bt53UVougCt6qu+Vhg847qWJJKJaHixlOdjgEXxjZ8ArVsnVHG+1PAQ+j2UgkUZe/cHVvyHmg6q4IOT3zLta5Xahe5C7UOPzjk1r+QgnKnYE4xsYI+0= Received: by 10.65.35.15 with SMTP id n15mr1534256qbj; Sun, 23 Apr 2006 15:35:15 -0700 (PDT) Received: by 10.64.178.18 with HTTP; Sun, 23 Apr 2006 15:35:15 -0700 (PDT) Message-ID: Date: Sun, 23 Apr 2006 15:35:15 -0700 From: "Craig McClanahan" Sender: craigmcc@gmail.com To: "Struts Developers List" Subject: Re: Standalone Tiles as TLP In-Reply-To: <16d6c6200604231129vd019e5dl9f803dd41d754157@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13531_789698.1145831715371" References: <8b3ce3790604210556g3faef4c6gc7c16f8848389696@mail.gmail.com> <281617D0-7F63-4370-8114-9869F1430DAD@apache.org> <16d6c6200604221137r251441fchd079e0ff836454b5@mail.gmail.com> <8b3ce3790604230943i528f206dr1a3c1e3e7181a5a4@mail.gmail.com> <444BBF8A.20703@twdata.org> <444BC481.8020808@twdata.org> <16d6c6200604231129vd019e5dl9f803dd41d754157@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_13531_789698.1145831715371 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 4/23/06, Martin Cooper wrote: > > On 4/23/06, Don Brown wrote: > > > > I would think it would be Tiles' responsibility to support deployment > > with Struts. In that view, Tiles would be its own project, yet part of > > it would depend on struts-action.jar to provide the Struts hooks. In > > the same way, they would provide Struts Action 2 hooks, if necessary. > > > This is a tough one - for me, at least. Should an independent Tiles have > glue code for Struts, or should it be Struts' responsibility to provide > the > glue? If we look at Velocity, the glue is over there, but we've also > talked > about it coming here. If we look at Validator, the glue is here. If we > look > at Chain, the servlet and portlet glue is over there. I've always thought it would be as Martin describes for Validator -- standalone Tiles would really be standalone, and each framework that wanted to utilize it would provide it's own glue to some particular version(s) of Standalone Tiles. That is what Shale already does with the standalone Tile= s stuff -- for example, Shale integrates tiles into the standard JSF navigation mechanism. That's not something that it seems reasonable to impose on a "standalone" project. My preference, at least at this time, would be for the Struts / Tiles glue > to stay here. That will help Standalone Tiles stand on its own feet, and > especially help with the notion that it's now independent of Struts. Any > perception - real or otherwise - that Tiles is tied to Struts will be > detrimental to Tiles as an independent library. +1 -- > Martin Cooper Craig ------=_Part_13531_789698.1145831715371--