Hmmm, I can't get that working can anyone point me at a working example? All the examples I can find are extremely simple and don't use nested tiles. (*Chris*)
On 10/25/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
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: > > <action path="/loginPage.jsp" parameter="login.layout" type=" > org.apache.struts.actions.ForwardAction"/> > > But it doesn't work, it just returns 404's. You probably want something like <action path=".tile.name" ... where .tile.name is the name of a definition in your tiles-defs.xml. You definitely don't need the 2-line JSP when using Tiles with Struts like this. L. > 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 <[EMAIL PROTECTED]> 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"%> >> > <tiles:insert definition="login.pane"/> >> >> 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): >> > >> > <definition name="default.pane" extends="site.layout"> >> > <put name="body" value="default.layout" type="definition"/> >> > </definition> >> > >> > <definition name="default.layout" path="default-layout.jsp"> >> > <put name="bluearea" value="/tiles/blank.jsp" type="page"/> >> > <put name="whitearea" value="/tiles/blank.jsp" type="page"/> >> > <putList name="breadcrumbs"> >> > <add value="/|head.home" type="string"/> >> > </putList> >> > </definition> >> >> 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? >> >> <definition name="foobar" extends="default.layout"> >> <put name="bluearea" value="mybluearea.jsp"/> >> <put name="whitearea" value="mywhitearea.jsp"/> >> </definition> >> >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
