Here's what I have done in the past:

 (This describes the source code written for the hyperlink below my name.
  The source code is available by request.)

Here is what my layout looks like on a web page:

    ________________________________________________
   |                     .                          |
   |  Logo               .   Nav                    |
   |                     .                          |
   |                     .                          |
   |                     .                          |
   |------------------------------------------------|
   |                               .                |
   |  Main                         .  Modules       |
   |                               .                |
   |                               .                |
   |                               .                |
   |                               .                |
   |                               .                |
   |                               .                |
   |                               .                |
   |------------------------------------------------|
   |                     .                          |
   |  Legal              .   Powered                |
   |                     .                          |
   |                     .                          |
    ------------------------------------------------


When you consider the flow of the application.
1. All requests are handled by an action
   (this means even index.jsp is just a forward to a .do)

2. All actions forward to a "something.view"
   (these are tiles definitions)

3. All "something.view" are made up of "something.tile"


This technique provides for better naming and quicker development.  Not to
mention that once you understand the naming, when you've seen one, you've
seen them all.



----------------------
from struts-config.xml
----------------------
  <!-- === Action Mapping Definitions  ======== -->
   <action-mappings>
     <action path="/index" forward="index.view"/>
     <action path="/meetings" forward="meetings.view" />
     <action path="/sponsors" forward="sponsors.view" />

     <action path="/main-tile" forward="/WEB-INF/jsp/main.jsp" />
     <action path="/meetings-tile" forward="/WEB-INF/jsp/meetings.jsp" />
     <action path="/sponsors-tile" forward="/WEB-INF/jsp/sponsors.jsp" />



-------------------
from tiles-defs.xml
-------------------
<tiles-definitions>

   <!-- ================================  -->
   <!-- Master definition                       -->
   <!-- ================================  -->

   <!-- Doc index page description  -->
        <definition name="index.view" path="/WEB-INF/layout/classicLayout.jsp">
            <put name="logo.tile"       value="/WEB-INF/jsp/logo.jsp" />
            <put name="nav.tile"        value="/WEB-INF/jsp/nav.jsp" />
            <put name="main.tile"       value="/main-tile.do" />
            <put name="modules.tile"    value="/WEB-INF/jsp/modules.jsp" />
            <put name="legal.tile"      value="/WEB-INF/jsp/legal.jsp" />
            <put name="powered.tile"    value="/WEB-INF/jsp/powered.jsp" />
        </definition>

        <definition name="meetings.view" extends="index.view" >
                <put name="main.tile"           value="/meetings-tile.do" />
        </definition>

        <definition name="sponsors.view" extends="index.view" >
                <put name="main.tile"           value="/sponsors-tile.do" />
        </definition>



Can you see the flow here?

If someone goes to index.jsp, there is an immediate forward to /index.do
/index.do will forward to "index.view"
  which has definition from 6 "tiles"

It saves me lots of time, and I prefer using my naming
conventions (xyz.view is made up from a.tile, b.tile, and/or c.tile)


One other option I've explored is to remove all references of any jsp from
the struts-config
and use actions solely to forward to "views" and "tiles" defined in the
tiles-defs.xml.

Hope that helps you.


James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://www.open-tools.org/struts-atlanta




> -----Original Message-----
> From: Lee Crawford [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 4:29 PM
> To: 'Struts Users Mailing List'
> Subject: Decorators?
>
>
> Greetings,
>
>   A question I thought I'd run by the group here; surely someone else has
> found the appropriate approach.
>
>   The plan is to build a struts-based site that has a standard templated
> layout. I've got a standard template.jsp which is a table that imports a
> header, footer, navigation panel, and a content pane:
>
>   /------------------------\
>   |      header.jsp        |
>   +------------------------+
>   |            |           |
>   | navbar.jsp | _________ |
>   |            |           |
>   |            |           |
>   +------------------------+
>   |      footer.jsp        |
>   \-----------------------/
>
>   the header.jsp, footer.jsp, and navbar.jsp while dynamic are
> largely just
> a decorator around the actual functioning application that will go in the
> content page. The template.jsp will be passed (request parameter) the name
> of the JSP to include in the page each time it is drawn.
>
>   So, what are my architectural options here.
>
>   I experimented with forwarding all of my actions (/login.do, /logout.do,
> ...) to the same action as a dispatcher each with a property that
> describes
> the URI of what is to be included in the content area. But in the case of
> forms the RequestProcessor seems to detect that there is no form and
> forwards to the form page which them shows up without the decoration.
>
>   Is this the sort of thing that the RequestProcessor could be used to do,
> like a servlet filter, to touch up the outgoing markup? But, the decorator
> isn't completely 'static', for instance the navbar.jsp wants to
> know what's
> going in the content area so it can change it's representation.
>
>   Thoughts?
>
> --lee
>
> --
>  Lee Crawford
>  Trintech, Inc.
>  [EMAIL PROTECTED]
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to