Symphony.

Forgive me if this has already been discussed…

I’ve been looking through the examples, focusing on the url structures that I can create, and I have a question about them…

Is it possible to create say a page under /news which would list all news articles, paginated. And then have the titles of each post as a direct child, say as /news/today-in-the-news to display the article?

From the examples I can read, I can’t see how to do it. There always seems to be an extra level. Is it possible??

Might be a very stupid question…

Yes you can. You’ll have to differentiate the two different output methods in the XSLT though.

usually i create two separate pages - one for news articles that would be paginated and then another that would filter only specific news articles. if you tack on too much filtering/functionality on one page, you will bloat your xml output and slow down your page output.

what i tend to do is have pages like /news that would have a page parameter of pg (i think page as a param is reserved for symphony) and then i would make a child page for /news like /news/article and then have a parameter of post and then filter my datasource with the {$post}. however, if your post has a really long title and there is more than one that begins with that same really long title, you will always filter the first result. i think it cuts off at 50 characters or something. so in lieu of that, i usually add in the post id and filter by both the id and post to make sure i grab the unique post, but have the post title in the url.

Yep. Create a page “News” (which will create a URL Handle of “news”) and add a URL Parameter “title”. This effectively gives you:

/news/:title

Whereby the “title” is an optional URL parameter.

You can then create a Data Source that filters your news articles on a text input field with the filter value {$title}. The clever bit is that when $title evaluates to nothing (i.e. when you’re just viewing /news/) this filter in the DS will be ignored. So if you leave your DS to limit 20 entries and sort them by date, by default you’ll get your list of news articles. But when the $title is present in your URL, the same DS will just return the one DS.

You’ll have to differentiate the two different output methods in the XSLT though.

Simple :-) In your page you’ll probably use a choose/when statement to see whether $title is set or not, and adjust your page to write a list of articles, or show a single article:

<xsl:choose>
    <xsl:when test="$title">
        <!-- show a single news article -->
    </xsl:when>
    <xsl:otherwise>
        <!-- show a list of news articles -->
    </xsl:otherwise>
</xsl:choose>

Take a look at the default workspace (the blog) that comes with a standard Symphony install; it uses this technique.

You can also use the URL Router extension to “fake” that sort of structure, i.e., passing off those request to separate pages. I haven’t got time to add an example at the moment but it’s definitely possible.

Thanks for everyones responses. It never occured to me to use xslt choose/when…

Gonna have a play…

I have a similar question in this vein. Is there an elegant way of doing a two-tier lever URL structure similar to this “news/individual-article-tiltle” example with more than one base section?

For example, instead of just a “news/” section that lists individual new articles what if you wanted to have say three sections with similar presentation/data structure like “example.com/cakes/”, “example.com/cookies/”, and “example.com/pies/” each of which would output a list of their respective items in that category that would link to individual articles with URLs like “example.com/pies/moms-apple” or “example.com/cakes/heavenly-chocolate”.

Basically, is there a way to pass on more than one filtering criteria (a sub-section, then a title) divided by slashes through a URL like the above example to a single data source/page pair, or would it be necessary to create a DS/Page combo for each of the three sub-sections? I’ve not seen a thread yet that seems to address this directly so far, so my apologies if this has been covered already. And thanks to anyone who might be able to provide any clarity.

Is there any reason you’d want all three of those to be on the same Page?

In the particular instance I’m thinking of, the template code would be basically identical other than the name of the Page, so the primary reason is to only have to edit/update 1 page as opposed to 3 separate pages if I ever wanted to change things. Just trying to reduce repeated code that would be redundant. Or am I looking at it the wrong way, or missing some other feature that could make it more efficient?

In the particular instance I’m thinking of, the template code would be basically identical

Ah, thought that might be what you were after. In that scenario it’d probably be best to create separate Pages for each of those URLs (cakes, cookies, etc) and just import a common template for the layout. This would work much the same way that so-called “utilities” work. That way you’re keeping your DS/URL logic separate and native—i.e., no modifications needed—and you get the benefit of editing a single template to make changes.

Ok, that makes sense. So to do the template importing one would just make a new utility component with the relevant template code inside and then just put a <xsl:include href="whatever.xsl"/> line inside the default Page template code for each of the section’s Pages? or is there a different method to do the importing of a common template?

That’s right, you can even leave the page_name.xsl stylesheet completely empty (i.e., no template matches) and only include the common template instead.

For the last project I had three sections, each having their own page for full view and sharing a single page for an overview-screen. Displaying the actual items should be the same in both views.

I am not sure yet if it’s good programming style but I ended up with including the detail view Page into the overview Page to make use of its templates matching the entry:

referenzen.xsl (applying templates on the entries):

<xsl:import href="../utilities/master.xsl"/>
<xsl:import href="../pages/referenzen_fortbildungen.xsl"/>
[...]
<xsl:template match="data">
    <xsl:apply-templates select="fortbildungen" />
</xsl:template>

<xsl:template match="fortbildungen">
    </ul>
        <xsl:apply-templates select="entry[position() &lt; 4]"/>
    </ul>
</xsl:template>

referenzen_fortbildungen.xsl (containing the templates for the entries):

[...]
<xsl:template match="fortbildungen">
    <h2><xsl:value-of select="section" /></h2>
    <ul>
        <xsl:apply-templates select="entry"/>
    </ul>
</xsl:template>

<xsl:template match="fortbildungen/entry">
    <li><strong><xsl:value-of select="titel"/></strong> am <xsl:value-of select="datum" /> im <xsl:value-of select="ort" /></li>
</xsl:template>
[...]

<xsl:import href="../pages/referenzen_fortbildungen.xsl"/>

I’m not convinced it’s great practice either, but on bekonscot.co.uk I do the same thing — many sub pages import their parent pages since they share functionality. This made more sense than abstracting out into a shared utility (in this example).

Heh. You guys are stirring up all my old crazy ideas about making templates technically independent of pages and then enabling all kinds of insane relationships among them like inheritance/extension and so forth. Stop it :)

Hah! Classic…