This is an old problem that I've dealt with for a long time but its becoming a problem when working with Umbraco.
In you use the <xsl:include /> tag to include another XSL file into one of your Macro XSL files .net caches the child XSL file. So you can make a change to the child file and it won't be picked up (ie you'll go around and around going mad as your changes don't show up). The only way to make them be "seen" by .net (ie triggering .net to recache your child file) is to touch or tickle the parent file, that forced .net to refresh the cache ont he parent and therefore the child.
Its a nasty problem so I'm documenting it here in case anyone else has the same problem. Does anyone have a simple solution though? When I'm hand coding its not so much a problem but when using Umbraco its a right pain in the ass as you have to switch XSL files using the interface which is a bit slow.
Personnally I use Visual Studio where possible for editing all my Masterpages / CSS / XSLT so it's actually easy to "touch" the parent XSLT file, if you are editing everything via the Umbraco interface, you have a couple of options:
Open a second tab in your browser so that you have both the parent and child XSLT files open at the same time
Write an extension to Umbraco so that on the save of the XSLT file it automatically touches any parent that references it or forces a refresh somehow?!
Ok so some feedback please, I've been reading a bit about extensions (are there any docs I should read about these that give more than a slither of info on how to do one, any walk throughs?)
Gist is to attach to the Template (?) "after save" event and to scan the all the XSL templates to see if they have a xsl:include or xsl:import tag in it that references the filename you just saved, if so it "touches" the file(s).
Now, here are some tricky ones:
Is touching enough or does the content need to change? Only ask as sometimes when I've added and deleted a space in one go and saved its not picked it up, I have to add the space and save or delete the space and save. Needs testing and is a easy one to do :)
How does this effect SVN? Could end up with all the templates showing up as modified when they haven't been really, not sure what that would do, again needs testing and is an easy one to do (sort of).
I'm going to write two versions, first is a simple standalone app that just watches a folder(s) for any file updates, and then does all the touching as discussed above. This means you can use it outside of Umbraco which would be cool.
Then I'll mash that one around a bit to work as an extension so that you Umbraco install is all nicely self contained.
Hows that sound guys, have I missed anything stupid?
Changing the modified date is enough to trigger the XSL cache to refresh, SVN does not consider files with differing modified dates to have been changed which is great.
As a result I've knocked up a little help prog this morning which we are using in the office today to test it out. It simply watches our template folder and tickles any XSL files which include our modified file. Very quick and impressive yet very simple. Had to add some thread safety but other than that it works a treat. Knocked up a bat file to make launching it a breeze and so far so good.
We'll test it for a day or two and if ok I'll roll it out as an Umbraco extension and release it to the wild, I'll write up how I wrote the extension too as can't seem to find much about that online.
Including XSL file changes not picked up, needs parent file "tickled" to update
This is an old problem that I've dealt with for a long time but its becoming a problem when working with Umbraco.
In you use the <xsl:include /> tag to include another XSL file into one of your Macro XSL files .net caches the child XSL file. So you can make a change to the child file and it won't be picked up (ie you'll go around and around going mad as your changes don't show up). The only way to make them be "seen" by .net (ie triggering .net to recache your child file) is to touch or tickle the parent file, that forced .net to refresh the cache ont he parent and therefore the child.
Its a nasty problem so I'm documenting it here in case anyone else has the same problem. Does anyone have a simple solution though? When I'm hand coding its not so much a problem but when using Umbraco its a right pain in the ass as you have to switch XSL files using the interface which is a bit slow.
Hi Peter,
Personnally I use Visual Studio where possible for editing all my Masterpages / CSS / XSLT so it's actually easy to "touch" the parent XSLT file, if you are editing everything via the Umbraco interface, you have a couple of options:
Cheers,
Chris
I like the sound of option 2, just need to find the time to work out how to do it :)
Cheers Chris.
Pete
Will be great if you publish this extension :-)
Ok so some feedback please, I've been reading a bit about extensions (are there any docs I should read about these that give more than a slither of info on how to do one, any walk throughs?)
Gist is to attach to the Template (?) "after save" event and to scan the all the XSL templates to see if they have a xsl:include or xsl:import tag in it that references the filename you just saved, if so it "touches" the file(s).
Now, here are some tricky ones:
I'm going to write two versions, first is a simple standalone app that just watches a folder(s) for any file updates, and then does all the touching as discussed above. This means you can use it outside of Umbraco which would be cool.
Then I'll mash that one around a bit to work as an extension so that you Umbraco install is all nicely self contained.
Hows that sound guys, have I missed anything stupid?
Another update!
Changing the modified date is enough to trigger the XSL cache to refresh, SVN does not consider files with differing modified dates to have been changed which is great.
As a result I've knocked up a little help prog this morning which we are using in the office today to test it out. It simply watches our template folder and tickles any XSL files which include our modified file. Very quick and impressive yet very simple. Had to add some thread safety but other than that it works a treat. Knocked up a bat file to make launching it a breeze and so far so good.
We'll test it for a day or two and if ok I'll roll it out as an Umbraco extension and release it to the wild, I'll write up how I wrote the extension too as can't seem to find much about that online.
Cheers
Pete
For those interested: www.offroadcode.com/xsltouch.html
Feedback welcome :)
Or even easier, try our new Umbraco package, install and forget "it just works (tm)"
our.umbraco.org/projects/xsltouch
is working on a reply...