Ask a Jedi: Does using a framework reduce your portability?

Dave asks an important question for those using frameworks:

You have shed light on frameworks, methodologies and how we can benefit from them. I think it would be simply spiffing if you would address a similar topic on your blog: portability. How portable is an application that employs mach-ii, modelglue, mvc... How might this affect redeployment, distribution or selling such an application?

This is sure to be a critical factor for many developers who are evaluating the new frameworks. It would be dandy if you could start what I hope will become an ongoing discussion in the ColdFusion community.

This is a pretty interesting question. I can only speak to Model-Glue as I have not used Mach-II or Fusebox. In general, the portability of these applications typically comes down to one question - can you use a mapping? I know that Model-Glue can be used without a mapping. The last time I did this I remember it being a bit of a pain, but doable. But in general, this would be the only issue you wound run into. Of course, the flip side of this is that you may deploy to a location that does allow mappings and is already using one for your framework. Then you either use the version they have or you force your code to use your version.

In the best of worlds - you have a box with the frameworks set up so that any site can use them. The frameworks can be updated easily and all applications get the benefit of the new updates. Oh, and they are always 100% backwards compatible as well. Of course, no one I know actually lives in that world.

So what should you do? If I were moving to an ISP, I'd setup a very simple application that uses the framework. For example, Model-Glue comes with a simple application. Get that application up on the ISP and ensure it runs correctly. The last Model-Glue site I created used both a mapping for Model-Glue and ColdSpring, and the ISP had no issue making that for me, but it is something you want to know ahead of time obviously.

One last practical example: The next contest entry that will be reviewed (in a few hours) used Fusebox 5. I didn't even know this till after I started using the application. I'd consider that a good example of portability.

What problems/concerns have others run into?

Comments (4) Aug 29, 2006 6:21 AM Views: 2440

Comments

[Add Comment]
No Problem or concern.. just a comment. I have used a ColdFusion ecomerce product called CFWebstore that started using Fusebox when they moved to version 5. As far as portability in set-up and use with that framework I've found no problems. There were no special considerations in set-up caused by using that framework.
# Posted By Robert Owen | 8/29/06 7:00 AM
In general, as Ray says, your code is as portable as the framework it uses, and almost all decent CF server providers will offer almost all frameworks, by default or on request.

A lot of effort is put into making a framework run in as many places as possible - not just CPUs and operating systems but with and without mappings - though having a mapping generally means you as a developer don't need to worry.
# Posted By Tom Chiverton | 8/29/06 7:18 AM
It seems you are talking about portability of code between servers. But, how portable is the code between different applications and/or different frameworks? Using a framework is supposed to help this type of reuse (or so they say)

I know Model-Glue (1.1) the best of any framework. I'd say that the Model portion is as portable as you code it. If you're properly encapsulating your code, then you should have no problem taking the same 'model' and putting it into another application, be it a Flex based front end, or Mach II, or Fusebox, or some other roll your own app.

However, Model Glue views will [most likely] only be portable to other Model Glue applications. This is because you aren't passing parameters into the Model Glue view (like you do to your model). You just access the relevant variables by using the Model Glue API (AKA ViewState).

A controller is usually application specific and I wouldn't expect it to be easily portable without also moving the relevant model and view bits.
# Posted By Jeff Houser | 8/30/06 8:31 AM
I'd just like to point out (as the lead developer on Fusebox 5) that Fusebox has always allowed the "self-contained application" approach where you can bundle the framework inside your application and "It. Just. Works."

When I started on Fusebox 5 - a rewrite from scratch - and went with CFCs for maintainability, my key focus was on backward compatibility and to retain the ability to just "drop in" a Fusebox 5 application on any server and have it run.

That means all the CFCs are in a single directory so there's no path information involved. You can drop the framework core files into your application "root" and then package up the whole thing and run it on any server.

I think Fusebox is the only framework that is designed to work this way.

Note that Fusebox also allows a single install of the core files on the server if you want, either in the web root (no mapping) or anywhere on the file system (with a mapping). That ability was introduced in Fusebox 4.1 and is also present in Fusebox 5.

For more information, check out http://fuseboxframework.org/
# Posted By Sean Corfield | 8/30/06 10:51 AM
[Add Comment]