Mark Drew (Redux)- cf_etc...

A few people have asked me to post my presentations, and I should have done so anyway straight after the conferences, but of course, since I did three presentations + a Mystery Theatre at cfobjective and four presentations at Scotch on the Road I have been falling behind normal work and blog postings.

So, here for your delectation are all the presentations for you to download... (apart from the Mystery Theatre 3000 since that has a naughty picture in it)

• Atomic Reactor: or how I stopped worrying and love the ORM
• ColdSpring: Better Living through configuration
• Which Framework? ColdBox, Mach-ii and Model Glue compared
• Whats Railo 3.1 Open Source?
• Railo in the Cloud
• ModelGlue and You

I recently have been working on adding a couple of different cache providers for Model-Glue 3 .

So I was getting my head round Andrew Powell's CF_EHCache so that I can write an interface for it that Model-Glue can use, which should be simple enough since it already uses a SimpleTimedCache, when I come across a very odd thing, with the code out of the box I got the following error:

The system has attempted to use an undefined value, which usually indicates a programming error, either in your code or some system code.
   Null Pointers are another name for undefined values.

So I started dumping my way through it, so to speak, but it would work... eh?!

	<cfscript>

		var mBeanServer     = createObject('java','java.lang.management.ManagementFactory').getPlatformMBeanServer();

			variables.manager	= createObject('java','net.sf.ehcache.CacheManager');

			variables.manager.create(javacast("string",expandPath('#arguments.scope#.xml')));

			variables.cacheName = arguments.cacheName;

	</cfscript>

	<cfdump var="#variables.manager#">

	<cfset createObject('java','net.sf.ehcache.management.ManagementService').registerMBeans(variables.manager,mBeanServer,

		javacast("boolean",false),

		javacast("boolean",false),

		javacast("boolean",false),

		javacast("boolean",true))>

<cfset variables.manager.addCache(javacast("string",arguments.cacheName))>

 

The above is the constructor code, I have split it out a bit so that you can see what is happening, but if call the above code without the cfdump, I get an error, but if remove it, it crashes. I have never seen something like this before.

UPDATE!

This morning, writing this post, I realised that in the third line I had forgotten to add the .init() to the CacheManager. Go figure! Seems that cfdump does the init for you eh?

As you may know from my previous posts, I am a bit into Model-Glue. Besides giving tips on using it I have talked at a couple of ColdFusion User Groups about the framework and try and pass on any knowledge I can, since I think its a nice brief framework that in conjunction with ColdSpring and Reactor (or Transfer) can really help your application development. The problem with just giving tips, is that if you have a whole development team to get up to speed, you need more formal training to really get up to speed. If you are in the USA, I found out recently that Alagad,Inc that über development company (run by Reactor supremo Doug Hughes, with none other than Jared Rypka-Hauer and Scott Stroz amongst others!) has started offering training courses in Model-Glue! The four day course based in Arlington VA seems to cover anything you need to get your team up to date, and, for a hands-on four day course doesn't seem expensive at all (ok, that might be because the pound is strong against the dollar, but then again, its still pretty cheap). Check out the details on Alagad's site (Tell them I sent you and I am sure they will make you a cup of tea!)

As some people might have noticed, its got so busy round here that I haven't been blogging as much as I used to and basically been keeping my head down and eyes on coding for the last few months. To aliviate this situation, Design UK, the company I work for is desperately seeking a couple of ColdFusion contractors to work in our London offices for a minimum of 2 weeks (could be up till XMas). No, you can't do the work remotely, sorry, don't ask. No, really... just don't. Also, if you are an agency, don't call me or email me. Just don't, really, you WILL get abuse, and I am sure you don't want that. The pay is dependent on experience (hey, I want to pay nothing, you want a lot, we compromise). The kind of experience that we are seeking is:

• 2 years minimum ColdFusion (obviously)
• Experience of Frameworks especially Model-Glue and ColdSpring are a massive plus
• SQL Server knowledge
• HTML, JavaScript and CSS (yep, there is front end work to do too!)
• XML (generating and parsing)
• Subversion and Trac knowledge is also a plus

Start date is as soon as possible, so if you are available and want some work, let me know by emailing me your CV to .

This is a quick tip for today. In all views you will probably be linking to other events, now of course you could write something like: <a href="#CGI.SCRIPT_NAME#?event=my.event">My Event </a> But what happens if you change the event key to something else (you can do that in the ModelGlue configuration section in the ColdSpring.xml file, see the property for "eventValue") such as "go" or "action"? You would have to change every view. A simple way round this is to put at the top of each view the following: <cfset myself = ViewState.getValue('myself')> And then change your links to: <a href="#myself#my.event">My Event </a> What do you think?

By default, when you create a Model-Glue project you get the following directories in you root project:

	/config
	/controller
	/css
	/images
	/model
	/views

This fits (apart from the css and images folders) with the idea of an MVC model. The problem that I find is that Reactor (by default) creates objects in the model/data directory. Why is this a problem you might ask? Well, I find that it doesn't fit in with what I think of the model. I see the model as the business model, and I tend to add another directory; "services" which interact with the model. The services are stored there and they glue the model together the model being stuff created by your ORM. I know people might disagree (no names) but I tend to add a services directory in which I have number of cfc's usually named %3CSomething%3EService.cfc . In my model folder I then have the objects and gateways. This means that the controller talks to the service and the service talks to the gateways and objects. This keeps it nice and tidy in my view. Of course, it doesn't matter at the end of the day, since you can change where all the objects are stored and just change your ColdSpring.xml file (you ARE using your ColdSpring.xml file your services aren't you?!)

As shown in the previous post, there is the ability to pass messages back to a message-listener with added information in the form of arguments. This can come in quite handy and allows you to make your controllers a bit more dynamic and re-usable so that they are useful under different situations. I shall give an example, which you should have spotted if you read the GenericList documentation, but I shall go into more depth here.

[Read more →]

A lot of the time that you are developing an application, depending on how you have set up your database etc, you will want to do a "select * from sometable", for example to get the types of pages you have, or a full list of user roles or simply to get the current user. This is all fine if you are sticking to the semi rigid pattern of having services for your whole architecture, but in the heat of battle, you might be tempted to do a cfquery in your view. DONT! Model-Glue gives you a built-in way of doing Generic Database actions (or messages as they are called in the documentation) The messages that you can call from the broadcast section of your event handler are:

• modelglue.GenericList: Which does a select * from [table]
• modelglue.GenericRead: Which does a select * from [table] where [id] = xyz
• modelglue.GenericCommit: Which will save the record (or update it depending if it already exists with that ID)
• modelglue.GenericDelete: Which will delete the record with the ID that you have passed in

An example of using modelglue.GenericList would be to list the People in our fictional system. In ModelGlue_people.xml I create an event-handler to display people: <event-handler name="people.list.users">
      <broadcasts>
         <message name="modelglue.GenericList">
            <argument name="object" value="People" />
            <argument name="queryName" value="qPeopleList" />
         </message>
      </broadcasts>
   
      <view>
   </event-handler> Then in my display template I can get access to the query: <cfdump var="#viewstate.getValue("qPeopleList")#"/> There is more functionality available such as filtering and sorting, you can check out the details in the Documentation for modelglue.GenericList Calling the other other Generic Database functions is as simple as that, have a look at the full documentation over at http://docs.model-glue.com/ under "How To's" / "How To Use Generic Database Messages"

When you develop model-glue apps, you start adding your view files in the /views directory, this all fine as a demo or in a small application, but it can get very full of items. An easy way to sort out your views a bit, is to use the same naming convention we used for the event-handlers but to create directories to hold the views named after the controller they relate to, for example:

	/views
		/pages
		/security
		/products
		/layouts
		/nav
	...

I tend to keep views that are used in multiple places (lets say a top nav) in a /nav directory and the layouts in a /layouts directory. Another way to distinguish your view files comes in the way with prefixes for what kind of file they are, so for example listing pages have dsp_, form pages have frm_, pages that output XMl start with xml_ and navigation pages start with nav_. Hopefully following these tips it will be a lot easier for you to find the right view quicker!

Continuing from the previous post, I wanted to talk about naming conventions, I am sure everyone has a way of doing this and will argue (a bit like IDE or OS wars) till they are blue in the face. This is the way I try and do it, maybe because I started out using fusebox, but it makes sense to me. If you have split out your Model Glue file as mentioned in my previous post, you will already have event-handlers that deal with different areas of your application, why not do the same with the event handlers, then you can see exactly what you are dealing with. For example, if we are doing Security related functions (in my ModelGlue_Security.xml file) it makes sense to name the event-handlers something like "security.dologin" or "security.dologout" then you will be able to see exactly what part of the application you are dealing with. I hope this makes sense and is useful!