I agree with Hal. I've been in projects where every CF
developer was "rolling his own" solution for the problem at hand, and their
solutions were not particularly interoperable :) Also, if you're
constantly "making your own way", this can be a real slow down in attempting to
get a production flow going. It also becomes very difficult to evaluate
developer talent if there are no standards to compare them to. One of the
most significant contributions of Fusebox is having a basis of agreement and
cooperation, not to mention a move to cleaner separation.
I am
very interested in evolving a framework for my company that is elegant,
repeatable, and can be trained in on new developers. No, I don't
think this framework will suit all situations, but it may suit the majority of
them and will reduce time to market. I've done a good bit of
Fusebox-esque development in my time. My basic problem continuing in that
vein is that I believe the CFC offers structure options that didn't exist
before. Whether it supports a full blown inheritance hierarchy is not
important to me - I'm a CF developer after all - I just want to code a MVC
style separation that provides some presentation layer flexibility,
encapsulation and ease of maintenance.
I'm
reading up on Struts and there's a lot to be learned there. Many of
the modalities are adaptable to a CFC based architecture. I like the idea
of a singleton (application scoped CFC) that handles the request and passes
off the request to the appropriately mapped actions. That singleton could
parse a config xml file at start up which would contain the
mappings. I like Beniot's work because it moves in this
direction. And I certainly draw upon my Fusebox experience in evolving
what I intend to evolve.
As far
as the performance of CFCs, I've been seeing some pretty good things. When
a CFC takes 0 milliseconds to run, what's not to like? Granted, I am doing
some relatively lightweight things, but so what? And, call me crazy, but I
rather like it that a session scoped CFC is "disconnected" from the request
scope - it tends to enforce that I explicitly pass arguments to the object
instead of getting lazy. Storing a logged-in user's profile in a
session scoped CFC seems to work like a charm in CFMX. If I want some page
context, why I just go and get some by calling a non-scoped CFC. If I need
run some algorithm or biz logic that is truly beyond the capabilities of
the CFC, then it's time to write something in Java.
So
that is where my thinking is going. My concern was/is if there are other
problems with CFCs that I don't know about that I am going to inadvertently run
aground on. I don't want those type of surprises.
Jeff
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Helms
Sent: Tuesday, March 25, 2003 12:44 AM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] MVCF at benorama.comHere's a different POV: while it's absolutely true that "if it works, it works", there's something to be said for a standard. If you bring your laptop to my office, we're pretty sure that there won't be any problem with you plugging it in, because the plug adheres to a standard -- as does the laptop. Anyone who's traveled to other countries than their own may have had the experience of different plug standards. When that happens, things that we take for granted can become a big issue.I find this to be true in software development. I once worked on an ecommerce site for Sun Microsystems (solutionssite.com) in which the coding was done in one week by developers (who I had never met) who were working on the internet. (*Why* this had to be done in a week is a long story...) The reason it was possible was that we were all working to a known standard and friction was minimized.Years ago, I worked as a woodworker, building custom furniture in my one-man shop. I loved the independence and creativity that comes from doing "one-off" work and would not have wanted any system. The journey, as they say, was as important as the destination. When I moved from Boston to L.A. (talk about culture shock!), I ended up having a 13-person woodworking shop. We adopted a system for building cabinets and furniture that was invented in Germany. It made life enormously easier.I guess my point is that whether you want a standard or not depends on the environment you're in and what you're trying to achieve. For some people, a standard does them no good. For others, especially working on larger projects and with several members of a team, a standard is a godsend. I don't think there's a right or wrong answer -- just different answers to different questions.Hal Helms
"Java for CF Programmers" class
in Atlanta, GA May 5-9
www.halhelms.com-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes
Sent: Monday, March 24, 2003 6:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] MVCF at benorama.comIn truth after much debate i can't see FBX and MVC working with CFMX. Its too abstract in my books.I'd stop looking for the holy grail of "how to" program in CFMX and simply makeup or adapt your experience into your own methodology. I think too many people are spending too much time chasing the holy grail and wanting another FuseBox rule book to judge your code by, when in fact if you have to constantly refer to the "how to's" within a methodology, your constantly going to second guess yourself and your abilities to develop.This is the time, now to develop, and hone in on your own ideas and concepts, the worst that can happen is someone will pass their opinion that your "methodology" sux, and in return you ask them for theirs and with no doubt, they too will have someone higher in the "OOP er33t" foodchain saying the same thing.If it works, it works! if it doesn't, rethink, restrategise and then go at it again.Scott Barnes
Snr Developer
eCommerce Department
Tourism Queensland / Sunlover Holidays
[EMAIL PROTECTED]
ph: (07) 3535 5066-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Davis, Eric
Sent: Tuesday, 25 March 2003 4:55 AM
To: [EMAIL PROTECTED]
Subject: [CFCDev] MVCF at benorama.comLink: <http://www.benorama.com/coldfusion/>
Word ver.: <http://www.benorama.com/coldfusion/patterns/MVCF.doc>Has anyone looked really hard at this one? What are everybody's thoughts on this?
I'm looking for a replacement to Fusebox 3 for MX - FBMX is too slow coming, and probably won't make much sense anyway (I'm guessing it'll be quite obfuscatory and rather difficult to implement the first five to ten times).
He's put together quite a presentation, and he about has me convinced, if only I can simplify the structure a bit. I'm trying to find the right methodology for my team here to use, and they're NONE of them big methodology-users.
Anyway, just haven't seen any threads about this, and wondered if you folks had anything to say on the subject.
Which of course you must; you always do. ;)
Thanks,
ecd.--
Eric C. Davis
Programmer/Analyst I
Georgia Department of Transportation
Office of I.T. Applications
404.463.2860.158
[EMAIL PROTECTED]
