Symphony.

@DavidOliver @davidhund allright, thanks.

Thats what i could come up with, just checking if theres better options :)

Cool. Here's a quick intro in using a specific xsl:template for a Page Title that you can, optionally, completely override on different Pages.

@Nils Sorry for the confusion on my part: I tried to explain that Symphony is flexible enough for most scenario's but that it's 'probably better' to use different Symphony Pages (with their own DS and Templates) for different views (e.g. 1 Page for List-view and 1 for Detail view). This is what @phoque is saying as well.

Yes, I understood that. But I have a different opinion about it as it seems. For me it is one of Symphony's strengths to do this with a single page, a single Data Source and a simple switch in the template. A common pattern we use is for our page templates is something like this:

<xsl:template name="content">
    <xsl:choose>

        <!-- Übersicht -->
        <xsl:when test="$name = ''">
            <h2>Mitarbeiter</h2>
            <xsl:apply-templates select="data/mitarbeiter/entry" mode="short" />
        </xsl:when>

        <!-- Personenseite -->
        <xsl:otherwise>
            <xsl:apply-templates select="data/mitarbeiter/entry[name/@handle = $name]" />
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>

This is normally the only template in our pages with the other templates residing in task focussed utilities (like media.xsl, members.xls, projects.xsl …). We normally have a master template that contains the general HTML structure that is imported in each page template and that calls the template above. So each page contains a custom content template. Data Source filtering is quite powerful to get the content you want.

We normally only use child pages if we need different URL schemes: think of an archive that can either be filtered by tags (/archive/tags/tagname) or date (/archive/year/month/day).

I don't think there is a recommended way how to make use of pages, child pages and URL parameters as long as you follow a concept that suits your workflow and your page content.

@Nils: I understand. Maybe I should not have communicated a 'preferred way' that strongly.

Still: it would be good to stress the fact that, with your setup, one would have to attach one DS with all complete entries' content. This would potentially be quite a bit of overhead, no?

When the Client Section contains many fields and its entries contain much content and your one DS would fetch all these entries (or even just many) this would mean that you would fetch all that content even when you just need the content for one client.

This is indeed a personal choice but it would be good to realize for people new to Symphony.

Still: it would be good to stress the fact that, with your setup, one would have to attach one DS with all complete entries' content. This would potentially be quite a bit of overhead, no?

No, not at all. In the case I showed above the data source is filtered by parameters and thus either returning all or just one entry. If the setup is more complicated, I'd use two different Data Sources of course. And this is still a helpful customisation to reduce load: Don't execute Data Source if a URL parameter is set.

Oh wow. I am sorry Nils: you are completely right of course… :/

Worked great with the custom template for page title :)

Should i go the same route if i want to include certain javascript files on certain pages?

Or is it better/possible to pass some "additional headers" when i include the master template and then have a placeholder for that in it?

<xsl:import href="../utilities/master_modin.xsl"/>

Yes. That's the beauty of xsl:templates - you can override them when you need them.

I often use something like:

(in master.xsl)
<!-- Global CSS (or JS) -->
<link href="my.css"/>
<xsl:call-template name="extra-css" />

This way you load my.css globally on every page, but you can have a extra-css template on certain pages adding extra CSS (or JS etc)

PS: make sure your master does, in fact, have (an empty) extra-css xsl:template ;)

Okay, so a conditional statement is the way to go?

I put the extra page-title template in /utilities, does it work to just have these things in the bottom of the master? They become a few and are only used in one place i guess...

Update: Nevermind... i thought if it's just one condition i could just run it within

Is there any way to specify a max size when loading images trough JIT?

So it only scales images down if bigger than X but leave them untouched if smaller than X?

This logic should reside in your XSL templates. Have a look at some XSL templates:

• Magical JIT Resizer
• Resize Images
• Image Formatter
• Smart Image Resize

Personally, I use an improved version of Smart Image Resize and the standard Magical JIT Resizer.

Take the templates and adjust them to your needs.

I made an own simple template... is it OK or bad?

<xsl:choose>
            <xsl:when test="image/filename != ''">
                <xsl:call-template name="get-image">
                    <xsl:with-param name="path" select="image/@path" />
                    <xsl:with-param name="filename" select="image/filename" />
                    <xsl:with-param name="alt-text" select="title" />
                    <xsl:with-param name="width" select="image/meta/@width" />
                    <xsl:with-param name="max-width" select="'500'" />  
                </xsl:call-template>
            </xsl:when>
        </xsl:choose>



<xsl:template name="get-image">
<xsl:param name="path" />
<xsl:param name="filename" />
<xsl:param name="alt-text" />
<xsl:param name="width" />
<xsl:param name="max-width" />

<p>
    <xsl:choose>
        <xsl:when test="$width &gt; $max-width">
            <img src="{$root}/image/1/{$max-width}/0{$path}/{$filename}" alt="{$alt-text}" />
        </xsl:when>
        <xsl:otherwise>
            <img alt="{$alt-text}" src="{$workspace}{$path}/{$filename}" />
        </xsl:otherwise>
    </xsl:choose>   
</p>

is it OK or bad?

For something dead simple, it should work. But ...

If you want to re-invent the wheel, feel free doing so, but others have done it before you and have done it well :)

Take their work and adapt to your needs.

You are right, one of your links made a better jobb :) Thanks