I need some code to be executed before any Umbraco page is rendered. Let me explain the whole scenario:
Created a YES/NO Base property called "Generate Static HTML" - all Nodes in the content tree has this property
Hooked up to the Document.BeforePublish event to check if the Node being published has "Generate Static HTML" = YES. If it does, I create static HTML versions of these Nodes (using this module)
Now I need some code to be triggered BEFORE a Node is rendered into browser. This code will check if "Generate Static HTML" = YES and if it is, the Static HTML is to be pushed to browser instead of the normal page process
I've checked all events here, but none seens to match what I want to achieve.
I've also tried Global.asax, attaching to the Application_BeginRequest event, but at that point Node.GetCurrent(); doesn't bring anything yet.
I found a "very bad" workaround for this: creating a macro that is included in every single DocType. This macro will check if "Generate Static HTML"=YES and if it is, the static HTML file is pushed to the browser instead of processing the umbraco page.
This is not the ideal solution because:
The macro must be include in every single DocTypes - I'd prefer a generic solution that can automatically attach to every DocTypes (present and future).
Since the goal is to load the page faster, I'm not sure how much of the page parsing already toke place when my code is reached. Perhaps another method is preferable instead of this?
Checking a node to see if it's look at teh value of property is going to take some performance anyways, I'm not sure the way you are approaching this is the best to be honest.
What the reasons that some pages are supposed to be 'Static' and some are not, can you achieve this via directory path / doctype? Then you could push out HTML on publish and serve this up instead.
Some pages has dynamic content on it (retrieved from webservices), so every time the page loads it rendes differently. This is why we need some pages to be "cached" as static HTMLs and some to continue passing thru Umbraco's normal rendering process.
I'm not sure what you mean by "achieving this via directory path/doctype", could you please elaborate?
There are no rules for the webserviced pages, that's the reason why I choosed to have the "Generate Static HTML property".
I'm reluctant on using Umbraco's cache because all page uses XSLT instead of compiled .NET code, I'm not sure if these files are cached or not, and how good this cache is for XSLT. I went for this static HTML solution because I know it will work at the speed my client needs.
Please let me know if my assumptions are not correct.
I think you may want to understand what Umbraco has to offer in the way of caching first.
To start with the content in Umbraco is 'cached' in memory on the server, this is access either by XSLT / Razor or .NET code and is fast as it's reading from memory.
On top of this, yes, XSLT can be cached, any macro can, it's fast.
Unless you have a high traffic site or have specific issues with speed it sounds like it's being over complicated to me.
I'm marking this thread as solved as I go and investigate your clues. Thanks a lot for you considerations Rich! I'll let you know if anything that poses as a blocker appears.
Umbraco's Before "Any" Page Load Event?
Hello all,
I need some code to be executed before any Umbraco page is rendered. Let me explain the whole scenario:
I found a "very bad" workaround for this: creating a macro that is included in every single DocType. This macro will check if "Generate Static HTML"=YES and if it is, the static HTML file is pushed to the browser instead of processing the umbraco page.
This is not the ideal solution because:
Hey Rodrigo,
Checking a node to see if it's look at teh value of property is going to take some performance anyways, I'm not sure the way you are approaching this is the best to be honest.
What the reasons that some pages are supposed to be 'Static' and some are not, can you achieve this via directory path / doctype? Then you could push out HTML on publish and serve this up instead.
Rich
Hello Richard, thanks for your response!
Some pages has dynamic content on it (retrieved from webservices), so every time the page loads it rendes differently. This is why we need some pages to be "cached" as static HTMLs and some to continue passing thru Umbraco's normal rendering process.
I'm not sure what you mean by "achieving this via directory path/doctype", could you please elaborate?
Hey Rodrigo,
What I meant was, maybe you had a certain section where your pages are retrieving data from webservices, for example /news/ or /stocksandshares/
Basically can does it follow any rules?
What's wrong with using Umbracos caching for the non webservices page?
Rich
Hey Rich,
There are no rules for the webserviced pages, that's the reason why I choosed to have the "Generate Static HTML property".
I'm reluctant on using Umbraco's cache because all page uses XSLT instead of compiled .NET code, I'm not sure if these files are cached or not, and how good this cache is for XSLT. I went for this static HTML solution because I know it will work at the speed my client needs.
Please let me know if my assumptions are not correct.
Thanks,
Rodrigo
Hi Rodrigo,
I think you may want to understand what Umbraco has to offer in the way of caching first.
To start with the content in Umbraco is 'cached' in memory on the server, this is access either by XSLT / Razor or .NET code and is fast as it's reading from memory.
On top of this, yes, XSLT can be cached, any macro can, it's fast.
Unless you have a high traffic site or have specific issues with speed it sounds like it's being over complicated to me.
Rich
I'm marking this thread as solved as I go and investigate your clues.
Thanks a lot for you considerations Rich! I'll let you know if anything that poses as a blocker appears.
Regards,
Rodrigo
Hey Rodrigo,
Good luck, let us know how you get on.
Rich
Just for everybody to know, I've achieved the cache I wanted by using this very good plugin:
http://our.umbraco.org/projects/developer-tools/outputcaching-4-umbraco
This is highly configurable and works exactly the way I neede!
is working on a reply...