You said you wanted to make it framework agnostic, why not do something that uses the concepts of a framework, but not the actual framework. Back when I was working at AT&T, due to their insanely paranoid server restrictions, we couldn't use the actual fusebox tags, so instead, we simulated fusebox. Instead of using the fusebox tags, we used if then else blocks to accomplish the task and kept the conventions used in fusebox like having separate files for queries, logic, and display elements. We even used the url conventions like fuseaction to determine what page we were executing. This gave us the benefits of using fusebox with its modularity and keeping the different operational layers separate, but it didn't require that fusebox was actually installed. It also introduces some good naming conventions that many people are already familiar with. This lends to the modular model and makes it easier plug items into the structure without breaking other parts.
Eric -----Original Message----- From: Kevin Pepperman [mailto:[email protected]] Sent: Wednesday, June 30, 2010 1:12 AM To: cf-talk Subject: Re: CF Shopping carts > > (a one CFC convention-based DI 'framework' in the spirit of FW/1). Yes, I like that idea a lot. FW/1 has inspired me in many ways, the most important thing it has taught me is that conventions, when they are fully understood in a framework-- is the best ways to build things. It is all too easy to fall into the trap of changing my own patterns, but if my app is all built with a standard naming/structure convention like FW/1 half the battle of complexity is already solved. cfpayment is on the list for sure-- that is also a major part of the puzzle solved. I know it may be hard to make a cart both simple, and fully loaded, but I do think that it can be done, as long as everything is built as highly specialized services and business objects-- Like Sean mentioned, a simple central DI service could in fact manage a cart, and frankly I don't feel any part of a cart is that complex that it could not be done as units. A lot of what we need for this has already been done 1000x over-- in CF and many other languages, so we do not really need to reinvent the cart-- we just need to model it with a consensus based standard so its not hard to use it. There are code bases in CF already that are way more complex than a cart/checkout system, so this should actually become better than any system available to CF. Content management-- CRM, POS, Bar-codes, Processing integrations (pic pack ship), database support etc.. all can be modular-- After all, the whole process is just TEXT-- from the customer adding to the cart, to processing the order-- it is all in fact just simple text. The most complicated middle-ware I have ever built even for stores with hundreds of thousands of products and customers all boiled down to getting 2 systems to talk to each other with some type of TEXT. CSV.. meet SQL XML... meet CSV.. EXCEL... meet XML 159,567 row-daily-inventory-comma-delimited-with-every-known-?-character-known-to-WO RD-along-with-commas-tabs,',",-,~,*,#- from 15 year old DOS based Legacy systems--- meet OSC Its all text man. -- /Kevin Pepperman "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." - Benjamin Franklin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334953 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
