> <!--- com_foo.cfm --->
> <cfobject type="COM" class="MyClass.Foo" name="oFoo" action="CREATE">
> <!--- end com_foo.cfm --->
>
> OK. Well, that sure buys me a lot, doesn't it? Admittedly, you might reuse
> some of the methods and properties, but then again you might not. The point
> of using COM, in my opinion, is that it IS an encapsulation - I simply
> instantiate the object, then use it. I don't need to encapsulate the
> encapsulation!
>
You're totally right, it doesn't need it's own file. What if you put
the <cfobject> call right in your index.cfm file? Maybe that's
something Fusebox is missing. Actually, it does make perfect sense to
put it in the index file because a cfobject call is essentially like
making a <cfmodule> call except it's to a different platform.
i love it! SEE! if you had just brought this up a long time ago! haha
> We'll often place significant amounts within stored procedures. Now,
> according to Fusebox, we should then place the stored procedure calls within
> separate "qry_" or "act_" files. Of course, since all the real code is in
> the stored procedure, and we often call the stored procedure using CFQUERY
> (as we can then cache the recordset using CFQUERY's caching attributes),
> we'd have something like this:
>
> <!--- qry_foo.cfm --->
> <cfquery name="foo" datasource="bar"
> cachedwithin="#CreateTimeSpan(0,1,0,0)#">
> { call myspFoo(#mynumericparam#, '#mytextparam#') }
> </cfquery>
> <!--- end qry_foo.cfm --->
>
> Again, not a lot of reuse value. In fact, at this point, using Fusebox seems
> to me to be just another layer of abstraction I'd have to deal with.
>
ok.... here's why you still 'may' want to do this (you don't have to).
It's not about reusing the query file, it's about reusing the display
file.
If you separate the <cfquery> call named "foo" from the display code
(<cfoutput query="foo">) you can reuse that display code with a
different query that has the same name. For example:
<cfcase value="fuseaction1">
<!--- assume this query file returns a query named "foo"--->
<cfinclude template="qry_davesstoredprocedure">
<cfinclude template="dsp_listfoo.cfm">
</cfcase>
<cfcase value="fuseaction2">
<!--- assume this query file returns a query named "foo" --->
<cfinclude template="qry_druckersstoredprocedure">
<cfinclude template="dsp_listfoo.cfm">
</cfcase>
> There just isn't that much CFML code to organize! The amount of organizational
> structure in Fusebox seems to me to exceed the amount of algorithmic
> content.
>
sure, that makes sense. If you only have a couple lines of CFML, there
really is no need for an architecture. How many .cfm files do your
normal applications have? If there are more than 50, Fusebox is will
make a difference, if there are more than 200, LOOK OUT! Fusebox kicks
ass!
> Finally, I've never told anyone "don't use Fusebox". I've said that I don't
> think it's the best choice for everything, and that I don't use it. If you
> like it, go ahead and use it! But if you don't, don't use it just because
> "it's what everybody uses".
Of course you shouldn't use it because it's what everybody uses, but if
so many people think it makes sense, it shouldn't be ignored.
Fusebox will only work in every application if every developer
contributes to it. From this conversation you have just contributed
something no one hadn't thought of before. I'm going to go bring up
this topic of adding <cfobject> to the index.cfm file. Thanks baby.
Steve
------------------------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]
