Symphony.

I noticed that I a lot of people on this board use utilities such as...

• get-articles.xsl
• get-comments.xsl
• get-images.xsl
• get-messages.xsl
• and so on

... which in my current project led to a dozen or so of different utilities that I have to juggle with.

While this approach seems very neat and tidy, I find it a bit confusing too. I feel that it slows down my development cycle slightly because in each of my pages I have to import a different set of utilities. This in turn leads to a slight increase in errors that I get during development.

So why not merge all get-utilities in a single utility called... hmmmm... get-contents.xsl? Or will this yield any problems such as speed issues?

Just curious what you guys think...

I use a master xsl page and call all the utilities from there. It happens just once then and I don't have to worry whether I included the utility, I can just call it.

I'm using get utilities as well. I find them very handy. I'm simply importing them wherever they're needed: master.xsl, page template, other utilities.

@Tintin81

While this approach seems very neat and tidy, I find it a bit confusing too. I feel that it slows down my development cycle slightly because in each of my pages I have to import a different set of utilities. This in turn leads to a slight increase in errors that I get during development.

I'm past the point where I forget to change from import href="get-articles.xsl" to import href="get-messages.xsl" in the messages.xsl. I really appreciate the neat and tidy workflow instead of writting all matched templates in each page's .xsl file.

The 1 or 2 errors I get from forgetting to properly import templates really pay off when I'm returning to inspect some code written months ago.

We no longer use or recommend the the concept of get-object utilities for a long while now. I know that the default ensemble still does this but the utilities used in the ensemble haven't changed for several years and it is due for an update.

The original idea behind get-object utilities came from object-oriented programming. The initial idea was to borrow the convention from OOP as a way to establish a standard practise in XSLT. However in OOP, get and set methods were bred from the fact that object data were encapsulated and had to use accessor methods to handle objects.

This concept doesn't apply to XSLT. Instead, I'd recommend structuring utilities based on data semantics. XSLT is a rule based language, and as such, it's ideal when it comes to dealing with different content types. For example, templates that calculates, output or transform twitter feeds should be grouped in a utility. Similarly, code that operate on dates should be in its own utility file.

I'm with Allen — I've never used utilities named get-something.xsl, it never seemed right to me. "Utilities" to me (those that live in /workspace/utilities) are considered "helpers" — those that are found in the XSLT Utilities section of this website. These utilities are re-usable functions that are not site-specific, such as pagination, date formatting, string manipulation, ninja HTML manipulation and so on.

I then create a /workspace/sections directory and put site-specific XSL templates in there, usually matching the names of the areas of my site (blog.xsl, news.xsl, comments.xsl). The contents of these files, as Allen says, strongly follows the semantics of my data source XML i.e. a series of template matches. Why? To keep page XSLT very light.

Imagine you have user login and commenting on many areas of your site. Instead of copying the templates that create login forms, comment forms, and rendering comments into each page that supports commenting, I put my comment templates into /workspace/sections/comments.xsl and any user/login related things (such as displaying a user's mini profile beside a comment) into /workspace/sections/users.xsl. This encourages re-use across the site, and enforces a difference between the concept of utilities/helpers and content templates.

Ok, I see it more clearly now.

It is probably the Symphony default installation that set me on the wrong track. As Nick points out it really seems more reasonable to create a sections folder and put the XSL templates in there. So I guess this is what I'm going to do from now on... :-D