Railo Features Part III
Railo Administrator - Settings
Yesterday I presented a part of the architecture of Railo concerning the separation of webs. Next I will post something about the new features
invented in Railo and beeing configurable in the Web Administrator. We start with the settings section.
Regional settings
Railo offers you to set up your regional settings according to your applications requirements. You can for instance host Railo somewhere in Europe having an application that is used only in a certain area the US. Then you need to convert all the time and date values to the local time of the host server to the local time of the applications usage area. This would be done by using the DateAdd() function. But with Railo you can just set the local time of your server to any desired time zone.
After setting this value you Railo offers two functions in order to obtain the current time: now() and nowServer(). While now()
returns the current Railo time (depending on the region you chose), nowServer() returns the current time of the server itself.
Another cool feature is the definition of a time server where Railo synchronizes the server time with.
In addition to that you can define the default encoding of a page and the default locale for formatting values.
Component
When you create a new component it allways inherits a base component. By inheriting this base component your component inherits all attributes and methods defined in the base component. So if you would like to add functionality to all of your components you just have to add the functionality to the base component. By setting the default base/root component you can define which component is to be used as the ancestor for all your components.When you call a Railo Component directly via an url, then a dump template is beeing used in order to display the components contents. If you would like to change the layout of the component dump you can either change the file that is used for the dump or write your own dump template and address it here in this setting.
Now comes a tricky one. In object orientated languages encapsulation is one of the main principles. This principle declares amongst others that any variable that is declared inside a class is not accessible from outside. Means that all variables from the this scope are private, unless you declare them explicitly as public.
Coldfusion does not behave in this way. All variables in the this scope of a component are accessible from outside. So just look at the following code:
file test.cfc:
<cfcomponent>
<cfset this.name = "Roger">
<cffunction ...>
</cffunction>
</cfcomponent>
file test.cfm:
<cfset oTest = createComponent("component", "test")>
<cfdump eval="oTest">
The ouput delivers the following.
| oTest | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||
In Railo you can set the accessibility level of the variables of the this scope to private, package, public (CFML standard) and remote. By setting this level to private, Railo does not show the name attribute of the this scope in the component anymore. It's now private.
| oTest | ||||||||||||||||||||||
| ||||||||||||||||||||||
I guess the other settings are self-explanatory.
Scope
One of the main things regarding readability of code and performance improvements is the scope cascading. CFMX offers the nice features of searching variables in different scopes while accessing an unscoped variable. Just have a look at the following (I must admit, stupid) code:1: <cfset cookie.name = "Roger">
2: <cfset form.name = "Smith">
3: <cfset st = StructNew()>
4: <cfloop from="1" to="100000" index="i">
5: <cfset st[i].name = name>
6: </cfloop>
Since the variable in line 5 is not scoped and CFMX (and Railo by default) searches the scopes for a variable named name in the following order: variables -> cgi -> url -> form -> cookie, st[i].name will allways be "Smith" since the form scope which is scanned before the cookie scope contains a variable called name which value is set to Smith.
Now if in line 5 you would write:
5: <cfset st[i].name = cookie.name>
then the result would be different. Not only for readability reasons scoping variables is adviseable. If in the above example you delete line 2
2: <cfset form.name = "Smith">
...
5: <cfset st[i].name = name>
and leave line 5 as is then the difference in execution time between scoped and unscoped code is 75%. OK it's an extreme example but it should show the necessity of scoping variables.
Railo can force you to scope variables by allowing you do deactivate scope cascading. The result above would throw an error of trying to use an undefined variable called "name".
The same type of coding requirement can be achieved by disabling the search of variables in all available queries.
If you deactivate the cascade to resultset feature following code would throw an error.
<cfquery name="getCustomers" datasource="cust">
SELECT firstName, lastName FROM Customers
</cfquery>
<cfloop query="getCustomers">
<cfoutput>#firstName# #lastName#</cfoutput>
</cfloop>
If you like to cluster Railo, you need to set the session type to "J2EE" in order to use the clustering capabilities of the used application servers.
Since the rest of the settings in the scope section are similar to those of CFMX and BD, I will not address them any further.
There are no comments for this entry.
[Add Comment]