OscarArevalo.com - OO

Overcoming CFC Serialization Issues Using Java

Mon, 28 Jul 2008 23:37:00 -0500

*** THIS IS A REPOST OF AN EARLIER ARTICLE THAT GOT WIPED OUT ON A RECENT DB CRASH. *** At work we always build our applications targeting clustered environments, that means that even if an app will be deployed to a single server at the beginning, it can always be moved to a cluster without any change. We also use our own infrastructure for clustering and don't rely on session replication or sticky sessions. That environment presents certain challenges for maintaining state within an application. Our standard solution is to rely heavily on a DB backed Client scope. However, this has always limited how we can persist CFCs in the application. Typically when we want to persist a CFC we have to build our own serialization/desearialization mechanism to accomodate it to the client scope limitations. This solution would work fine for simple CFCs but it would rapidly become a hassle (to say the least) when dealing with composition/aggregation relationships. Needless to say when I learned about the CFC Serialization feature in CF8 I was very eager to see how it could allow us to make better use of persistent CFCs. Sadly as soon as I started to make some simple proof of concepts I discovered (and later confirmed) the limitations of the current implementation of CFC Serialization in CF8. Apparently the serialization mechanism chokes when you have arrays, dates or query variables as instance variables in your CFC. Actually the problem is not the serialization, but the deserialization process. Anyway, since other than that the CFC serialization worked beautifully (as far as I could tell), even with composition relationships, I still wanted to find a way to make use of this feature. After a little bit of tinkering I found that I could make the CFC Serrialization work as intended if I just used a different Java class for the objects instead of the one provided implicitly by ColdFusion. For example, instead of using ArrayNew(1) to declare my array, I found that using createObject("java","java.util.ArrayList").init() would work just fine. And for date objects using java.util.GregorianCalendar would do the trick. Obviously the code that interacts with this Java objects need to be updated, but you can always create wrappers around it to handle the transformation between java.util.ArrayList and regular ColdFusion arrays, for example. Well, here is the code for the object I used on my testing. I can now happily say that my days of limiting myself to persist only dull CFCs seem to be coming to an end :)

PS: You can find the code for serializing/deserializing CFCs here and here.

A Rant on Frameworks, Libraries, and Shells

Fri, 30 May 2008 09:51:00 -0500

We spend ridiculous amount of time discussing the merits (or lack of) of the different MVC frameworks in ColdFusion, and we keep doing it again and again. Well, at least everyone should agree that when it comes time to decide how to go from one page to another we got that pretty much well covered. But for all the OO fever taking over the hard-core ColdFusion community as of lately, why are we still focusing on the presentation layer still, which honestly is the least OO place in the whole application? Where are the repositories of just plain libraries? components and subsystems that we plug together to provide sophisticated functionality to our applications regardless of how the presentation layer is done. Yes, we have Transfer, ColdSpring, and Reactor, and they really rock; but it seems that that's where the list ends. Has nobody written a really tight, super strong, caching library? what about a job-scheduling library? It could be that the lack of these libraries as separate entities is what motivates MVC framework authors to add more and more complexity to their projects, which in turn fuels the discussions of why these frameworks are so bloated and complicated. I know Luis, from ColdBox, has put a lot of effort in building the caching functionality in his framework, and knowing the quality of his code I'm pretty sure it kicks a$$; but sadly is all tied into the framework. Wouldn't it be much more beneficial to everyone if there were already some project out there that would provide this functionality so that you could just plug it in into your application? If we have enough of these little libraries that would focus on doing one thing and one thing only, then the 'framework' in which an application is built would not need to be these gigantic-swiss-army-knife platforms that we are getting used to. They would become lighter and lighter until they are reduced to a 'core', just down to the basic principle that embodies their core ideas. Imagine a coldbox-core, a modelglue-core, a fusebox-core, super small code bases that just provide the basic guidelines and minimal code to support a proposal on how an application should be structured; And then on top of them we could have 'distributions' or 'shells', canned projects that would group together a 'core' and a few libraries to put together a basic solution, custom tailored for specific purposes. For example, you could have a shell for an intranet application that includes the framework core, a caching subsytem, a security subsystem, an IOC subsystem and an ORM subsystem; or on the other hand there could be a shell for a plain website that may only include the framework core and a caching subsystem. The bottom line is that all those parts can be plugged in an out and replaced or extended, and the application as a whole could be customized to the specific needs and would not need to carry any added complexity that is not desired by the author. If I may give a suggestion, we should move on from the MVC frameworks and start focusing in these kind of projects. We need to focus more on libraries and subsystems in that the only interface is an API that can be used by other applications. Of course, in order to do that, it should be easy for everyone to find these libraries. RIAForge makes a terrific job as a repository of entire projects, and maybe it could be extended to add a new category exclusively for ColdFusion libraries and APIs; or maybe we need an entirely new website to allow us to post and search libraries for different types of functionalities that anyone wanted to add to their application. Any thoughts?

Using Polymorphism and Inheritance to Build a Switchable Data Access Layer

Wed, 28 Nov 2007 19:22:00 -0500

One thing I don't like when starting on a new application is having to go through the process of setting up and configuring the database before I can get anything even running at all. So, for a couple of projects I'm working on I thought about reading and writing data to plain and simple XML files and then later replace that section of the code with a proper database access layer. However the idea of just throwing away a large chunk of the application didn't sound very appealing, so after some thinking, I started playing with the idea of abstracting the actual storage medium from the application logic. Something that would let me change from XML files to database tables without having to change (or throw away) any application code. This, of course would involve some sort Data Access Objects, and also somewhere along the way would incorporate some sort of shape shifting object that would know how to either read/write files or do insert/select/deletes. Well, after some more playing, thinking and tinkering I came up with a way to address the issue at hand; and in the eventual case that there is someone else out there with a mind as twisted as mine that would actually consider making something like this, I share my solution here. [More]