Top Level Configuration

Posted At : August 27, 2009 7:56 PM | Posted By : Brian Carr
Related Categories: Tutorials,Tidbits

If you've had a chance to view the sample application provided in the download, then you've likely noticed how lean each applications Application.cfc file is. This is definitely by design. There are however a few optional configurations that you can provide in this file in order to control how your application initializes itself. Each has a default that the framework assumes when the config variables do not exist. Below are the details on each;

Reload config option

this.quicksilver.reload

This configuration option indicates when to reload your application context. This, of course, always occurs when your app services its first request (after the CF server is started). This config option takes the following possible values;

this.quicksilver.reload = 'autodetect'; // OR
this.quicksilver.reload = true; // OR
this.quicksilver.reload = false;

"Autodetect" is the default value QS assumes when the option is explicitly left out. With this option, QS will detect any changes to your code base and then reload itself accordingly. This is a very useful feature when developing, however along with it comes a degree of overhead - so this should never be used in a production environment.

"true" (boolean value - not a string) will ensure that your application is reloaded in its entirety on every request - regardless as to whether or not anything changed. We use this when working on the framework itself to ensure changes to core files are always up to date.

"false" (boolean value - not a string) ensures that the framework is only loaded on the initial request - no subsequent ones. Will not "look" to see if your code base has changed in any way - ideal setting for a production environment.

Context Root

this.quicksilver.contextRoot

This option indicates to the framework where your application "begins", or rather, which directory off of the web root all of your domain components are located. When ommitted, your context root is assumed to be the directory within which the self-same Application.cfc is located. However if the components that comprise your software are located somewhere else, then you can provide that information in this setting. This can be especially useful if your application context root is the same as the CF app server web root. It is likely under that scenario, that your domain classes will not also be in the web root, but under a sub-directory (e.g., /com/mydomain/). Specifying an explicit contextRoot in this scenario will ensure your application will load quickly and efficiently;

this.quicksilver.contextRoot = getDirectoryFromPath(expandPath("/com/mydomain"));

Ignored Packages

QS provides another configuration option to further customize how the app gets loaded;

this.quicksilver.ignoredPackages

This allows you to provide the fully-qualified, dot-notation package names for any directories (within the web root) that SHOULD NOT be parsed as a part of the initialization process;

this.quicksilver.ignoredPackages = "com.mydomain.config,com.mydomain.views";

More thorough documentation will be an integral part of the beta release, in the meantime we will be using the riaforge QS blog to publish helpful pieces of information as often as possible. So check back frequently.

Comments (2) | del.icio.us | Linking Blogs | 2506 Views

Prefer Tags?

Posted At : August 26, 2009 3:06 PM | Posted By : Brian Carr
Related Categories: Tidbits

The advent of the CF 9 beta brought with it a much more refined and (in my humble opinion) useful version of cfscript - a very, very welcome addition. As such, most of the samples that you see as part of the Quicksilver download have been developed in the latest version of cfscript. However, those of you who prefer tags - never fear, you can write a Quicksilver supported application using CF tags as well.

Annotations however, are implemented a bit differently between the two "styles" of the CF API. As Quicksilver is an annotation-driven framework, you'll need to know the differences if you're to create an application with component / function tags. You can see in the screenshots and associated sample apps included in the downloads, annotations implemented in cfscript are done via comments prefixed with the '@' symbol (immediately preceding the entity being annotated). Annotations for tags, take on the form of custom attributes. For example;

Script Annotations

/**
* @url /user/{id}
* @httpMethod GET
*/
public User function getUser(required numeric id) {
...
}

Tag Annotations

<cffunction name="getUser" access="public" returntype="User" url="/user/{id}" httpMethod="GET">
<cfargument name="id" type="numeric" required="true" />
...
</cffunction>

The 'url' and 'httpMethod' attributes in this example, that are defined at the tag-level are effectively ignored by CF with the exception of making the information available as a part of the functions meta-data - information about the function that does not affect it's behavior. The same is true when annotations are defined at the component level;

<cfcomponent singleton="true">
...
</cfcomponent>

I've attached a new screenshot which is a tag-based version of the WorldService component - a component containing a couple of url-mapped controller methods to more clearly illustrate this, so go ahead and check it out. I will also be updating the sample apps shortly to include a tag-based version of the Hello World sample as well.

Comments (11) | del.icio.us | Linking Blogs | 2554 Views
BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress