Title: Message
It's been interesting to see over the years how the collective understanding of architecture issues have evolved.  It's like we're all pushing forward together in a way.  MM & Allaire have been a fantastic vehicle for all of us to produce viable products so that we can live while we figure it all out. 
 
The desire for understanding of architecture has hit a new level in the developer community at large.   This is why Benoit's work (and that of the Fusebox community and many others) has been so well received.  People are gravitating toward a system.  This makes sense, because we have to have "agreement" on a system to enable cooperation between developers, especially on larger projects.   We also want to 'swim with the sharks' as it were, because enterprise developers in other languages have gotten here some time ago. 
 
As regards use of CFCs for MVC implementations, I'd have to say, in my experience, that the primary difficulty would be the Page Context bug.  Personally, I have not found it too difficult to deal with this.  Ultimately that problem will be solved.  IMO, there is too much value in what CFCs have to offer to not use them.  I need some compelling information to dissuade me from this course of action.
 
It is of concern, however, because you don't want to make architecture decisions on large projects that work out to be bad ideas.  I'm there right now, architecting a large web site for a university.  So when Matt says that CFCs won't scale for the Model, then I need to know what the story is.  There is the question of what he refers to as the "Model".  Are we talking using persistent CFCs for modeling?  What situations or usages caused problems?  Are there some code samples we can see?
 
In lieu of access to the archive, can we get a short list of the major gotchas?  And what sort of pressure can we bring to bear on MM to address these?
 
Jeff
-----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.com

In 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.com

Link: <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]

Reply via email to