The main reason for routing it all through the same index.cfm file, is the
addition of services. If the call isn't dispatched using a single
index.cfm, then services such as Security and Caching cann't be added
transparently.
-Dave
>> -----Original Message-----
>> From: Steve Nelson [mailto:[EMAIL PROTECTED]]
>> Sent: 02 April 2001 15:18
>> To: Fusebox
>> Subject: Re: Fusebox-X Specification
>>
>>
>> I like some of the concepts in here...
>>
>> Although just like the nested circuits that Hal proposed...
>> I'm still
>> lost as to why everyone wants to add extra processing to
>> nest circuits
>> through a URL variable versus letting the web server deal with the
>> nested calls through the directories. Which of these is best?
>>
>> /directory1/directory2/directory3/index.cfm?fuseaction=whatever
>>
>> vs.
>>
>> /index.cfm?fuseaction=directory1.directory2.directory3.whatever
>>
>> vs.
>>
>> /index.cfm?circuit=directory1.directory2.directory3&fuseacti
>> on=whatever
>>
>> I just don't see what problem is being solved by doing this. We can
>> still use the #self# or #XBX.whatever# in each of the situations:
>>
>> <cfset self="/directory1/directory2/directory3/index.cfm">
>> <cfset xfa.somefuseaction="somefuseaction">
>> #self#?fuseaction=#xfa.somefuseaction#
>>
>> vs.
>>
>> <cfset self="/index.cfm">
>> <cfset
>> xfa.somefuseaction="directory1.directory2.directory3.somefus
>> eaction">
>> #self#?fuseaction=#xfa.somefuseaction#
>>
>> vs.
>>
>> <cfset self="/index.cfm">
>> <cfset xbx.somecircuit="/directory1/directory2/directory3/">
>> <cfset xfa.somefuseaction="somefuseaction">
>> #self#?circuit=#xbx.somecircuit#&fuseaction=#xfa.somefuseaction#
>>
>> I hate to say it but these all seem far too similar to me. The web
>> server already handles the nesting of directories. So
>> unless it solves
>> some grandiose problem which is unclear to me, why would we
>> want to give
>> this task to CF's slow string parsing functions?
>>
>> I like the idea of the #self#, although I think it should be an XBX
>> (eXitBoX) #xbx.somecircuit# similar to what you've got in
>> the Fusebox-X.
>> That still works well with unit testing and would allow for easily
>> connecting to outside sites.
>>
>> I think what you've really hit on with this Fusebox-X is
>> your idea of a
>> central control panel. That's a slick concept. Connect your control
>> panel with open source application independent community built
>> applications and THAT will dramatically improve everyone's
>> applications.
>>
>> Steve Nelson
>> You'll NEVER be smart enough, but keep trying!
>> http://www.secretagents.com/training
>> (804) 825-6093
>>
>> "Maddison, David" wrote:
>> >
>> > Over the past few months I've been studying XFB, and
>> trying to ascertain
>> > just why it makes development so much quicker. During my
>> studies I've come
>> > up with a framework that's based on XFB and EJB, I call
>> it Fusebox-X.
>> >
>> > At present it's only in a preview, state, i.e. bits of
>> code are missing, but
>> > the specifications, should show the general idea. Any
>> comments are welcome
>> > to me or the list. The spec can be found at
>> > http://www.wildfusion.com/fuseboxXdocs/index.htm, ignore
>> the comments about
>> > selected reviews. I've decided to open it up to all
>> fusebox developers,
>> > since it's based on a few ideas, (such as XFB), which
>> people generously gave
>> > out to the community.
>> >
>> > If I get enough of a response, I'm looking at making
>> Fusebox Studio
>> > Fusebox-X aware, making it even easier and quicker to build web
>> > applications.
>> >
>> > I look forward to your comments,
>> >
>> > << David Maddison >>
>> > wildfusion
>> >
>> > W: http://www.wildfusion.com
>> > E: [EMAIL PROTECTED]
>> > M: +44 (7747) 024455
>> > YahooIM: maddisondavid
>> >
>> >
>>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
