Thanks for your reply. It's good to know that I'm on the right track. I guess part of what was tripping me up was wanting to have high-level Model functions when in actuality some of them belonged in the controller since they contained application flow logic/requirements. And I've also decided that returning a mixed data array with some kind of a status structure is the best way to go. I'm also in the process to implementing an event logger in my application to track errors, anomalous conditions, and possibly usage patterns.
It's also interesting that you mentioned your method for importing CSV data as an example as that's the exact problem I was working on when I wrote the original post. I haven't tried offloading data processing to a background task, but I may have to investigate that approach as some of my CSV spreadsheets can take quite a while to process as well (it's an intranet app, so I just increase the max script execution time). By the way, you wouldn't happen to have found a way to import .xls (Excel spreadsheet) data have you? My data sets (sales data from various distributors) almost always comes in the form of Excel xls spreadsheets or, occasionally, Excel html spreadsheets. The html spreadsheets are pretty easy to deal with since they're just HTML tables with some proprietary tags and attributes, but as yet I've found no way to process or automatically convert XLS data to something readable like CSV. On Jun 7, 9:06 am, LunarDraco <[email protected]> wrote: > I've been using fat model for a while now. It was difficult for me to > get over what now appear to insignificant problems but at the time > they looked huge. > > As the model's primary responsibility is to deal with data, I found it > useful to always return something more than a boolean. So most of my > model functions return a mixed data array. > Part of that result array is a status structure which I can then refer > to from the controller to display errors or redirect etc. This also > allows the model to process a set of data and return an iterative list > of errors. As an example I have a csv import which will process the > first 100 rows of an import. Each row has the potential of creating an > error, and the loop moves on to the next row. all these errors are > returned in a single result. The model then passes the file to a > background task to process the remainder of the rows. The controller > displays via the view to the user the results of the first 100 rows > along with the list of errors. I did this because some of these files > are huge and would timeout. I can process 100 rows fairly quick and > return control back to the user where they can see those newly > imported records along with any errors. > > A second reason for this process is the model code doesn't know if it > is being called by human interaction or via a cron script in either > case the errors are also written to a logger which the user can review > at any point in the app. > > In a previous post to this thread you mentioned you needed to redirect > in certain conditions. Don't get your business logic (model) confused > with your application flow (controller). A lighter controller doesn't > mean there isn't any logic in those functions it just means there is > less logic in them. Logic to control redirects definitely does belong > in the controller and your model needs to be able to give enough > information back to the controller to make those decisions. > > I've also found building test for the models is a lot easier than for > the controller. If your using test do your best to write the test > first. If your not using test, at least think in the mindset of the > model code being called from human interaction as well as from a > headless script. This will force you to deal with errors in a batch > mode instead of one off exceptions. > > Overall your on the right track your making your model fat and you > have identified the model is too deep for direct human interaction. I > think there are many ways to deal with this without breaking the MVC > pattern. > > My method explained above may seam too much for some, but having the > errors logged and being able to review them has helped in identifying > pieces of code which were in need of rework. A type of live profiling. > Not so much of the performance but more so on quality and intuitive > use or to identify poor assumptions on my part about the ability of my > users. 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
