As Waither mentioned you need to fatten your model. And make your controller thin.
You requested an object that represents your data. And the model is that object. It should return the data in an appropriate structure for your view. Any manipulation of that data should be done in the model. If you have a lot of conditional code in your controller modifying/ morphing the data you can almost bet that code is in the wrong place. Especially if your next thought is how do I reuse this controller function from another function. I think the biggest hurdle coming into cake from a non MVC background is getting your head wrapped around (M)odel. I believe the order of the acronym has some meaning (M)odel, (V)iew, (C)ontroller and that meaning is the importance and weight of the stack. Heavy on the model then the view with the controller as the lightest. The model represents our Application Data and is tied to the DB as our Storage Data but it is not a one to one field mapping of the table and sometimes isn't even tied to a db or table. Sure it most often starts that way as a baked model, but the model object is where most of your code should be that deals with transforming your Application Domain Data to and from the DB Storage Data. It is really the business logic of the data. It is the exact object you requested. The Model should know how to deal with the data and provide to the view exactly what it needs. You should not have to write additional code outside the model to adjust and tweak the data before it goes to the view. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en To unsubscribe, reply using "remove me" as the subject.
