Slashdot Mirror
ColdFusion Programming Methodologies?
lars-o-matic asks: "I work at a small (dozen people) company doing quite well building small-to-medium sized sites on the ColdFusion platform and the Fusebox architecture (which also has PHP and JSP versions). With our growth, increasing demand for Flash apps, new features of CFMX, and wanting to take on larger projects, we are researching methodologies. We like Fusebox3 for CF but worry it does not leverage the new object-like CF Components, web services, Flash remoting etc. and wonder if some kind of model-view-controller approach would help separate presentation from business logic. And there's structured documentation, re-usability, maintenance and yes, performance to consider. We're happy with the platform, which suits our project scale. We're not (yet) building a Google or an Amazon.com. It's methodology we need. How have the Slashdot CF users out there scaled from 2 to several coders and from little sites to larger ones?"
"We're not (yet) building a Google or an Amazon.com."
Nope, and you won't be w/ CF! When you begin getting a little more visitors to the site, and when the site becomes a bit larger, CF will be out of the game! Use a real language, drag n' drop programming is for M$ weenies who can't use real languages!
For CF, FB is about it. Not that it's bad, but you don't really have anything else to point to re: a structured, methodical approach to web development. Mind you, what's there is pretty good, if still a bit sketchy in some areas.
:)
It doesn't leverage whatever OO might be available in CF. It can't, because FB has a history, and the latest CF is, well, the latest. FB will eventually catch up - I've heard the core fusebox team is working on this issue. Timeframe to 'recommended' specs? Dunno. If you're sticking with CF, stick with FB, or come up with something else which suits you better. If you want to migrate to PHP, consider having us come out and give your developers some custom courses in PHP, suited to the topics you need to brush up on. (subtle plug, but what the hey!)
creation science book
personally, i can't stand fusebox. it's an artificial construct attempting to impose order on what is, essentially, a scripting language. a powerful one (i've been building fairly large scale applications in it for ~5 years), but a scripting language nonetheless. it's just not MEANT to have that kind of structure/organization.
or at least, that's what it was LTE CF5. (as a disclaimer, i have NOT worked with MX.)
with the advent of CFMX, it may get better, but most likely it won't be more than a set of rules for including files to simulated separating business logic from presentation, and "virtual code reuse".
as a corollary, i end up developing a set of my own "code management" rules. develop them inhouse, publish the document, and give a copy to your developers when they're new hires. you can customize it to the way your own shop works, and not be constrained by the artificial rules of another development shop. and hey, you can publish that document and call it "FooBox" (or whatever) and pick up some cash.
Quidquid latine dictum sit, altum sonatur.
This is slightly offtopic, but I'm curious what the market for CF development is like. I LOVE developing in CF but lately have been stuck in ASP and Java development. CF seems to have slipped in its prevalenca and I'm hoping that the new MX version will give it new life. Do you find that you have to push CF on people or are they coming in asking for it?
THIS SPACE FOR RENT
Well, judging from the # of posts here, either this ain't the place for CF posts or the market isn't too hot. Shame, too. CF4 did exactly just about everything that a developer of small to medium web-apps. needed or wanted to do. CF4 worked very well with Apache. As the market for small to medium web apps went towards the gutter, so did CF, I guess. Turns out the web wasn't as popular among the basic small- to medium-sized businesses in the business world was (and amazingly still is) thought.
CFMX, as far as I can tell, is the Allaire boys (after selling out to Macromedia) and CFMX trying to be the all-purpose IDE for all dev. environments, instead of just doing its own thing, which got it where it was. Those that try to please everybody generally just please no one. Oh, well. It was really fun while it lasted.
(whatever)
You might look into FuseQ. It's being developed by John Quarto-vonTivadar (and perhaps others?) at Techspedition. One of FuseQ's goals is to become the basis for the MCV model within Fusebox. See also this article.
One of the other guys at techspedition is Hal Helms, one of the early embracers/gurus of Fusebox. The current Fusebox 3 standard is based heavily on many of his ideas, including circuits and FuseDoc. He has written a book called Discovering CFCs (ColdFusion MX Components). Thus, I'm guessing that he is working hard to integrate CFCs into Fusebox.
Fusebox is relatively young, and still very flexible. It's very likely that the new features in ColdFusion MX will be incorporated into newer versions of Fusebox. After all, they need to return the favor--Macromedia/Allaire actually incorporated a tag developed by Fusebox developer Steve Nelson into ColdFusion 5: <cf_bodycontent>, with some variations, became <cfsavecontent>.
Karma: Chevy Kavalierma.
First, Fusebox isn't an architecture. Second, MVC isn't a methodology.
Any good methodology wouldn't be specific to a programming language. A good architecture for Web applications would also not be specific to a programming language. MVC is a design pattern that can be applied to be different architectures and programming languages. About the only specific thing you really need for CF is an application framework. Fusebox is an application framework; it just isn't very good.
I haven't seen MX cause I am now working for a company that is PHP only. I suggest you get your experienced coders to throw ideas around, having something that is sane and them is invaluable. I would still have input from your "non-geek" coders, but you really want the guys who eat, breath the web to formulate your spec, cause they have more to draw on.
BTW I was the secondary coder originally, because I was still in high school at the time, but I understood a lot more about coding standards and what was structuring, but not limiting to what I want to do.
Gah. The web is just the WRONG paradigm (can I say that?) to use for complex interactive applications. When you purchase a car, does it come with a "page-based" interface metaphor? Are there "steering-wheel-emulation" frameworks for emulating a steering wheel on a piece of paper? Yet that is what all these MVC frameworks which attempt to emulate an interactive stateful application on the client side propose to do.
It's just wrong wrong wrong wrong wrong. The web is great for displaying PAGES, not applications.
For the complicated applications people are trying to shove on the web, we need a new solution. Something in between a standalone fat application, and completely server-rendered pages (web). Something like cURL, or XULUX, or (choke) XUL + scripting glue.
When you try to add complicated statefullness and interactivity to the page-based server-based metaphor, complexity scales exponentially...it's just crazy. Your app just becomes a Big Hairy finite state machine DSP.
It's 10 PM. Do you know if you're un-American?
i can't stand fusebox. it's an artificial construct attempting to impose order on what is, essentially, a scripting language. a powerful one (i've been building fairly large scale applications in it for ~5 years), but a scripting language nonetheless. it's just not MEANT to have that kind of structure/organization.
d ef ine
There is nothing wrong with scripting languages and scaling. However, it does depend on your design style. I try to use the database to manage over-all structure, and not so much programming code. More on this at:
http://www.geocities.com/tablizer/misclang.htm#
The most annoying thing I found about ColdFusion was it's lack of first-class functions/subroutines and funky variable scoping rules. You can get subroutine-like structures using custom tags or the scripting syntax, but they are just not "full citizens". There are certain things you cannot do with or in them. Thus, one tends to end up with long "main" scripts. I want full-blown subroutines.
On the plus side, it has something that PHP and ASP do not have: named parameters.
I looked at fusebox a bit, but found it not very adaptable. It seemed to force pages into one of a predefined set of categories and I needed a finer control for the more complex pages which did not neatly fit into a category or spanned multiple.
Personally, I would totally overhaul the way many biz-centric web forms are typically handled in web scripting languages. There needs to be a "view buffer" IMO on the server side, and one talks to that view buffer instead of to HTML directly. The view buffer is then echoed at the end of the script task to the client (after being converted to HTML), but does not disappear. It would make development more GUI-like. Complex form validation and lookup fields would be much easier because you don't have to keep redrawing the HTML from scratch each time with subtle changes.
Microsoft's dot-net stuff comes a bit closer, but they admittedly convoluted their approach for speed purposes. This is a mistake for most biz apps. The best techniques and optimization profile for building eBay and building an intranet are very different. MS sold out to the benchmark wars IMO. More about this at:
http://www.geocities.com/tablizer/webstif.htm
Table-ized A.I.
On the plus side, the fusebox framework brings some organization to what would otherwise be a collection of interconnected pages of script. Fusebox is fairly straightforward and a developer can use it with a single day of instruction, so it can be a very useful application development tool.
OTOH the resulting application is usually a single large executable which handles all functions (and pages). This is not in itself a bad thing, but appears to be precariously close to the Big Ball of Mud methodology of software development, although it really isn't.
Until something better comes along for scripting languages complex applications can be organized using fusebox. And at that time it shouldn't be difficult to refactor an application from the fusebox framework to another, better methodology.
The REST methodology approaches applications development from another perspective and is grounded in the structure of the WWW: it may be the next place to look for organizing WWW applications development.
...a way of going about something is a *method*, not a "methodology." Yeah, I know, everyone uses it, but it's still wrong. Don't they teach English in college these days?
ahem
Jeremy French
Atabia Internet Services
If you build sites that need to scale multilingually, you'll find CFMX dramatically better than PHP or Perl because it's based on Java (therefore Unicode) strings.
It gives you the convenience of tag-based scripting, like PHP, with the internationalization power of Java.
This isn't likely to matter if your client is a local shoe store, but for larger clients it does, even if the client doesn't realize it.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Don't do it kids, mmmmmmk?
I'm being forced to develop a LARGE scale app using Fusebox. I've been programming CF for a little over five years now and developed my own standard I called "pseudobox" because it implemented the GOOD qualities of fusebox and left room to be creative. I hate the fact everything has to fall under dsp, act, qry, etc. In the app I'm building right now, that's not enough. And I don't like the fact that I have to post the form action a fuseAction to the index.cfm file...why can't a form just post to itself? I've worked at a lot of different types of software houses in the past that consisted of mainly knowledgeable web developers and we all agreed that fusebox is most definitely not the way to go...too bad the morons in management at my new place don't share the same opinion.
Fuxebox doesn't organize or change the code, per se. It is a *way of coding* and structuring sites, so that everyone codes the same way. Thus, any member joining the team, or joining a project half way through can just pick it up and immediately understand the architecture and logic, because it is the standard fusebox architecture and logic.
Yes, fusebox is imposing order on the chaos of scripting languages, but I'm betting that it doesn't impose nearly as much on neat/tidy coders as it does on sloppy coders.
The problem with developing your own 'in house' rules is that no one on the outside knows them... so you can't hire someone who already knows 'your' rules.
geeks are cats who dig a certain kind of cool