Page PreRender event

According to the Sitefinity documentation, the IPagePreRenderCompleteEvent is fired when a page's PreRender event has completed. In my observations, I have not been able to detect this event firing when a page is initially placed into edit mode, i.e., your.website.com/.../Edit.

The goal is to detect when a page has been placed in edit mode AND get access to the ASP.NET page itself in order to perform additional tasks, i.e., load custom Javascript in the page just before the in-context page editor loads in the browser.

What's the best approach to accomplish this task?  Is it even possible?

Couldn't you do the same by just peeking at the url in the masterpage codebehind?  Like just look for those url segments.

Steve, I completely understand where you are going with your approach, but if you wanted to create a self-installed module for Sitefinity, you would not want to require users to have to update the master page themselves.  Particularly, if your users consist of marketing staff and not developers. In this instance, it would be awesome if a page PreRender event could also fire when a page is placed into edit mode because it would give developers the opportunity to enhance or extend the in-context page editor experience/tools.

 In our case, we already use master pages to add additional custom tools to the page editor toolset, but wanted to achieve this via an event like the page PreRender event, which passes in the ASP.NET page already. 

Hello Chris,

The event might not be fired due to a different reasons - for example cache issue, thus you will not have a PreRender.

You can try to fire this event for example in a widget by using the method:

Svetoslav , thanks for the suggestion.  At this point, its clear that the IPagePreRenderCompleteEvent event is NOT fired when a page is either previewed or being edited via your.website.com/.../Preview or your.website.com/.../Edit respectively.

This is obviously not a caching issue either since completely disabling the cache via the advanced settings has no apparent effect.  In addition, it stands to reason that if you are editing a page via .../Action/Edit, the page itself would not be cached since there are tons of controls, and what not, loaded into the page for editing purposes.

Again, creating a widget that fires the event manually defeats the purpose of automatically loading or performing additional tasks server-side before the in-context page editor is loaded in the user's browser, i.e., loading custom JavaScript or jQuery libraries or frameworks.

My guess is that the IPagePreRenderCompleteEvent event is not being fired because the page is not truly being loaded into its own context, but rather, its being loaded within a different context via the in-context page editor for editing purposes.  Perhaps another similar event would suffice for this purpose. I do realize, however, that such a change wouldn't happen just because one developer wants to enhance the page editor's tools, interface, or experience.