Shameless is right... you list yourself as lead developer for C4.net... which is an ASP site. Then your review CFMX as compared to current CF with Fusebox. Pardon the initial conclusion... but that seems somewhat to be an agitant rather than a former supporter of fusebox. Do you have any sites that you built with fusebox? ... (Reading your article... yes page 3)... So you do program in a variation of fusebox... is this asp, or ColdFusion? It appears you have done ColdFusion. Your article is inept... have you built an entire site with MX yet? Have you replaced all the fusebox architecture with your pseudo MX replacement features yet?
This is what I see. FuseBoxMX is be a version of fusebox that incorporates CFC's. There will still be a core switch file and settings files. The CFC's will be called all over the application, but the logic will follow the same fundamentals as in FuseBox 3. The change will be how things are coded. Action (act_), Query (qry_), Display (dsp_) and other files will have the extended benefit for CFC's. The question is how to logically implement the CFC technology. Here is a few examples of where someone might (not should) use CFC's. * SES converter * Display / Layout Processors * Standard Database interfaces Example Action Circuit... --- OLD <cfcase value="updateAddress"> <cfinclude template="qry_updateAddress.cfm"> <cfinclude template="dsp_updateStatus.cfm"> </cfcase> --- Possible New (with some issues left out) <cfcase value="updateAddress"> <cfinvoke component="com.data.datAddress" method="update" returnVariable="dataResult"> <cfinclude template="dsp_updateStatus.cfm"> </cfcase> This is just a concept of how cfc's might be used... simplified and not functional for those who have not seen cfc's yet to look at. The switch file would still provide a logic controller. If you "decentralize" the switch file you will lose one of the greatest benefits of Fusebox! Now some fuseboxers would say... "Why would you build the database function into a component?". This allows you to access the component from FlashMX without the need for a page refresh. If you had a datastore that was working with affiliates... you could extend the data interface like this to your affiliates also... using the cfc. The code would be slightly different for FlashMX and the affiliate site... but the interface is now universal! (*Yes you would add security for those who are paranoid.) ...All that to say this... CFC's do not eliminate the benefits of FuseBox. CFC's add features and methods that FuseBox can take advantage of now. These extensions lend themself to interoperable services that reach beyond current networking capabilities. FuseBox is here... CFC's are here... one will not replace the other... it is just a question of how to make the mix work effectively! John Farrar John >>> [EMAIL PROTECTED] 05/22/02 05:47PM >>> > Don't you understand... that if you don't want to move the > standard to MX then you are dedicating resources to develop an > alternate way of doing what MX is ready to do... hmmm... maybe I > am wrong... but it seems like that is the case. <plug type="Shameless"> That was actually one of the main points of an article I wrote just the other day. You may find my experiences interesting. http://www.fulgen.com/content/developerscorner1.cfm </plug> Benjamin S. Rogers http://www.c4.net/ v.508.240.0051 f.508.240.0057 ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
