Return-Path: Delivered-To: apmail-struts-user-archive@www.apache.org Received: (qmail 35020 invoked from network); 26 Oct 2006 06:30:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Oct 2006 06:30:03 -0000 Received: (qmail 56595 invoked by uid 500); 25 Oct 2006 22:20:45 -0000 Delivered-To: apmail-struts-user-archive@struts.apache.org Received: (qmail 56581 invoked by uid 500); 25 Oct 2006 22:20:45 -0000 Mailing-List: contact user-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list user@struts.apache.org Received: (qmail 56567 invoked by uid 99); 25 Oct 2006 22:20:45 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Oct 2006 15:20:45 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of jak-struts-user@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Oct 2006 15:20:32 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Gcr6P-0005n4-VE for user@struts.apache.org; Thu, 26 Oct 2006 00:20:02 +0200 Received: from bas19-toronto12-1177963898.dsl.bell.ca ([70.54.77.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Oct 2006 00:20:01 +0200 Received: from laurie by bas19-toronto12-1177963898.dsl.bell.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Oct 2006 00:20:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: user@struts.apache.org From: Laurie Harper Subject: Re: Too many moving parts in Tiles Date: Wed, 25 Oct 2006 18:04:03 -0400 Lines: 160 Message-ID: References: <42db7f0a0610241020v46c66cbdnbc51bb94dd0a5af5@mail.gmail.com> <0D7B2E10-4FCA-4D24-A09F-48D0F8A461CE@apache.org> <42db7f0a0610241310y417f3141nb1ea772eb818002f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: bas19-toronto12-1177963898.dsl.bell.ca User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) In-Reply-To: <42db7f0a0610241310y417f3141nb1ea772eb818002f@mail.gmail.com> Sender: news X-Virus-Checked: Checked by ClamAV on apache.org Chris Pratt wrote: > Hmmm, I'm not using Tiles alone or Struts 2. I'm using the Tiles > integrated > into Struts 1.2.9. I've tried using the ForwardAction to forward something > like: > > > > But it doesn't work, it just returns 404's. You probably want something like As far as 2 definitions per page, I've been told by others on the list that > because you can only define variables at the first level (or something like > that) that you have to separate the layout from the definition into two > definitions. It seems very kludgy to me, which is why I'm asking here. I > agree that the ability to nest and extend Tiles is an excellent idea, > but if > this is the "best practice" approach, it leaves a lot to be desired. > > I've tried implementing it the way I'd like it to work, and with help from > people on the list, this was the only way I could get it to work, so my > wishes are a bit moot at this point. > > I'm just trying to get a handle on this "simplifying" technology and make > sure I'm not making things harder than they should be. If anyone can point > to a simpler solution (using Tiles and Struts, please refrain from > suggesting "switch to a completely different package"), I'd be very > grateful. > (*Chris*) > > On 10/24/06, Greg Reddin wrote: >> >> >> On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote: >> >> > First I have to create >> > an essentially empty file for each page that uses Tiles, something >> > like: >> > >> > <%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles- >> > el"%> >> > >> >> First off, I'm assuming you're using Tiles 2? That may affect the >> way we answer the rest of your questions. >> >> This is a drawback to using Tiles in standalone mode. Tiles is meant >> to be inserted into the view layer of an MVC application. It is >> meant to interface with the controller component of an MVC >> framework. So, if you're using Struts or JSF, you'd configure your >> controller layer to forward requests to Tiles. Instead of a 2-line >> JSP page along with a Tile definition and associated pages for every >> "page" you'd have 2 lines of configuration in your controller layer >> along with the Tiles components for every page. But in standalone >> mode you don't have a front controller so your intermediate JSP page >> becomes the front controller. In my current project I'm using >> Facelets. I'd like to see Tiles implement a feature of Facelets in >> which the "page" calls the template. Tiles works the other way >> around. In Tiles you have to define a definition that references >> both the template and the page content. In Facelets you invoke a >> page that, in turn, pulls in a template. >> >> But Tiles is currently missing this feature. Maybe you should >> consider including a controller in your app to avoid this problem. >> Currently, there is no Struts 1.x support for Tiles 2, but there is >> Struts 2 and JSF (by way of Shale) support. Note that I haven't used >> either in an application yet. >> >> > Then since 90% of our files are separated into a blue section (with >> > breadcrumbs) at the top of the page and a white section at the >> > bottom, I >> > extended the main layout definition to add those tiles. But to >> > extend a >> > tile it apparently takes two definitions (which doesn't make any >> > sense to >> > me): >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> The above defines the frame of your template, but you don't have to >> provide 2 defs for every page do you? For example, for a "foobar" >> page you only need the following (plus the intermediate JSP page), >> correct? >> >> >> >> >> >> >> Or have I missed something? >> >> I've heard talk of nested definitions whereby maybe you could combine >> default.pane and default.layout into one, but I'm not sure if it >> works or if it would be a best practice. It might depend on who you >> ask :-) The fact that you can extend definitions is a good thing, >> IMO, but you can only take the inheritance paradigm so far before it >> breaks down when dealing with XML-based definitions. >> >> > And since our site is internationalized we have externalized text in >> > resources as well as internationalized tiles_defs_fr.xml files. It >> > seems >> > like Tiles is making flow and maintainability harder not easier. >> >> To this point, in some cases, you're probably correct. It would be >> helpful if you would think for a minute about how you might "like" it >> to work. If you can post some example defs and pages that would >> represent your ideal environment we might be able to modify Tiles to >> suit. For example: >> >> * What would be your alternative to using the intermediate JSP? >> * What would be your alternative to using 2 extension defs to build >> 90% of your pages? (I know the answer is "one" def, but what would >> it look like?) >> >> With Tiles 2, we're still in development so, pretty much anything goes. >> >> > Is there a >> > best practice document somewhere that defines how to use this >> > technology to >> > make life easier rather than just making more work? >> >> Well, the doc is in progress. This is the best we can provide right >> now: >> >> http://struts.apache.org/struts-sandbox/tiles/index.html >> >> I think we have some best practices in mind, we just haven't had a >> chance to get them into the official docs yet. >> >> Thanks, >> Greg >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org >> For additional commands, e-mail: user-help@struts.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For additional commands, e-mail: user-help@struts.apache.org