Mixins in ColdSpring? What would you like?

So a while back I was thinking about the ColdSpring AOP framework, and expanding it to support mixins. I really like the idea of doing something like this declaratively, I think it will be much cleaner and easer to debug when configuration is done from outside of your cfcs. What a surprise to read posts by both Joe and Sean today about ways to implement mixins! Well, I'm definitely going to get this started next week, (I really have to finish something first, there's a _remote_ possibility it will be done tomorrow, hint hint...) so if anyone has any wishes, drop a comment and we'll see what we can get in there. I mean, there's not too much to it, we'll be adding methods and perhaps instance data to cfc declaratively, but there were some comments on both blogs that make me think that I'd like to hear how people see using mixins so we can work that into the implementation. Thanks for the input!

Get On the Bus! Register for cf.Objective!

Looks like I’ll be speaking at cf.Objective in March, along with some really great cf-gurus, Sean Corfield, Hal Helms, Joe Rinehart, Matt Woodward, Jared R, among others. Personally I’m really excited, it looks like Jared’s definitely trying to get this conference wrapped around some advanced enterprise level sessions. So get signed up!

Sean Corfield Spawns More Interface Debate…

The debate on whether or not ColdFusion needs interfaces returns, headed up by a really good post by Sean Corfield. There’s some excellent discussion going on in the replies, I’d say this is a definite must read thread. As good as many of the points are, however, I’m not swaying, I want interfaces, and as soon as I get my thoughts together, I’ll show some examples of how they can be used very effectively. One thing I would like to throw in is that interfaces aren’t only about typing and providing a contract for your objects. Interfaces can give your objects sudo-multiple inheritance. Lets say your object extends one base class, but also satisfies the methods for two interfaces, if you have methods in some objects that take arguments of any of those three types, four including the type of the composite object, that object can satisfy any of those type constraints, thus acting as 4 different objects from the point of view of the various methods. If we set the argument types to ‘any’ or ‘WEB-INF.cftags.component’, that method will accept any object, and we void all contractual obligations of our objects, no matter how conceptual they really are in ColdFusion.

Creating ColdFusion’s missing ‘instanceof’ method

Yesterday I was going back over some ColdSpring code, implementing some new features, and I came across the answer (sort of) to a question I remember being discussed a while back on CVCDev or topica. How do you find out if an object is an instance of a particular cfc or one of it’s subclasses? Unfortunately, ColdFusion doesn’t have the keyword ‘instanceof’ like Java and C#, which I suppose is far more commonly used in a strongly typed language. Why would it be more necessary? Well, for one thing the O’Reilly C# book I have advocates the use of instanceof before casting, alleviating ClassCastExceptions, but that’s another story. Anyway, I have run into a few situations in ColdFusion where I really need this functionality. So how do we do this in CF? Well, when I looked at what I had written a few months ago, although it works ok, the comment below it, ‘shouldn’t I be looking in the ‘extends’ key only?’, basically pointed out that it was a shotty implementation at best (btw, I looked back over the history of the file, and the original comment was ‘this sucks, I need to do this better later!’), so I asked Sean what he thought about it. Here’s something along the line of the original code I sent him, the main problem here being that by using StructFind() I am searching every key in every nested struct:

<cffunction name="isInstanceOf" access="public" returntype="Boolean" output="false">
  <cfargument name="obj" type="any" required="true"/>
  <cfargument name="reqType" type="string" required="true" />
  <cfif ArrayLen(StructFindValue(getMetaData(obj), reqType, "ALL"))>
    <cfreturn true />
  <cfelse>
    <cfreturn false />
  </cfif>
</cffunction>

Sean immediately pointed out that that was ok, but slow. Maybe I should search recursively through the extends keys of the metadata. So here’s what I ended up with, which seems a heck of a lot tighter to me. I shied away from the recursive method call, because that seemed it would be putting a little extra overhead on the search, but this implementation seams nice to me, thank for the input Sean!

<cffunction name="isInstanceOf" access="public" returntype="Boolean" output="false">
  <cfargument name="obj" type="any" required="true"/>
  <cfargument name="reqType" type="string" required="true" />
  <cfset var searchMd = getMetaData(obj) />
  <cfif searchMd.name IS reqType >
    <cfreturn true />
  <cfelse>
    <cfloop condition="#StructKeyExists(searchMd, "extends")#">
       <cfset searchMd = searchMd.extends />
       <cfif searchMd.name IS reqType>
         <cfreturn true />
       </cfif>
    </cfloop>
  </cfif>
  <cfreturn false />
</cffunction>

Fresh for 2006… ModelGlue for Java!

About a month ago I went down to the DC area to visit with Sean Corfield, Joe Rinehart, Doug Hughes, Scott Boyziod, and a few others, and for some reason Doug and I were talking about his port of ModelGlue for .Net. I don’t know why, maybe for pure masochism, I mentioned that maybe I would be interested in porting ModelGlue to Java. Well Joe though it was a good idea as well, so I decided to give it a go! Over the past month a few people have asked me why I would want to do such a crazy thing, and I do have some reasons! Most importantly, I know a lot of cfers are starting to think about getting into J2EE development, and I know from personal experience, that the initial learning curve, not so much of the language itself, but really of the architecture of J2EE, can stop people in their tracks. Maybe a familiar framework would be a bit of a helping hand? I think so. I’ve done a few J2EE apps and one of the things that I always seem to find myself saying is, ‘man I really like working with mach-ii and modelglue much better that any of these java frameworks’. Struts is too big and too messy for me, SpringMVC is actually pretty nice, but still kind of heavy. For me, I think ModelGlue sits about right for an MVC framework, since it is so lightweight. So I’d like to announce that an early alpha pre-release is not available from svn://clearsoftware.net/clearsoftware.net/ModelGlueJava.

A few notes about this early release:

Spring support is built into the framework, but by doing so, it is currently dependent on the spring distribution. Spring.jar is included in the lib folder of the distribution, along with other dependencies such as commons.beanUtils. An example of defining your controllers in a Spring config file can be seen in the Klondike Records sample app.

I have not implemented asynchronous messaging or session state container support yet, but everything from the current BER of ModelGlue should (maybe) be implemented.

I did make one possibly major, but really semantic change, that I just thought fit better into java. The viewState that you would normally access in views is called eventModel, and is of type EventModel, which extends HashMap. So add(Object key, Object value) and get(Object key) as well as other HashMap methods are available if getValue(String key [, Object defaultValue]) ) is not to your liking. I just really feel strongly that as a user we are dealing with a model object that is tied to the event when setting/accessing values in our controllers and our views. The names have changed to protect the innocent, but nothing more!

Final notes, I’m not done at all! I’m hoping an early preview will gain some interest, and maybe some input and assistance from other java/cfers out there, so have fun, and of course, I’ll be changing things for a while!