Main Menu
 Login

Show your love!

Fusebox 3 vs. Fusebox 4

Posted on Sat 08 Jan 2005 (6496 reads)

Similarities and Differences from a Developer's Point of View

These are some notes I took while learning Fusebox 4 having already worked with Fusebox 3. I hope you find this information useful.

  • fbx_settings and fbx_switch and fbx_circuits have been "merged" into fusebox.xml and circuit.xml

    In FB3, every directory has its own fbx_Circuits file. In FB4, the main application directory needs only Fusebox.xml (and in the case of PHP, Fusebox.init.php). Circuit.xml has been disassociated, in some respects, from the application directory structure and in all respects from the web directory structure.

  • you program the application in XML using verbs such as INCLUDE, DO, and SET

    This is, in a way, something new in FB4. In FB3, program flow was determined by a combination of factors including the existence or not of fbx_Circuits. In FB4, this aspect of the site has been consolidated in the Fusebox.xml file.

    The definition of Circuits has also changed significantly. Circuits.xml is capable of much more than including files (functionality originally found in fbx_Switch). Now, with Circuit.xml you can also execute random sets of code (such as calling other fuseactions via the DO verb). The purpose for encapsulating such things as setting variables and including files is for portability accross languages: you can use the same Fusebox.xml and Circuit.xml files in a PHP, ASP, JSP, ColdFusion, etc. environment. You can almost say that Fusebox.xml and Circuit.xml constitute the DTD or Schema of your application (borrowing from XML terminology).

  • the XML grammar can be extended using plug-ins (instantiate, invoke)

    Because code contained in fbx_Settings and fbx_Switch has been encapsulated in Fusebox.xml, programming logic frequently found in fbx_Switch (such as security) needs to be recreated in the Fusebox XML vocabulary. Therefore, you may find your favorite statement or function missing. For this reason, the grammer can be extended via plug-ins. Here is a link to a custom Switch statement.

  • access to fuseactions can be restricted to calls by the user, the application, or the fuse

    I haven't fully grasped the value of this, but access to fuseactions can be "scoped" to access by the user, system, or the current fuse by setting the ACCESS attribute to one of "public", "internal" or "private". I assume that this increases application integrity but I don't have enough object oriented programming experience to be able to say exactly how this should be used.

  • a number of new framework variables have been added

    Ex.: the 'fuseaction' parameter can be customized to 'fa' or 'go' or whatever

  • program execution has been comlpetely decoupled from the directory structure
    • A single set of application files can be used for multiple instances of the application. This means that all versions of an installation can run off of the same code base. If you have an error in your application, you only need to fix it in one place!
    • sample 4.1 files are organize code in an MVC fashion, but developers are free to organize the code as they see fit, including in a fuse/fuseaction hierarchy.
Index :: Print
The comments are owned by the poster. We aren't responsible for their content.
TedMasterWeb.com Home Page TedMasterWeb.com Home Page TedMasterWeb.com Home Page