0 users online. Create an account or sign in to join them.Users

Search

I wonder how others name these assets. Currently I'm using something like

Articles :: Articles list            <-- perhaps all or not
Articles : Title :: Articles list    <-- perhaps 5 etc
Articles : Title :: Article details
Articles : Title :: Article details : Images   <-- chained to previous one
W : Articles list     <-- this list of articles appears on at least 2 pages

Parent-page : Page : ... :: Section : Chained-section :...

but it's rather verbose, perhaps overkill ... What is your naming convention?

@kanduvisla asked

I'm not quite sure what you would be trying to achieve with a convention like that.

Better readability in XSLT:

<xsl:template match="articles-title-article-details/entry">...

Easier finding of needed DS on DSs index due to knowing on what page it resides.

But I would like to try out some other ideas ... Searching for the sweet spot :)

Nothing set in stone, but often follows something like:

Articles: List Latest (latest 5)
Articles: List Related By ID (related videos given an article ID)
Articles: List by Category (articles in a category)
Articles: By ID (a single article)

Me too, I use the colon as the seperator between category : datasource. Or no colon if no category is applicable:

News : Last 3
News : Detail
News : Archive
Articles : Last 2
Articles : Detail
Navigation

etc...

category : datasource

Do you use "category" to refer to the area on the frontend of your site or section names? I always try to use:

Section name: Filter

I'm using this for a web app that has two user areas called dockhouse and vessels:

Area: Section

Using Nick's take:

Dockhouse: Vessel Owners
Dockhouse: Vessel Owners by ID
Dockhouse: Vessels by Dockhouse ID

Vessels: Vessel Owners by ID
Vessels: Vessels by Vessel Owners ID
Vessels: Vessels

but it's rather verbose

I prefer the little additional overhead for less confusion.

Cool thread and timely too!

Read News by ID
Read News by Date
Fetch Comment ID by News ID

We/I try to use Read/Fetch to distinguish between if this Datasource is being used to get information, or just parameters.

Better readability in XSLT:

<xsl:template match="articles-title-article-details/entry">...

This is interesting, and while we don't always follow it at work, we use @modes to describe XSLT templates more than the datasource name (as changing the Datasource name as the project progresses is nearly always a nightmare). So instead of hardcoding the datasource handle, we'd do something like this:

<xsl:apply-templates match="*[section/@handle = 'articles']/entry" mode="article-details" />

I've noticed over time from random snippets across the forum that the @mode attribute is rarely used. Does anyone else use this technique?

Interesting idea, @brendo ... but what if you have article details

<xsl:apply-templates match="*[section/@handle = 'articles']/entry" mode="article-details" />

and list of articles

<xsl:apply-templates match="*[section/@handle = 'articles']/entry" mode="articles-list" />

templates? You still have to use the DS handle, I assume.

Nope that's the point of the @mode. What you've posted will work.

Like @brendo I started using modes rather than DS handles. BTW: The example is buggy, it should be select instead of match:

<xsl:apply-templates select="*[section/@handle = 'articles']/entry" mode="article-details" />

If you don't dare to do this you may use a DS handle in the "select" but still use wildcards in the matching templates:

<xsl:apply-templates select="some-datasource/entry" mode="article-details" />

<xsl:template match="*[section/@handle = 'articles']" mode="article-details">
</xsl:template>

<xsl:template match="*[section/@handle = 'articles']" mode="articles-list">
</xsl:template>

Or even:

<xsl:template match="*" mode="article-details">
</xsl:template>

<xsl:template match="*" mode="articles-list">
</xsl:template>

As @brendo said, the idea behind this is to reduce trouble when a datasource is renamed!

This is a really nice approach, thanks for sharing.

I have the same concern of @vladG though:

Nope that's the point of the @mode. What you've posted will work.

Say you have

<data>
    <articles-list>...</articles-list>
    <article-detail>...</article-detail>
</data>

How are you gonna match one instead of the other?

You'd do what @michael-e suggested:

<xsl:apply-templates select="/data/articles-list" mode="article-list" />

<xsl:apply-templates select="/data/articles-details" mode="article-details" />

<xsl:template match="*[section/@handle = 'articles']" mode="articles-list">
    I'm articles-list.
</xsl:template>

<xsl:template match="*[section/@handle = 'articles']" mode="article-details">
    I'm articles-details.
</xsl:template>

Oh right, makes sense. You're still bound to ds handles in this case but not as much as I am currently :)

These tips are awesome! I've not used @mode much but I love abstracting it a little and removing the dependancy from the DS handle.

Thanks for these tips: this particular tip might be another candidate for the "XSLT tips that will change your life!" thread?

This thread came at just the right time for me. I'm using the *[section/@handle = 'section-handle'] approach where I can with a site I'm currently structuring.

I'm also trying the data source naming convention, but with the parameter output also being signified. E.g. Category by Parent ID gives ID.

Thanks for the tips.

Brendan, if you are using distinct modes, why don't you just match on entry in your templates?

I'm using something like this recently for handling lists of entries:

<xsl:for-each select="forum-activities/entry">
    <li><xsl:call-template name="content-forum-activity-preview"/></li>
</xsl:for-each>

Allows me to reuse the same markup for differently filtered datasources (same sections).

I still use "<xsl:apply-templates..." for single-entry-datasources, though.

What if a datasource exists purely for chaining, only producing an output parameter? How would you name that?

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details