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 ==^================================================================
