In fact the Apache Tiles Web site example ( http://struts.apache.org/1.x/struts-tiles/examples.html right above the header "Specify Attribute Types") seems to be promoting the two line file as the right way to do things? I'm very confused... Doesn't anyone use Tiles? (*Chris*)
On 10/25/06, Chris Pratt <[EMAIL PROTECTED]> wrote:
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] > >
