Hi All- I'm the guy who posted this topic to the ASP Fusebox list. Alex brings up a good point here and I've been grappling with this for the last week. I have a boss and a couple coworkers who have been repeatedly asking me why we even need to use fusebox in .NET. To be honest, I had a hard time coming up with any more compelling arguments than, "You can all functions through index.aspx," or "better file and directory organization," or "more secure," (picture them with a blank stare, and me on a soapbox). The security thing is somewhat moot, since any VB code is compliled into a DLL, but I had to come to a realization: I'm addicted to fusebox.
After about 3 years of developing with fusebox, I find any other solutions/suggestions kludgey at best. So yes, .NET has all kinds of nifty controls and classes and other conventions for separating code from display. But it doesn't have elegant naming conventions, neat and tidy file/directory structures, or an easy way to call pages from a root circuit. If we didn't use fusebox, we would still end up having to create some sort of file/directory naming conventions of our own, and *some* sort of project-level framework so all of our developers could be on the same page, so why not just adapt one that we know works, and works very well? Which is precisly why I spent the last week trying to get a fusebox-ish framework to function in .NET! I finally got what I think is a relatively solid Fuzebox 2.0 one working last night, so there is hope. If I get the time, development will continue on an FB 3.0 one, which I had *very* partially working yesterday. Anyhow, back to Alex's original question: Is it a crutch? No. Does it make my life easier in the long run? Yes. Will it speed up our development time in the long run? Damn right. Especially when I get hit by a bus mid-project and another developer has to step in and take over my project. Fusebox is convenience and a much-needed order amongst all the chaos, and that's a good thing to have (the order, not the chaos). -Bret (feeling more long-winded than usual) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, May 20, 2002 5:44 PM To: [EMAIL PROTECTED] Subject: Is fusebox appropriate for other languages? This post was put on the asp_fusebox list and it made me really think harder about fusebox and how appropriate it is for other language platforms. Originally fusebox's strengths was that it would be used for other languages but clearly this is not being done actively. Now the question I have is this "Is fusebox really just a crutch for non-OOP scripting languages?" ----- Date: Fri, 17 May 2002 12:22:04 -0700 From: Bret Van Horn <[EMAIL PROTECTED]> Subject: .net progress, further thoughts, no answers Since I've sort of been under the gun to find a fuseboxish solution for .net, I hacked a lot on it this week and have a *VERY* rough fusebox 2 scheme working. I can pass a querystring variable of fuseaction, have it passed to a fusebox user control, along with some other global variables, then the fusebox control parses an fbx_switch.xml document to find the include file. I then took it a tiny bit further and had the fusebox user control do a webRequest to the include file and return the content, as Kevin had alluded to earlier this week. Works beautifully and actually quicker than I expected. However, I started to realize that I was running into a giant brick wall comprised of all the supporting code that would be needed to pass any additional variables and/or post data into the webrequested form, while still retaining state and doing all the other stuff that a fusebox 3 framework for .NET would need to do (nested circuits, etc.). Then I started thinking, which always gets me in trouble (not to mention, even more confused). Fusebox in itself, and from my impression -- so I could be wrong here -- is an attempt to make a largely non-object oriented language act like an object oriented language. If you dissect a circuit, it is basically a class at its core. It has properties and methods and those methods are called in a very object oriented way. Granted, fusebox has given us many other benefits, such as nested circuits, always calling the same template, rapid development, etc. .NET *IS* object oriented, from the ground up. So why are we trying to port a non-object oriented language's version of OOP to a language or framework that already is? Being that I'm quite new to OOP, I could be totally off-target here, but why couldn't we have a user control that grabs the fuseaction and any POST or additional GET data, and then based on the requested circuit and fuseaction, calls an appropriate method within the corresponding class? For example, say I click on a link that takes me to: http://www.workshed.com/index.aspx?fuseaction=users.add That could tell fusebox to call the add() method (fuse) within the user class (circuit). Now granted, this brings up many, many questions, such as: 1) How realistic and/or time consuming would it be for a .NET developer to create a class for each circuit and compile it in with the fusebox user control? (again, this is getting way outside my level of knowledge so I could be way off base) Or is it possible to have the classes compiled separately and then include/reference them in the user control at runtime? 2) Is it possible to perform a dynamic call to a class in VB or C#? Sort of like doing an Evaluate(fuseaction)? 3) Would it really be kludgey to not have the display files as part of the fusebox equation? How would web forms be dealt with in a model like this? And there are many more questions as well, but I need lunch and my brain hurts. Thoughts? Ideas? Am I just being silly an restating things that have already been said? Futile? -Bret ==^================================================================ 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 ==^================================================================
