Loading Page option in Bootstrapper

[peterfarrell]

This ticket is a planning document to investigate the possibility of adding a "loading page" directive to the Mach-II bootstrapper. This would only be available on CFML engines that have threading available. However, it would work in a manner that the onApplicationStart() method in the Application.cfc would spawn a thread to load the framework, set the thread id in the application scope and then forward the request to the a developer defined "loading page" (which is not Mach-II based). Future requests would check an application variable such as application.loaded and the status of the thread to see if the "loading page" show be used.

The only problem is figuring out how to show errors to developers if something during the loading of the framework has gone wrong. We might have to ship with a simple load utility that is password protected that can get the exception if the application fails to load from the spawn thread scope.

I believe this would help give immediate response to users if an application is currently being loaded or reloaded and definitely eliminate the problem of threads stacking up waiting for the framework to load up.

I have added Brian Klaas to the ticket because he expressed interest helping to develop this potential feature. Let's discuss the idea here on this ticket. Are there any thoughts on implementation or potential problems with this idea?

[bklaas@…]

Could we use available logging mechanisms (if any are turned on in the config) or even allow for a simple email address parameter to be passed for delivery of the exception if the application fails to load from the spawn thread scope? This may be simpler than building a new password-protected utility.

[peterfarrell]

Well, the bootstrapper is the "program" that loads up Mach-II. Unfortunately, Mach-II isn't loaded yet and if the loading caused an exception there wouldn't be Mach-II logging yet. In general, the MachII.mach-ii CFC is a bootstrapping "program" (think of booting a computer here). So this ticket is basically investigating the possibility of "improving" the bootstrapper and I think we'd have to build in simple logging / exception handling.

I was thinking of a couple of ways of accomplishing this enhancement idea. Maybe we need to come up with some specs, so I'm going to offer a few:

Purpose: Provide a "loading page" while the framework loads

• Developer defined non-Mach-II .cfm "loading page" by providing a path.
• Loads the framework in a thread while serving the "loading page" by intercepting all requests until the framework is ready. This page would be served with a HTML meta refresh tag in the head so it will retry the request ever X seconds and served with a HTTP status code of 500.
• Password protected utility page to load/reload the framework from the boostrapper. This page would be outside of the context of the framework. This page would also show the exception if the framework load failed.

Thoughts?

[bklaas@…]

A developer-defined loading page with the framework loading in a thread in the background would be ideal. This way, designers can create a page for users that meets their branding and design requirements while developers can rest easier about requests not erroring out while the framework loads.

The external page for realoading and seeing if the framework load failed would be helpful, but could that be handled by the dashboard? (It may give developers more reason to use the dashboard.)

As you're moving a bit more towards convention (ie; view loaders by convention), should a "default" page name be defined so that if nothing else is defined in the mach-ii.xml configuration file, a default loading page is used? This could then be used as an example (or left alone if people want the most non-designed, bare-bones page possible) or a building block for a custom "framework loading..." page.

[peterfarrell]

Great thoughts Brian. I concur on that a user-defined loading page (although I think we should ship with a generic default .cfm page for people that don't want to customize). Since the framework hasn't been loaded yet -- the "loading" page can't be a Mach-II event handler. So a simple .cfm page is about what we can offer.

There is a catch-22 here -- if the loading of the framework fails when the application has never been loaded -- the dashboard isn't available because it is a module of your current application and thus isn't loaded yet. Maybe the dashboard can ship with a simple .cfm page that is password protected that would show the caught error?

Does all of this sound reasonable?

[bklaas@…]

Gotcha on the dashboard. A password-protected page would be a viable and useful alternative so that if something does go wrong, developers can see what and where.

One tangential but related thought: wasn't there talk at some point of a dev/staging/production property being introduced as a standard part of the framework? If the property is set to dev or staging, you could bypass the need for a password-protected page and just output the error if one occurs during framework load. It'd be a small convenience, so maybe not worth the effort (if I didn't totally make up that property...).

[peterfarrell]

Re-targeted to a new milestone.

[peterfarrell]

Re-targeted to a new milestone.

[peterfarrell]

Just retargeted for 1.9 since the team doesn't have enough time to implement without additional contributors for the 1.8 timeline.

[peterfarrell]

Re-targeted for the Integrity Milestone 1

[peterfarrell]

(In [2067]) refs #195

[peterfarrell]

(In [2081]) refs #195

[peterfarrell]

Checked in is a simple loading page. The first request will wait, however any other subsequent requests (from the same client or other clients) will trigger the loading page.

You can turn this option on using:

<cfset MACHII_HANDLE_ONLOAD = true />
<!--- Optionally to point to another complete .cfm page --->
<cfset MACHII_ONLOAD_TEMPLATE = "/MachII/bootstrapper/defaultLoadingTemplate.cfm" />

The template must be a complete HTML document.