You're quite right that a fuseaction variable must be passed back to the fusebox. It can be a form variable (I've done apps without any URL variables because the client didn't like them.) But I think your objection isn't the URL var, per se, but the idea of sending a variable back and in that you're exactly right: one of the key FB ideas is that the app is not so much a collection of code files (though on one level, it is just that, of course) but rather a single entity that responds to messages and executes methods.
-----Original Message----- From: Jennifer Larkin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 2:49 AM To: CF-Talk Subject: RE: Fusebox (was: I like CFMX) To be honest, it's been quite some time since I've looked at the docs, so I can't say with conviction what the stance is on URL variables. However, it seems that the method requests that you refer to need to be passed in some way and that way usually seems to be through a URL variable. It *is* these variables that I dislike. In order for a user to link to a page in the site, the method must be in the URL (as opposed to a session, form, client or other variable). Otherwise, the default method would be selected and the user would not be linking to the part of the site that is expected. The user's bookmarks would be invalid and any links the user sends in email to his/her/its friends would also be invalid. Avoiding that requires that the method be in the URL. So you say that FuseBox is agnostic about the use of URL variables, but I don't understand how that could be true. It seems to require them, regardless of the format in which the variables appear. Obviously, you know more about FuseBox than I do, so please correct me if I am wrong about that. I dislike URL variables in general, although I think they do have a place. I certainly wouldn't want to build a catalog of 4000 products without them. I just think that telling a site what to do isn't the place for URL variables. I wouldn't even say that I stick to that as a rule, since I have built data-entry systems that use URL variables to determine whether a person is editing something or making something new. However, the requested functionality of the applications required that. As I've said before, I don't think that a single solution can solve every problem. The solution is dictated by the problem itself. At 02:23 AM 4/30/02 -0400, you wrote: >Jennifer, I'm unclear about the reference to URL vars, which Fusebox is >completely agnostic about. It does view the application as a single >entity that responds to different method requests, though. Those method >requests come to the fusebox as variables. Is that what you don't like? > >-----Original Message----- >From: Jennifer Larkin [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, April 30, 2002 1:50 AM >To: CF-Talk >Subject: Re: Fusebox (was: I like CFMX) > > >Lets assume that it teaches people incorrect definitions for standard >terminology. This is Matt's viewpoint. Since I am familiar with Matt, I >can tell you that the guy *does* know what he's talking about. He >doesn't always say it in the most understandable or helpful way, nor >does he explain things that he thinks you should already know, but he >knows what > >he's talking about. So for the sake of answering your question, let's >assume that none of us question the validity of that part of Matt's >stance. > >That does affect it's quality and may affect it's usefulness. You see, >when you learn the weird definition, you aren't able to communicate >effectively >with people who know the standard definition. If two people on the same >project are unable to communicate, that does affect productivity, making >it >less useful than it would be if it used the correct definitions. In this > >case, knowing the standard definitions might help you become a better >programmer, which means that you are being done a disservice by being >told the wrong definition. Again, it would therefore be more useful to >you if it >gave you the correct definition. > >It certainly doesn't change how FuseBox works, but that doesn't >preclude a change in usefulness. > >And about getting around the url variable problem. The way I described, >I don't have to get around the URL variable problem but I still get the >usefulness. Creating what I see as a problem and then solving it is not >as >good as not creating the problem in the first place. > >At 12:49 AM 4/30/02 -0400, you wrote: > >So whether some people call it a methodology, others a framework, > >others a standard, are you saying that changes it's > >usefulness? > > > >Steve > > > >Matt Liotta wrote: > > > > > Since I first saw Fusebox, its web site as well as some of its > > > proponents like Steve and Nat have termed it as among other > > > things, an architecture, an application framework, a methodology, > > > and more recently a standard. About the only term remotely related > > > to Fusebox > > > > is methodology. > > > > > > -Matt > > > > > > > -----Original Message----- > > > > From: Hal Helms [mailto:[EMAIL PROTECTED]] > > > > Sent: Monday, April 29, 2002 9:24 PM > > > > To: CF-Talk > > > > Subject: RE: Fusebox (was: I like CFMX) > > > > > > > > I certainly wouldn't want to do that any more than you would, > > > > Matt. > > > I'm > > > > not sure what you're referring to, though. > > > > > > > > -----Original Message----- > > > > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, April 30, 2002 12:16 AM > > > > To: CF-Talk > > > > Subject: RE: Fusebox (was: I like CFMX) > > > > > > > > > > > > Indeed, more power to you for helping people. But, do you have > > > > to use common programming terms incorrectly? Showing people > > > > techniques is one thing, but to show a technique and pass it off > > > > as something it is not, certainly isn't helpful the person or > > > > the community in general. > > > > > > > > -Matt > > > > > > > > > -----Original Message----- > > > > > From: Hal Helms [mailto:[EMAIL PROTECTED]] > > > > > Sent: Monday, April 29, 2002 9:12 PM > > > > > To: CF-Talk > > > > > Subject: RE: Fusebox (was: I like CFMX) > > > > > > > > > > I agree there's no formal specification, Dave. We're all > > > > > working > > > > > > developers and though people contribute enormously to > > > > > spreading > > > > Fusebox, > > > > > we haven't created a formal spec. That may come at some point, > > > > > but > > > > most > > > > > of our efforts are focused on helping people learn use Fusebox > > > > > to achieve successful software projects. > > > > > > > > > > In response to your question to Steve, Tim Heald asked us to > > > > > respond > > > > to > > > > > some Fusebox talk on the CF-List. I'm happy to try to help, > > > > > but I > > > know > > > > > > > > > that some folks have an animus against Fusebox that I can't > > > > > help > > > with. > > > > > > > > > In short, if I can offer info, I will but I respect your time > > > > > too > > > much > > > > > > > > > to waste it trying to convert you. Besides, my take on this is > > > > > that we're all in this together, Fuseboxers and non-Fuseboxers > > > > > alike. We share a common goal and a common love for creative > > > > > programming. A > > > lot > > > > of > > > > > people have found Fusebox helpful; some people don't. Let a > > > > > thousand flowers bloom, as the Chinese say. > > > > > > > > > > -----Original Message----- > > > > > From: Dave Watts [mailto:[EMAIL PROTECTED]] > > > > > Sent: Monday, April 29, 2002 11:54 PM > > > > > To: CF-Talk > > > > > Subject: RE: Fusebox (was: I like CFMX) > > > > > > > > > > > > > > > > > > There are two books coming out on Fusebox that should > > > > > > > > help > > > > > > > > > to alleviate the lack of available information on > > > > > > > > exactly what Fusebox is. John Quarto and I wrote one > > > > > > > > called "Discovering Fusebox 3" and Jeff Peters/Nat > > > > > > > > Papovich wrote > > > > > > > > > one for New > > > > Riders. > > > > > > > > That will help people who want to find out for > > > > > > > > themselves what Fusebox is all about. > > > > > > > > > > > > > > Well, hi, Hal! > > > > > > > > > > > > > > That's nice and all, but where's the definitive > > > > > > > specification? I don't have to shell out for that, do I? > > > > > > > It doesn't have to be stimulating reading, it just has to > > > > > > > be a specification. > > > > > > > > > > > > http://www.fusebox.org/index.cfm?fuseaction=learn.specificat > > > > > > io > > > > > > n > > > > > > > > > > > > CF and PHP are there, JSP is coming pretty soon. > > > > > > > > > > Well, hi to you too Steve! What did they do, ring the alarm > > > > > bell > > > > > > at fusebox.org? > > > > > > > > > > I went there, before posting the previous post, and there's > > > > > nothing there which is a specification. There are some > > > > > implementations, > > > > there's > > > > > some documentation, but no specification in the formal sense. > > > > > > > > > > Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ > > > > > voice: (202) 797-5496 > > > > > fax: (202) 797-5444 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
