We've had some interesting chatter on one of the local lists and I was wondering if anyone has any opinions on it. The site that is the topic is http://www.switch-box.org ... Haven't read to much on xfb yet, but this seems to be a similar evolution? Here is an excerpt from one of the emails: Interesting...minds thinking alike...but not the same. I read the document you suggested and looked at Mr. Helms's examples. The idea of classification and organization of information is as old as the human mind. It is how we understand ideas and hold on to them. It is intrinsic to our human nature. So the idea for boxes and nesting of boxes is a really great way for our minds to understand the problem paradigm. The use of the word box in Switch_box is really more coincidental to box in Blackbox or Fusebox than a variation. I have read, studied and used may different programming techniques and I can definitely say they all have influenced my thinking. (In SB, I did incorporate the Fusebox fom2urlattributes function as a matter of a normalization technique for of attribute handling. But FORM and URL data structures have REQUEST scope and are just as useful.) Switch_box introduced the notion of a message vector as means for directing program execution from a URL. It builds on the tradition dotted object syntax with two important distinctions; it is designed to be a HTTP attribute and the clear separation of a method name from the object name. The word vector is means direction and is calculated from coordinates. In the case of SB the axis for coordinates are the object list and the method list. This is illustrated by the picture at <http://www.switch-box.org/sbsite_box.cfm/?&mv=sbsite.details:shl.faq> on the Switch_box FAQ page. In traditional OO syntax, sometimes discerning the method from the object can be a guessing game and requires beforehand knowledge of objects and their methods. In SB, the objective was to make the separation clear and unambiguous. This is the reason for putting the colon between the object tree and method tree. In SB, the rule for a message vector is that any message without a colon is a method for the current box otherwise all message vectors must be properly formed with the object tree and method tree. Also, in the method axis SB allows for a compound method tree. This feature is necessary for handling predicate noun actions and it's economy in writing program code. With a message vector I also introduced the notion of a "switch operator" as a means to calculate the message direction path. Your example BooksByHal.Catalog.Adults.AffiliateInventory.Display would be BooksByHal.Catalog.Adults.AffiliateInventory:Display would read BooksByHal switch Catalog switch Adults switch AffiliateInventory switch Display. The cf_switchbox custom tag handles the message vector switch operators. If you prefer to use the attribute name fuseaction instead of mv, the cf_switchbox custom tag allows you to change the attribute name by changing the default to any value so you can code <cf_switchbox default="#attribute.fuseaction#"> without problem. In Mr. Helms document, he mentions the use of circuits.cfm to implement something like Switch_box already called symbolic message vectors (SMV). We also have a further extension to SMV called coded message vectors (CMV) that uses only simple query string e.g. handler.cfm?123yya7. In each case, the symbolic or code vector is converted to the full message vector by one of various lookup techniques like a database query, a hash table. On the www.switch-box.org site I used a cfselect in the root's local file. (The CMV documentation is not on the site yet.) I hope this explains how Switch_box approaches these techniques you are asking about. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
