Symphony.

I’m wondering what the rules are to submitting an XSLT Utility. With Symphony being so good at pulling in external XML, it’d be nice to have some quick utilities for integrating 3rd party services into a site.

I use this code on my site to pull in Tumblr. http://gist.github.com/107037

I’d like to add it to the XSLT Utility section once I finish it, but I’m not sure if it’s too specific.

Any thoughts? Is this worth putting in the Utility section?

Any thoughts? Is this worth putting in the Utility section?

Most definitely! It’s not too specific (in reference to working with Tumblr). As long as the utility can function independent of any of your other site XSLT, then I would consider it a great resource.

Absolutely! This is perfecto :-)

It just so happens that the existing Utilities are rather generic. But any standalone XSLT templates are worthy, for sure.

OK. I’ll finish it up, test it, and submit a final one. Thanks!

looking forward to it!

I have added it. Take a look and see if it’s worthy. If you have ideas on how to improve it, let me know.

Nice one MrBlank. I had a couple of ideas on how it can be made shorter:

http://gist.github.com/107958

I noticed there were two places where code was being repeated: writing the `meta div, and checking the content body for HTML tags. I’ve converted these to separate templates so you have to write them only once.

I’ve made all templates use mode attributes to make sure they don’t interfere with any other XML parsing. The meta template matches on the url attribute and accepts a $label parameter. The tumblr-body template matches on any XML node thereby allowing us to pass any node name to it (although this could be made more specific by replacing * with video-caption | audio-caption | link-description ...). Because the logic is identical for each, I figured it’d be best to include it only once :-)

I haven’t tested this code, mind. Just wrote it blindly!

@Nick: Great! I was thinking about breaking out the text area output where it checked for tags, but didn’t get to it. (What you have won’t quite work with classes, but it’s close.) You’re right, making the meta info into a separate template is much more efficient.

Since these utilities are probably used by people new to XSLT, I thought making them easy to understand would be better than making them the most efficient. Having a lot of apply-templates inside a utility makes things harder to understand.

But, maybe the best approach is to set a good example so new users don’t learn any bad habits.

I’ll work on a revision soon. Thanks for the input.

But, maybe the best approach is to set a good example so new users don’t learn any bad habits.

My XSL is learned from examples from Allen and the others, so that’s the direction I’d go in. That said, there are often many ways to achieve the same goal, so choose the one that’s best for your own purposes.

I updated the utility to incorporate nickdunn’s suggestions. They worked perfectly. Thanks!

Great utility! Now I don’t have to write my own! But in:

<xsl:template match="@url" mode="tumblr-meta">

I believe you have to change from:

<a href="{@url}" title="Permalink to this post on Tumblr">...

to:

<a href="{.}" title="Permalink to this post on Tumblr">...

Since you otherwise are trying to select an attribute at an attribute node match. I haven’t tried with LibXML yet, but Saxon complains about it.

I’ll check that out. Thanks!

If you get it all working, please post a link so I can see it. :-)

Good catch on that type-o. I’ve fixed it on the forum and on Gist.

Am I right in assuming that you can’t filter the XML in the ‘Included Elements’ section in the DS for Dynamic XML?

I have tried it using pretty standard Xpath and it never worked, but I wanted to double check. Reason why I want to do this is because I want to only display certain types of entries, and rather than pulling lots of data into my XML I just want to pull through what I need.

I’m going to try the XML Importer for size as it seems to be a better fit.

You ought to be able to just pull what you need straight from Tumblr.

http://www.tumblr.com/docs/en/api#api_read

The GET parameters from Tumblr’s API includes post type. You could set up a data source for each post type.

I shall investigate some more when I get home. I may just adapt the utility for my purposes as its a little too detailed for what I need.

Great resource though.

Hmm, it seems this thread has been duplicated, I replied to something in the other less populated thread.

Great utility but can I ask about the element you have used?

From what I understand from Keys is that you can create a key, have it match a pattern in the XML and reuse that key to display info based on the pattern and context.

I don’t understand the substring part of your Key.

Could you explain to me more of what your intention here is, because from what I know about the substring() function - the 6, 11 part of your code indicates start from the 6th character and take 11 characters and return them as the post-date.

Is that correct?

the substring() function - the 6, 11 part of your code indicates start from the 6th character and take 11 characters and return them as the post-date.

That’s correct. I am using the date attribute and pulling the day and month value and making a key out of it. (This assumes I always post more than number of posts I’m pulling per year, otherwise you’d have to get more specific and include the year in the substring or use the date-gmt attribute.) This allows me to group posts that are posted on the same day.

I’m not using the string as a literal date. I’m just using it as a way to group posts, if that makes sense. Tumblr has added more date formats since I wrote the XSLT, so there may be a better way to group. I also noticed that they have another content type, ‘Answers,’ that I need to add.

Well as soon as I understand fully Keys, which is only going to happen through practice, I will then be able to fully understand what your doing. :)