Firstly, I applaud your work in attempting to truly understand how OO works and how to apply it to CF. I just wanted to chime in and give you a few things to think about when you are trying to understand / build an MVC app.
I looked at the problem of building an MVC application and looked to Mach-ii, MG, and Fusebox as possible options. When I attempted to build my own MVC architecture one of the hurdles that I encountered was how the controller knew what it was supposed to do. I knew that it was to act as the 'traffic cop', but was really confused as to how IT knew what was currently happening. In my research I dug through the code of every MVC framework that I could find. The one thing that I saw repeated for all web based MVC patterns was that the framework acted as the controller. When you look at the existing OO frameworks, many of them use an XML config file to help 'wire' everything together and use an 'event' driven methodology to define when things happen. You define your model and tell the controller how each event affects the model and which views are used for display. The framework manages transforming all url and form variables into its internally used object (in Mach-ii this is the event object) to ensure your model / view do not need to know anything about scopes. In your original example of a user logging in, your userObject would be the model and accept arguments of username / password. Your view would have a form element that had inputs for both the username and password and when submitted would cause the controller to be invoked (usually event driven, eg. index.cfm?event=loginUser). This is where XML config files usually come in. Generally, you need to map an action to model components as well as what views to generate once the operation is complete. This all becomes significantly more complex when you begin to think about different logic paths that might need to be followed depending on the current request. For example in your scenario, what happens when the user login fails? What about if it succeeds? What if you want to add logging into the process? You could have the model generate new 'events' or have your components simply return success / failure response which your controller could then consume and dispatch other events. When I began looking at the previously mentioned frameworks as a controller to my application, I began to look more closely at the model portion of application. I highly suggest looking at the problem in slices when trying to 'get' OO. Once I focused my attention on modeling real world things in my application and focused less on the 'traffic cop' it made it much easier for me to see how each object should be constructed as well as relate to other objects in the system. This perceptual shift was a kind of spring board to me truly getting OO. Once I began designing components like this, I began to *see* the benefits of architectural patterns like DAO, Factory, etc. Once I saw the benefits of these patterns, I looked back at the frameworks and examined the controller layer and saw them applied there as well. That was when I could actually see *why* they had used them and what problems they solved. Good luck and I hope you enjoy the journey! HTH Rich Kroll ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Create robust enterprise, web RIAs. Upgrade & integrate Adobe Coldfusion MX7 with Flex 2 http://ad.doubleclick.net/clk;56760587;14748456;a?http://www.adobe.com/products/coldfusion/flex2/?sdid=LVNU Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:265485 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
