Symphony.

Just coming off my first Symphony project I now feel three inches taller, believe Symphony, XSLT, and XML are the trifecta of awesomeness, and have reduced my plaque build-up by nearly 68%.

Now starting on project #2, I'm trying to wrap my head around some different issues. This site is much more of a standard, corporate brochure-type Web site with levels of nested pages. I've been delving into setting up a more specific page structure and wonder if there isn't a better way to do this.

Given a target structure something like this -

Home
News
Development
    Strategy & Consulting
    Case Studies
        [Case Study #1]
        [Case Study #2]
        [Case Study #n]
Property Management
    Management Services
    Availabilities
    Tenant Request Form
Team
    [Guy #1 - anchor link #1 to section of 'Team' page]
    [Gal #2 - anchor link #2 to section of 'Team' page]
    [Guy #n - anchor link #n to section of 'Team' page]
Contact

how could one setup the page structure somewhat efficiently and elegantly? (For the detail loving, here's a link to the actual site being reproduced; turn of styles to quickly see the full unordered list of page navigation.)

It makes sense how you create a single page to frame the sub-entries that are shown "beneath" it (as with the blog-esque 'articles' > 'entries' setup within the default install) but how does this extend when there are sub-pages beyond the second level of entries (i.e. the 'Case Studies' secondary page with sub-level, tertiary entries below it.)

Does one have to create pages for each of these? This seems like it would not only be painfully redundant if the page structure is identical but also less than dynamic as the site grows. Hopefully I'm currently blinded to the simple way of doing this by temporary stupidity.

One other bonus questionor/ clarification - in respect to the top level pages it would be preferable to have something like the 'Contact' page url be "domain.com/contact" although I think the closest I can get is "domain.com/page/contact", right?

Thanks in advance for any help seeing the light.

Best, Clayton

I'm not entirely clear on how you intend to create the site's structure. From what I've read, you want to create all the pages in Symphony as entries, is that right?

From the look of the site, this is how I would structure it:

Home (physical page, index)
News (physical page)
Development (physical page)
    Strategy & Consulting (physical page)
    Case Studies (physical page)
        [Case Study #1] (entries in the Case study Section)
        [Case Study #2] ""
        [Case Study #n] ""
Property Management (physical page)
    Management Services (physical page)
    Availabilities (physical page)
    Tenant Request Form (physical page)
Team (physical page)
    [Guy #1 - anchor link #1 to section of 'Team' page] (entries in the Team section)
    [Gal #2 - anchor link #2 to section of 'Team' page] ""
    [Guy #n - anchor link #n to section of 'Team' page] ""
Contact (physical page)

If you also want your physical pages to be editable by your authors because the idea of your authors going to Blueprints > Pages > Development and editing content amongst code is scary and unfriendly, then create another section called Page Content. This section should have 2 fields, one for page location and a text area for the actual content.

Luckily, there is a handy extension that adds a page select field so you can pair the Page Content entry with a physical page. The other useful extension in your situation would be the Rich Text Editor for use with the text area for your page content.

So to summarise, with the above structure, you should have 11 physical pages and 3 sections (Case Study, Team and Page Content).

in respect to the top level pages it would be preferable to have something like the 'Contact' page url be "domain.com/contact" although I think the closest I can get is "domain.com/page/contact", right?

This won't be the case if Contact is a physical page in Symphony.

Thanks Allen.

I'm not entirely clear on how you intend to create the site's structure.

Why, the best way, of course ;) The approach you outlined articulates very well what I was thinking might need to be done but I was hoping there might be another way of going about it that was slightly more dynamic.

If the page content is meant to live as entries (i.e. within a 'Page Content' section) would there be a more efficient way of achieving this site structure with fewer pages that allows the navigation to grow as entries are added? (Even if the url structure had to change a bit; i.e. "domain.com/page-name/entry-name"). Similar to article entries I suppose but goofed up by the need for section / parent - child dependencies.

Thanks again for the guidance and any help.

To have the entire thing powered by a section the biggest thing to contend with is hierarchy. There's a way to do this and it is to mimic how the Blueprints -> Pages define hierarchy.

1. Create a Page Content section.
2. Add a Title input field.
3. Add a Content text area.

After you've done this, save the section then go back into your section and do the following:

1. Add a Parent Page page select box field.
2. On the select box field, type None for the static value.
3. Choose, Page Content -> Title for the dynamic value.

You now have a section that has similar characteristics to the Blueprints -> Pages page.

From this point on, it will be a matter creating 2 data sources, one to produce the content of a given page and another to list the pages based on your location to use for the navigation.

I have started making my sites pretty much the way Allen described in #5. I think that's the best as far as data structure goes. The wall I run up against is that you need to create 'physical' Page any time you create a new level in the url in order to manage the url parameters. This means each top-level content section in your site gets a Page, and any sub-page that has it's own children also gets a physical Page. This assumes a single url parameter that matches the content entry handle for the page.

In #2, Allen has alot of sub-pages as physical Pages, but I wouldn't do it that way (I'm not sure you'd need to if you do it as described in #5). While 'Case Studies' would need to be a Page, 'Strategy' could just be a content entry. The key here is that you need your navigation to not differentiate between a sub-page based on a content entry, and a sub-page that is a physical Page. Sometimes the last item in the URL path will be a content entry handle, and sometimes it will be a Page handle.

I ended up using an XML Page as an abstracted navigation data source that put all the pages of the site (whether they are entries or Pages) as nested 'page' elements. This is handy, because then I wrote my navigation XSL to work with that, so if I change the way I organize Pages/entries in future projects, I just need to get them into that nested-page XML form, and I can reuse all my navigation templates. I also threw in other handy info like display order, special display names for the link, the content entry ID, display status, and redirects (if the displayed link has to go to another url).

You can actually take a look at it here (you have to view source): generic navigation datasource

I'm not positive, but I think an added benefit is that you get access to the whole site structre, but you can cache this (since it's a dynamic DS), cutting down on queries.

Thanks a lot Allen and Andrew. These approaches are pretty close to what I was hoping for. I'll need to tinker around a bit to make sure I'm following along correctly; I don't think I'm fully up to speed on setting up the navigation savvy DS yet...

Andrew, when you mention -

The wall I run up against is that you need to create 'physical' Page any time you create a new level in the url in order to manage the url parameters.

Do you mean a page for each level of navigation, period, as in primary pages, secondary pages, tertiary pages, etc. or do you mean a page for each level of navigation within a particular section?

Okay, upon brushing up on my reading skills...

This means each top-level content section in your site gets a Page, and any sub-page that has it's own children also gets a physical Page.

it sounds like you do create a unique page at any point where there need be children present (as opposed to a single 'secondary-level' page; although this would be cool if possible and the url parameters afforded it.)

I ended up using an XML Page as an abstracted navigation data source that put all the pages of the site (whether they are entries or Pages) as nested 'page' elements.

This is just done via a DS, right? Is there anything particularly fancy one needs to do to make sure it works as planned?

you can cache this (since it's a dynamic DS), cutting down on queries

Sounds like a good tip; where do you throw this switch?

Thanks again for the tutelage ;)

Sorry for the litany of questions guys... I just realized one other monkey wrench in the ointment -

Some of the top level links are structural elements rather than real pages: i.e. when someone clicks on the primary-level link 'Development' they are taken to the Development section, but displayed the first second-level page within that section, 'Strategy & Consulting'.

Is there an elegant way to accommodate these kind of instances within the page structure system we've been discussing (i.e. some sort of faux pages or entries) and a dynamically generated navigation?

Is there an elegant way to accommodate these kind of instances within the page structure system we've been discussing (i.e. some sort of faux pages or entries) and a dynamically generated navigation?

I agree with Allen's practices because of the added benefits and flexibility. However, I sometimes take a less flexible approach by using a choose statement in a page. In your example, with the development page you could use a choose statement that checks for a sub-page parameter and display the necessary content. This content could be within the conditional statement. Likewise, you can use apply-templates along with a static XML page if you wanted to keep your page clean.

Using the choose statement as Lewis suggests works well for simple pages. But if you need specific data sources executing on specific subpages, remember that adding the DS's to the parent page will mean viewing one subpage will still execute DS's for the other sub pages.

Create another data source that provides the details for each page filtered by the title field of the page content to optimize the XML data for each subpage.

I don't follow, bauhouse. How does this allow one to apply data sources to a pseudo-subpage (which isn't actually a subpage, but is a page with a parameter appended, with an xsl:choose statement controlling the UI). Could you show a quick example?

Create a page, for example, "Development" with the following URL parameters:

sub-page/entry

Create a data source called "Page" with the "Page Content" section as the source (assuming that you have followed Allen's instructions above. For each page, filter by Title with {$current-page} as the value. Include the elements that you want to display on the page.

For sub-pages, create a data source called "Sub-Page" with the "Page Content" section as the source. For each sub-page, filter by Title with {$sub-page} as the value. Specify $sub-page as a required URL parameter. Include the elements that you want to display on the page. Attach both of the data sources to your pages. Then have something like this in your template to display the appropriate page:

<xsl:choose>
  <xsl:when test="$sub-page">
    <xsl:apply-templates select="/data/sub-page/entry"/>
  </xsl:when>
  <xsl:otherwise>
    <xsl:apply-templates select="/data/page/entry"/>
  </xsl:otherwise>
</xsl:choose>

At the most, then, you should have no more than two entries in your XML for each page, the parent page and the sub-page, as long as you don't have identical values for any of your Title fields. I haven't tested this, but it should give you the basic idea.