919 - 926 - 9847

So how did you get started in ColdFusion?

My journey to ColdFusion stared in 2001. I was working at getting a BA in order to escape the inability to break into the "computer" world. As part of my internship for school, I got to choose where I got the privilege of paying $300 to work for free (yay education system), and that place was EXTOL International Inc. in Pottsville, PA. My in-laws worked as AS400 developers there (still do), and it seemed like a great place to start out. At any rate, it was a "foot in the door" situation that I couldn't pass up, and just 15 minutes up the road.

I started work under Mark Dempshey, the then current product manager and webmaster, and was given the task of learning about ColdFusion and the network in general. So for 40 hours a week, which was double the requirement, I spent 9 weeks working full time (for free) learning the ropes in the computer world, as well as my 3-11 paid job. It was a challenge, but well worth it as I was able to translate that internship into a paid position.

We started out on ColdFusion 4.01 and Access (good lord, why??), and when I left in 2006 we had moved to ColdFusion MX 6.1 against MSSQL. We grew from a home grown, gnarly CMS, to the FarCry CMS. I've discovered that I have no real ambition to EVER work under the NJ/NY mind-set again (you didn't read my mind and make that webform already?? We sent it to print!! We'll send you a graphic soon). Sadly they've since moved to a hosted solution that's either ASP or PHP, but that's just the way the ball bounces sometimes. There really wasn't anywhere to go "up", so I had to leave PA in order find better prospects. Still, they kept me on for 9 months as a consultant. I miss the area, but the opportunities presented in the Triangle area should keep me covered for a good number of years to come.

Where would I be without ColdFusion? Probably as a java/php/asp developer. I personally like being a CF dev and wouldn't change it for the world.

Google brought down my house of cards

For almost three years now we've been running ColdFusion (well, really JRun) session based replication and failover on all of our hosted ColdFusion environs. Things were great! And then, we let google in the door to index our content. Things went from "great", to "why is this always down??". I spent far too much time looking at JVM settings, JRun settings, etc., but never really came up with a concrete answer as to what was happening. Ultimately, we'd see a deluge of errors about the failure of session replication in the log files and a complete breaking of failover and sometimes even the JRun -> IIS connector.

Whilst searching for the session replication errors, I came across Sean Corfields postings across various blogs that replication just does not scale well, and that it remains a broken feature. Up until a few months ago, I'd argue this to be untrue. However, it appears that replication works... if you can manage to keep the amount of crap you throw into shared memory scopes down to a minimum.

It's been 4 days since I've disabled session replication, and my servers have remained standing for an equal amount of time. We've been getting indexed by google (and others), and things are sailing along with nary a blip. Next stop, creating a guide for users that want/need session based failover that can be accomplished in code. Otherwise known as, "Help me Sean Corfield, you're my only hope!" ;).

PNG not showing using Built-in JRun webserver

My friend Michael blogged about an issue he was having with viewing PNG files when using the built-in JRun webserver. Just in case this should ever happen to you, here's the link.

It appears I didn't get the link right. It's fixed now.

Error when entering lots of text view the body tag of a FarCry content item

I forgot that I've seen this before, but I had a client trying to enter text (quite a bit, in fact) and it kept failing. After finally getting all of the information on the incident, it turns out that the following error was being generated:

ErrorContext WDDX packet parse error at line 1, column 32001.
Message WDDX packet parse error at line 1, column 32001. XML
document structures must start and end within the same entity..
StackTrace coldfusion.wddx.WddxDeserializationException: WDDX
packet parse error at line 1, column 32001. XML document
structures must start and end within the same entity

I google'd around a bit before I found the answer. We're storing the body field as a CLOB (at least, I'm pretty sure that's what it is). The default buffer size for this in the ColdFusion administrator is 32k. My text input went beyond that. Whoops. So, I made sure to check the box for CLOB (and turned on BLOB for good measure) and set the size to 128k. Problem solved, and now they can enter a very long string of text into the database. Just throwing this out there in case anyone else stumbles upon this issue.

Quick and dirty uptime monitor

Although we use FusionReactor to determine the health of our servers on our team, the environment as a whole is still monitored by another group. And they cannot access FusionReactor. Our previous method of monitoring just a URL worked fine when the servers were not clustered. Now, however, you can't really be sure what instance you're on. Therefore, we get false up/down messages for a specific instance.

What I've done is this, I've got a new monitor.cfm file such as the one below:

    System = createObject("java","java.lang.System");
JRun = createObject("java","jrunx.kernel.JRun");
<cfset this_servername = JRun.getServerName()>
    Instance: #this_servername#<br>
    Server Name: #cgi.Server_Name#<br>
<!--- Change timeout behavior if more than one instance is displayed --->
<cfif isdefined('url.all')>
    <cfset timeoutBehavior=15>
    <cfset timeoutBehavior=28>
<!--- Ensure that url.instance is defined --->
<cfparam name="url.instance" default="all">

<cfif url.instance EQ 'someinstance' or url.instance EQ 'all'>
<cfset sStatus="">
<cfhttp method="get"

        <cfcatch type="any"><cfset sStatus="bad"></cfcatch>
<b>SOMEINSTANCE 1 - status</b> <cfif sStatus EQ "bad">Down<cfelse>Up</cfif>
<cfif sStatus EQ "" OR sStatus EQ "good">

This code calls out to a file sitting within the instances built-in web server path. Since I need to leave this enabled to effectively manage the instance anyway, it's a good way to test that it's "alive". That monitor.cfm file contains:

    System = createObject("java","java.lang.System");
JRun = createObject("java","jrunx.kernel.JRun");

<cfinclude template="Duration.cfm">
<cfset uptime = duration(server.coldfusion.expiration,now())><br>
<cfoutput>#uptime.days# Day(s) #uptime.hours# Hour(s) #uptime.minutes# Minute(s)</cfoutput><br>

<cfset this_servername = JRun.getServerName()>
<cfoutput>Instance: #this_servername#</cfoutput>

This display the instance information, and uses the UDF duration call (from CFLIB) to get the uptime count for the server. This information is then used within the first monitor call to display uptime status.

Why bother? Well, I need some type of text on the page to tell the monitor (soon to be Nagios) that my instances are up. And near as I can tell, this is the only accurate way to do so. It's not pretty, I admit, but it gets the job done.

FarCry 4 formtools issues

Here's a strange one that I came across yesterday. I was working on making a new site available for some community type work (www.fouroakskidskampus.com), when I found an issue with the default FarCrycms plugin. I'll post the code, see if you can spot the error.

<!--- wiz: General Details --->
<cfproperty ftseq="1" ftfieldset="Event Overview" ftwizardStep="General Details" name="title" type="string" hint="Title of object." required="no" default="" ftLabel="Title" ftvalidation="required" />
<cfproperty ftseq="2" ftfieldset="Event Overview" ftwizardStep="General Details" name="startDate" type="date" hint="The start date of the event" required="no" default=""ftDefaultType="Evaluate" ftDefault="now()" ftType="datetime" ftDateFormatMask="dd mmm yyyy" ftTimeFormatMask="hh:mm tt" ftToggleOffDateTime="false" ftlabel="Start Date" />
<cfproperty ftseq="3" ftfieldset="Event Overview" ftwizardStep="General Details" name="endDate" type="date" hint="The end date of the event" required="no" default=""ftDefaultType="Evaluate" ftDefault="DateAdd('d', 5, now())" ftType="datetime" ftDateFormatMask="dd mmm yyyy" ftTimeFormatMask="hh:mm tt" ftToggleOffDateTime="false" ftlabel="End Date" />
<cfproperty ftseq="5" ftfieldset="Event Overview" ftwizardStep="General Details" name="displayMethod" type="string" hint="Display method to render." required="yes" default="display" fttype="webskin" ftprefix="displayPage" ftlabel="Content Template" />

The above was pulled from plugins/farcrycms/packages/types/dmEvent.cfc. It was not displaying any webskins, even though they were in the correct path. Placing new webskins in the project folder failed as well. It's only when the webskins existed in the core folders that you actually were able to see them.

<cfproperty ftseq="1" ftfieldset="General Details" ftwizardStep="General Details" name="title" type="string" hint="News title." required="no" default="" ftlabel="Title" ftvalidation="required" />
<cfproperty ftseq="2" ftfieldset="General Details" ftwizardStep="General Details" name="source" type="string" hint="source of the information contained in the content" required="no" default="" ftlabel="Source" />
<cfproperty ftseq="3" ftfieldset="General Details" ftwizardStep="General Details" name="displayMethod" type="string" hint="Display method to render." required="yes" default="display" fttype="webskin" ftprefix="displayPage" ftlabel="Content Template" />
<cfproperty ftseq="4" ftfieldset="Categorisation" ftwizardStep="General Details" name="catNews" type="string" hint="News categorisation." required="no" default="" fttype="category" ftalias="dmnews" ftlabel="News Category" />

This next was pulled from plugins/farcrycms/packages/types/dmNews.cfc. Did you see it? It's not real blatant. Alright, this is where it's at, if you notice that ftseq in dmNews does not skip a sequence. The sequence in dmEvent DOES have a gap. Odd, but that's what seemed to break it. Renaming "ftseq=5" to "ftseq=4" fixed the issue. Groovy, baby.

FarCry plugin breakdown - Part III

Let's finish this up with Part 3. We only have two things to look at yet, and that's our Rule and webskin.

The Rule

<cfcomponent displayname="Mass Mailer Rule" extends="farcry.core.packages.rules.rules" hint="Allows you to select a list for user to sign up for">
    <cfproperty ftSeq="1" ftFieldSet="List" name="intro" type="longchar" hint="Introduction HTML for list." ftLabel="Intro" ftType="longchar" />
    <cfproperty ftSeq="2" ftFieldSet="List" name="ListID" type="UUID" hint="ID of the List to be displayed" ftLabel="List" ftType="UUID" ftJoin="massMailerList" />
    <cfproperty ftseq="3" ftFieldset="List" name="displayMethod" type="string" hint="Display method to render." required="yes" default="display" fttype="webskin" ftprefix="displayList" ftTypename="massMailerList" ftlabel="Content Template" />
<cffunction name="execute" hint="Displays the text rule on the page." output="true" returntype="void" access="public">
    <cfargument name="objectID" required="Yes" type="uuid" default="">
    <cfset var stObj = getData(arguments.objectid) />
    <cfset var oList = createObject("component","farcry.plugins.massMailer.packages.types.massMailerList") />
    <cfset var stData = oList.getData(stObj.ListID) />
    <cfset var stInvoke = structNew() />    
        if (len(stobj.intro))
        stInvoke.objectID = stData.ObjectID;
        stInvoke.typename = application.types.massMailerList.typepath;
        stInvoke.method = stObj.displayMethod;

Not too complicated, and once again, formtools comes to our rescue! To get a real breadth of what can be done with rules, you really should take a look at the existing core and farcrycms rules. Some of them have much more functionality than what was required for this rule.

Basically, if you want to have something displayed on the screen, you need to make a cfproperty for it. The usual formtools ideas apply. The items I required were the ID of the list, and the name of the webskin to display it. Formtools can grab this list of webskins for you with the fttype="webskin".

The real magic is in the execute fucntion. It will create our stObj (which the webskin will use), and also invoke the webskin to be used. To be frank, I've not dug into the internals much within rules. This one will get the job done, but I don't have the greatest of knowledge of this piece of FarCry.

The webskin

The essence of the skin is to display two form fields, name and address, and submit this information as a aObjectID into the massMailerList. The nifty drag-n-drop display does this for us, so I simply "borrowed" those pieces to pull this of.

<cfsetting enablecfoutputonly="true">
<!--- @@displayname: Display Mass Mailer Signup Form --->
<!--- @@author: Matthew Williams --->
<cfif isdefined('form.FARCRYFORMSUBMITBUTTON')>

<cfimport taglib="/farcry/core/tags/formtools/" prefix="ft" >
<cfinclude template="/farcry/core/admin/includes/utilityFunctions.cfm">

<cfparam name="form.primaryObjectID" default="">
<cfparam name="form.primaryTypeName" default="">
<cfparam name="form.primaryFieldName" default="">
<cfparam name="form.primaryFormFieldName" default="">
<cfparam name="form.ftJoin" default="">
<cfparam name="form.wizardID" default="">
<cfparam name="form.LibraryType" default="array">
<cfparam name="form.ftLibraryAddNewWebskin" default="libraryAdd"><!--- Method to Add New Object --->
<cfparam name="form.ftLibraryPickWebskin" default="libraryPick"><!--- Method to Pick Existing Objects --->
<cfparam name="form.ftLibraryPickListClass" default="thumbNailsWrap">
<cfparam name="form.ftLibraryPickListStyle" default="">
<cfparam name="form.ftLibrarySelectedWebskin" default="librarySelected"><!--- Method to Pick Existing Objects --->
<cfparam name="form.ftLibrarySelectedListClass" default="thumbNailsWrap">
<cfparam name="form.ftLibrarySelectedListStyle" default="">
<cfparam name="form.ftAllowLibraryAddNew" default=""><!--- Method to Add New Object --->
<cfparam name="form.ftAllowLibraryEdit" default=""><!--- Method to Edit Object --->
<cfparam name="form.PackageType" default="types"><!--- Could be types or rules.. --->
<cfparam name="form.currentpage" default="1">

<cfif form.PackageType EQ "rules">
    <cfset PrimaryPackage = application.rules[form.primaryTypeName] />
    <cfset PrimaryPackagePath = application.rules[form.primaryTypeName].rulepath />
    <cfset PrimaryPackage = application.types[form.primaryTypeName] />
    <cfset PrimaryPackagePath = application.types[form.primaryTypeName].typepath />

<!--- TODO: dynamically determine the typename to join. --->
<cfset request.ftJoin = listFirst(form.ftJoin) />
<cfif NOT listContainsNoCase(PrimaryPackage.stProps[form.primaryFieldname].metadata.ftJoin,request.ftJoin)>
    <cfset request.ftJoin = listFirst(PrimaryPackage.stProps[form.primaryFieldname].metadata.ftJoin) />

<ft:processForm action="Attach,Attach & Add Another">    
    <ft:processFormObjects typename="#request.ftJoin#" /><!--- Returns variables.lSavedObjectIDs --->
    <cfset oPrimary = createObject("component",PrimaryPackagePath)>
    <cfset oData = createObject("component",application.types[request.ftJoin].typepath)>
    <cfloop list="#lSavedObjectIDs#" index="DataObjectID">
        <cfif len(form.wizardID)>                    
            <cfset owizard = createObject("component",application.types['dmWizard'].typepath)>
            <cfset stwizard = owizard.Read(wizardID=form.wizardID)>
            <cfif form.LibraryType EQ "UUID">
                <cfset stwizard.Data[form.PrimaryObjectID][form.PrimaryFieldname] = DataObjectID>
            <cfelse><!--- Array --->
                <cfset arrayAppend(stwizard.Data[form.PrimaryObjectID][form.PrimaryFieldname],DataObjectID)>    
                <cfset variables.tableMetadata = createobject('component','farcry.core.packages.fourq.TableMetadata').init() />
                <cfset tableMetadata.parseMetadata(md=getMetadata(oPrimary)) />        
                <cfset stFields = variables.tableMetadata.getTableDefinition() />
                <cfset o = createObject("component","farcry.core.packages.fourq.gateway.dbGateway").init(dsn=application.dsn,dbowner="")>
                <cfset aProps = o.createArrayTableData(tableName=form.PrimaryTypename & "_" & form.PrimaryFieldName,objectid=form.PrimaryObjectID,tabledef=stFields[PrimaryFieldName].Fields,aprops=stwizard.Data[PrimaryObjectID][form.PrimaryFieldname])>
                <cfset stwizard.Data[form.PrimaryObjectID][form.PrimaryFieldname] = aProps>
            <cfset stwizard = owizard.Write(ObjectID=form.wizardID,Data=stwizard.Data)>
            <cfset st = stwizard.Data[form.PrimaryObjectID]>
            <cfset stPrimary = oPrimary.getData(objectid=form.PrimaryObjectID)>
            <cfif form.LibraryType EQ "UUID">
                <cfset stPrimary[form.PrimaryFieldname] = DataObjectID>        
            <cfelse><!--- Array --->
                <cfset arrayAppend(stPrimary[form.PrimaryFieldname],DataObjectID)>                        
            <cfparam name="session.dmSec.authentication.userlogin" default="anonymous" />
            <cfset oPrimary.setData(objectID=stPrimary.ObjectID,stProperties="#stPrimary#",user="#session.dmSec.authentication.userlogin#")>

    formObj.primaryHash = stObj.objectid;
    formObj.primaryNoHash = replace(formObj.primaryHash,'-','','all');
    formObj.userObjHash = createuuid();
    formObj.userObjNoHash = replace(formObj.userObjHash,'-','','all');

<cfif isdefined('form.FARCRYFORMSUBMITBUTTON')>
    <p>Your email address has been added to the list!</p>
<form action="" method="post" id="farcryForm936443538" name="farcryForm936443538" target="" enctype="multipart/form-data" onsubmit="" class="formtool" style=""><input type="hidden" name="phpMyAdmin" value="6ffe8b831e4bded08a42997de2b6eeaa" />
    <p>Name: <input type="Text" name="#formObj.userObjHash#Title" id="#formObj.userObjHash#Title" value="" class="" style="" /></p>
    <p>Email:<input type="Text" name="#formObj.userObjHash#Email" id="#formObj.userObjHash#Email" value="" class="" style="" /></p>
    <input type="hidden" name="#formObj.userObjHash#DateAddedinclude" id="#formObj.userObjHash#DateAddedinclude" value="1">
<input type="hidden" name="#formObj.userObjHash#DateAdded" id="#formObj.userObjHash#DateAdded" value="#now()#" style="" /></p>
    <input type="hidden" name="#formObj.userObjHash#ObjectID" value="#formObj.userObjHash#">
    <input type="hidden" name="#formObj.userObjHash#Typename" value="massMailerUser">
    <input type="submit" name="FarcryFormSubmitButton" value="Attach" onclick=";$('FarcryFormSubmitButtonClickedfarcryForm936443538').value = 'Attach';;return realeasyvalidation.validate();" class="formButton " style="" />
    <input type="hidden" name="FarcryFormPrefixes" id="FarcryFormPrefixes" value="#formObj.userObjHash#" />
    <input type="hidden" name="FarcryFormSubmitButton" id="FarcryFormSubmitButton" value="" />
    <input type="hidden" name="FarcryFormSubmitButtonClickedfarcryForm936443538" id="FarcryFormSubmitButtonClickedfarcryForm936443538" value="" />
    <input type="hidden" name="FarcryFormSubmitted" id="FarcryFormSubmitted" value="farcryForm936443538" />
    <input type="hidden" name="SelectedObjectID" id="SelectedObjectIDfarcryForm936443538" value="" />
    <input type="hidden" name="PRIMARYFORMFIELDNAME" value="#formObj.primaryNoHash#aObjectIDs" />
    <input type="hidden" name="FTALLOWLIBRARYADDNEW" value="massMailerUser" />
    <input type="hidden" name="CURRENTPAGE" value="1" />
    <input type="hidden" name="FTLIBRARYPICKLISTSTYLE" value="" />
    <input type="hidden" name="FTLIBRARYSELECTEDLISTCLASS" value="arrayDetail" />
    <input type="hidden" name="FTLIBRARYADDNEWWEBSKIN" value="libraryAdd" />
    <input type="hidden" name="FTLIBRARYPICKWEBSKIN" value="libraryPick" />
    <input type="hidden" name="FTLIBRARYSELECTEDWEBSKIN" value="LibrarySelected" />
    <input type="hidden" name="PACKAGETYPE" value="types" />
    <input type="hidden" name="PRIMARYOBJECTID" value="#formObj.primaryHash#" />
    <input type="hidden" name="FTALLOWLIBRARYEDIT" value="massMailerUser" />
    <input type="hidden" name="WIZARDID" value="" />
    <input type="hidden" name="LIBRARYTYPE" value="array" />
    <input type="hidden" name="PRIMARYTYPENAME" value="massMailerList" />
    <input type="hidden" name="FTLIBRARYPICKLISTCLASS" value="thumbNailsWrap" />
    <input type="hidden" name="PRIMARYFIELDNAME" value="aObjectIDs" />
    <input type="hidden" name="FTJOIN" value="massMailerUser" />
    <input type="hidden" name="FTLIBRARYSELECTEDLISTSTYLE" value="" />
    <input type="hidden" name="librarySection" value="addnew" />
            <script type="text/javascript">
                var realeasyvalidation = new Validation('farcryForm936443538', {onSubmit:false});
<cfsetting enablecfoutputonly="false">

What we have is a call to formtools, supplied with our main object (massMailerList) and our attachment (massMailerUser). This code was wrought from within library.cfm. If you haven't already looked, it would be a great place to learn more about how the open library function works. I don't have any validation for the email field, yet. That's comming down the line.

Hopefully this makes this a little bit clearer. Or, at the very least, steers someone in the right direction.

FarCry plugin breakdown - Part II

First, an addendum. Matthew Bryant pointed out that I had forgetton wrap my objectAdmin tag within an <admin> call. This would explain why my wizzardStep and CSS formating wasn't happening correctly. The updated zip can be found at this location

Let's begin Part II by looking at the customadmin files. These files are responsible for generating the menu at the top of the FarCry administrator, and for providing the links on the left hand pane.

First up, the massMailer.xml:

<?xml version="1.0" encoding="utf-8"?>
    <section mergetype="merge" id="massMailerSection" label="Mass Mailer" labeltype="value">
        <subsection mergetype="merge" id="massMailerSubSection" label="Mass Mailer" labeltype="value">
            <menu mergeType="merge" id="massMailerMenu" label="Mass Mailer" labelType="value">
                <menuitem mergeType="merge" id="massMailer" label="Mass Mailer" link="/admin/customadmin.cfm?module=customlists/massMailer.cfm&plugin=massMailer" />
                <menuitem mergeType="merge" id="massMailerList" label="Mass Mailer List" link="/admin/customadmin.cfm?module=customlists/massMailerList.cfm&plugin=massMailer" />
                <menuitem mergeType="merge" id="massMailerUser" label="Mass Mailer User" link="/admin/customadmin.cfm?module=customlists/massMailerUser.cfm&plugin=massMailer" />

FarCry gives you the ability merge changes to the look and feel of the webtop via XML files. The above should be fairly straightforward to follow.

  • Section - Creates a new tab within the webtop
  • Subsection - Creates the subsection within the specified tab. More than one subsection may be created, and a drop down list of choices will be presented if more than one subsection exists.
  • Menu - The navigation for the subsection
  • Menuitem - Navigation links within the subsection
    • Link - The FarCry custom admin parser
    • Module - The location of your customadmin files. In this case, customadmin/massMailerxxx.cfm
    • Plugin - The name of the plugin for the module

Now, let's look at the files behind the link from above:

<cfsetting enablecfoutputonly="true">

<cfimport taglib="/farcry/core/tags/formtools" prefix="tags">
<cfimport taglib="/farcry/core/tags/admin/" prefix="admin" />

<!--- set up page header --->
<admin:header title="Mass Mailer Admin" />

    title="Mass Mailer User"
    sqlorderby="datetimelastUpdated desc" />

<admin:footer />

<cfsetting enablecfoutputonly="false">

Let's start our simplest object, the massMailerUser. We need to first import the formtools and admin tags. The <admin></admin> tags allows to setup nifty things like pagination, and also bring along page styling. The formtools tags will automagically style the inputs on our pages based on the CFCs we created before. Neat, huh?

We need a call to objectAdmin to display our main menu details. The arguments are:

  • Title - The title displayed at the top of the details page
  • Typename - Very important! This is the type we plan to display
  • Columnlist - Comma seperated list of list columns to display. This could be any column within the type specific database table. Label, action, and datetimecreated are the default
  • SortableColumns - Uh... no further explanation required
  • lFilterFields - Fields on which to allow filters (restrict results)
  • plugin - Plugin to use as a base
  • sqlorderby - Order in which records are displayed in the details page

This set of options should see us through most of what we need to get done. The massMailerList uses much the same call, just a different typename. Things get different for massMailer however.

<cfsetting enablecfoutputonly="true">

<cfimport taglib="/farcry/core/tags/formtools" prefix="tags">
<cfimport taglib="/farcry/core/tags/admin/" prefix="admin" />

<!--- set up page header --->
<admin:header title="Mass Mailer Admin" />

    title="Mass Mailer User"
    sqlorderby="datetimelastUpdated desc" />

<admin:footer />

<cfsetting enablecfoutputonly="false">

There is two things of note here. One is the array of buttons. You can override most of the default behavior of FarCry, and in this case, we need to add the "Send" email functionality. You will need to delve into objectAdmin and typeAdmin to sort out what values are expected here.

The other thing to note is our send functionality. It waits for the form to submit with our "Send" value, then calls to our plugins/massMailer/packages/types/massMailer.cfc with the objectID of the particular massMailer. If you recall from part one, there's a function within our CFC to handle this call, along with the send.cfm file.

Set up muliple instances for just one website - caveats

To expand upon this earlier post, when you map multiple instances within the same website (via virtual webs), items that use CFCHART will break. To make sure that the correct CFIDE is called when calling things like cfform, cfchart, etc. you need to make these modifications (thanks to Bruce Purcell)

  • In {cfmx-root}/lib/neo-graphing.xml
    Change /CFIDE/GraphData.cfm to /somesite/CFIDE/GraphData.cfm
  • In {cfmx-root}/wwwroot/WEB-INF/web.xml
    Change /CFIDE/GraphData.cfm to /somesite/CFIDE/GraphData.cfm

In addition, we were experiencing issues with session replication when users were moving between virtual webs within the same site. The fix for this is to place this code into a normal index.html template, and ensure that this template is called first when entering your site.

<script LANGUAGE="JavaScript">
         document.cookie = "JSESSIONID=; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/";
         document.cookie = 'CFID=; expires=Thu, 2 Aug 2001 20:47:11 UTC; path=/';
         document.cookie = 'CFTOKEN=; expires=Thu, 2 Aug 2001 20:47:11 UTC; path=/';


    <!-- <META http-equiv="refresh" content="0;URL=http://<somedomain>/<somesite>/index.cfm" /> -->
    <!-- <p>The eBusiness home page can be found at <a href="http://<somedomain>/<somesite>/index.cfm">http://<somedomain>/<somesite>/index.cfm</a></p> -->

FarCry plugin breakdown - Part I

I promised a breakdown, and so it shall be writ. This first segment is going to analyze the newly created objects. If I have wherewithal to finish tonight, we'll move along to the administrator addon.

Let's start with our objects then:

  • massMailer - This object will hold all the information about our email. Things like message body, subject, from, to, and the massMailerList objects.
  • massMailerList - This object contains the name of the list, and holds massMailerUser objects.
  • massMailerUser - This object contains the name, email address, and dateTime stamp when the object was created.

Now let's look at the code. We'll start with the massMailerUser.

<cfcomponent extends="farcry.core.packages.types.types" displayname="Mass Mailer Users" bFriendly="1" hint="Mass mailer object to hold the users" bobjectbroker="true" objectbrokermaxobjects="1000">
type properties
<cfproperty ftSeq="11" ftFieldset="User Details" ftWizzardStep="General Details" name="Title" ftLabel="Name" type="string" hint="Users Name" required="no" default="">
<cfproperty ftSeq="12" ftFieldset="User Details" ftWizzardStep="General Details" name="Email" ftLabel="Email" type="string" hint="Email Address" required="no" default="">
<cfproperty ftseq="13" ftFieldset="User Details" ftWizzardStep="General Details" name="DateAdded" type="date" hint="The date user was added" required="yes" default=""ftDefaultType="Evaluate" ftDefault="now()" ftType="datetime" ftDateFormatMask="mm dd yyyy" ftTimeFormatMask="hh:mm tt" ftToggleOffDateTime="false" ftlabel="Date Added" />

object methods

Hmm... so what does THAT mean?? Let's break this object down. Formtools will generate our object administration page for us, but it needs some help to get along.

  • ftSeq - Numeric sequence that you wish the fields to be displayed in
  • ftFieldset - Gives "groups" within a given page. Usually denoted by a horizontal line
  • ftwizardSet - Should give pagination, but it isn't working (for me) at this time
  • name - Name for the object to be created in the database
  • ftLabel - Label to displayed in the admin
  • type - Type for database creation
  • hint - Typical component hint. Although I think there's a way to give context sensitive help, I just haven't explored it yet.
  • required - No need for explanation, right?
  • other ft types - Not going to into these in detail. There are several examples in the core for working with date/time types with the supplied date/time picker.

Next up, our massMailerList object

<cfcomponent extends="farcry.core.packages.types.types" displayname="Mass Mailer List" bFriendly="1" hint="Mass mailer object to create the lists" bobjectbroker="true" objectbrokermaxobjects="1000">
type properties
<cfproperty ftSeq="11" ftFieldset="List Details" ftWizzardStep="General Details" name="Title" type="string" hint="Title of object." required="no" default="">
<cfproperty ftSeq="12" ftFieldset="List Details" ftWizzardStep="General Details" name="aObjectIDs" type="array" hint="Holds objects to be displayed at this particular node. Can be of mixed types." required="no" default="" ftLabel="Users" ftJoin="massMailerUser">

object methods


Pretty much more of the same, EXCEPT, for this little gem. Notice that my aObjectIDs is of type array. This type MUST have an ftJoin attribute applied. You would specify a component here that you would like to have data populated from. In our case it is massMailerUser. But it could easily be dmImage (default supplied image library) or dmFile (default supplied file library). Heck, it can even be a comma separated list of any of these things.

So what happens when you add this type of field? Formtools will generate a button for you to click, called open library. This will pop open a window, and you will be given a choice of various tabs. In the main view, you can drag the massMailerUser (or image, or file, or whatever) objects from the right hand pane to the left hand pane. And that's it, you're done. You've now attached objects as an array to your massMailerList object. And you didn't even have to write any code!

This leaves us with massMailer

<cfcomponent extends="farcry.core.packages.types.types" displayname="Mass Mailer" bFriendly="1" hint="Mass mailer object to send to lists created by Mass Mailer List" bobjectbroker="true" objectbrokermaxobjects="1000">
type properties
<cfproperty ftSeq="11" ftfieldset="Mailer Details" ftWizzardStep="General Details" name="Title" type="string" hint="Title of object." required="Yes" default="">
<cfproperty ftSeq="12" ftfieldset="Mailer Details" ftWizzardStep="General Details" name="aObjectIDs" type="array" hint="FarCry Groups to send email to" required="Yes" default="" ftLabel="Lists" ftJoin="massMailerList">
<cfproperty ftSeq="13" ftfieldset="Mailer Details" ftWizzardStep="General Details" name="fromEmail" type="string" hint="From email address" required="Yes" default="">
<cfproperty ftSeq="14" ftfieldset="Mailer Details" ftWizzardStep="General Details" name="replyTo" type="string" hint="Address(es) to which the recipient is directed to send replies" required="no" default="">
<cfproperty ftSeq="15" ftfieldset="Mailer Details" ftWizzardStep="General Details" name="wraptext" type="string" hint="Specifies the maximum line length, in characters of the mail text." required="no" default="">
<cfproperty ftSeq="16" ftfieldset="Mailer Details" ftWizzardStep="General Details" name="failTo" type="string" hint="Address to which mailing systems should send delivery failure notifications. Sets the mail envelope reverse path value" required="no" default="">
<cfproperty ftSeq="17" ftfieldset="Mailer Details" ftWizzardStep="General Details" name="charset" type="string" hint="Character encoding of the mail message, including the headers" required="no" default="UTF-8">

<cfproperty ftSeq="21" ftfieldset="Text Body" ftWizzardStep="Text Body" name="Body" type="longchar" hint="Main body of content, text only." required="no" default="">
<cfproperty ftSeq="31" ftfieldset="HTML Body" ftWizzardStep="HTML Body" name="htmlBody" type="longchar" hint="Main body of content, to be sent to users as HTML" ftType="richtext"
    ftImageArrayField="aObjectIDs" ftImageTypename="dmImage" ftImageField="StandardImage" required="no" default=""
    ftTemplateTypeList="dmImage,dmFile" ftTemplateWebskinPrefixList="insertHTML"

<cfproperty name="bSent" type="boolean" hint="Flag for email being sent" required="yes" default="0">

object methods

<cffunction name="send" access="public" output="true" hint="Prepares and sends email to members">
    <cfargument name="objectid" required="yes" type="UUID">
    <cfset stObjMail = createobject("component", application.types.massMailer.packagepath)>
    <cfset massObj = stObjMail.getData(objectid=arguments.objectid)>        
    <cfinclude template="send.cfm">


Again, more of the same. Except we also used a rich text for generation of our "Pretty" email body. Examples of such types exist in the core. Two things worth noting is the send function and the array of massMailerList(s). I plan to fully expound upon this in part II or III, but for now, know that it's there for us when it comes time to send out our mass mail!

Oh, and thank the heavens for FireFox's built in spell checker... it at least keeps these posts from being slightly more legible than I could manage without it.

More Entries