Slow down John. Flaming doesn't help anything. Steve Nelson
John Farrar wrote: > > 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 ==^================================================================
