Mail: <br><font size=2 color=blue face="Arial">>> 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.</font><font size=2 face="sans-serif"> </font><font size=2 color=blue face="Arial">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.</font> <br> <br><font size=2 face="sans-serif">This is really the essence of what I'm working on, too. Will MVCF (or Fusebox, or whatever) be the best solution for every application? No, because there is no "one size fits all", silver bullet solution. Is it easier and more streamlined to start the design phase with the understanding that, all things being equal, the FooBar methodology is our standard and should be considered first? Absolutely. I've already done this with our visual design standards with great success. We don't spend a ton of time laying out a visual design for our applications unless there is some business reason why.</font> <br> <br><font size=2 face="sans-serif">The thing I keep running into is my management asking questions like, "didn't we already develop a billing system in the FooMatic system?" It's extremely difficult to explain that FooMatic was written in a modified Fusebox 2 architecture, while the current project was designed in a totally proprietary way, and that the input vectors are totally different and will present an enormous challenge to re-engineer. Management doesn't care about these things because they don't understand them.</font> <br> <br><font size=2 face="sans-serif">This is the second time I've come into a team that was in total chaos and been asked to turn the team into well-oiled machine (think "Junkyard Wars" ). The first time, it took around four years. Hopefully, this time I will be able to do a better job in less time, because this time I know that I don't necessarily have to develop the standards myself. But standardizing as much as possible is a key aspect to this process, including the possibility of some of my team coming to view me as a "Code Nazi bastard". Hopefully, they will see the benefit of it, but I'm willing to take that risk.</font> <br> <br> <br> <br> <table width=100%> <tr valign=top> <td> <td><font size=1 face="sans-serif"><b>"Jeff Battershall" <[EMAIL PROTECTED]></b></font> <br><font size=1 face="sans-serif">Sent by: [EMAIL PROTECTED]</font> <p><font size=1 face="sans-serif">03/25/2003 04:20 AM</font> <br><font size=1 face="sans-serif">Please respond to cfcdev</font> <br> <td><font size=1 face="Arial"> </font> <br><font size=1 face="sans-serif"> To: [EMAIL PROTECTED]</font> <br><font size=1 face="sans-serif"> cc: </font> <br><font size=1 face="sans-serif"> Subject: RE: [CFCDev] MVCF at benorama.com</font></table> <br> <br> <br><font size=2 color=blue face="Arial"> 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. </font> <br><font size=3 face="Times New Roman"> </font> <br><font size=2 color=blue face="Arial">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. </font> <br><font size=3 face="Times New Roman"> </font> <br><font size=2 color=blue face="Arial">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. </font> <br><font size=3 face="Times New Roman"> </font> <br><font size=2 color=blue face="Arial">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. </font> <br><font size=3 face="Times New Roman"> </font> <br><font size=2 color=blue face="Arial">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. </font> <br><font size=3 face="Times New Roman"> </font> <br><font size=2 color=blue face="Arial">Jeff</font> <p> ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
