Hi Sam, One way or the other, the View needs all the relevant data to render a page. So it needs to have access to all that relevant data from the Model. I suppose the first step is making sure the Model has sufficient logic to gather only the required data. In a sense this logic represents the Report itself since the only thing the View should be doing to handling presentation logic (it shouldn't need to interpret or manipulate the data). Is a giant array bad? If it's all going to be displayed than probably not - again the Model should return only the required data, not everything and the kitchen sink ;). That will help keep the array size in memory to a minimum.
Getting the data into the View has two routes - from the Controller which seems likely if the Report is the main purpose of a request. Otherwise from a View Helper (or nested Controller) which access the Model directly. Either should be simple - the Model should be capable of returning data specifically for that report and the Controller/View Helper shouldn't have to do much more than call one or a few Model methods. Adding presentation logic is the last piece. If the report is not a reuseable element (used only for this specific request) then it's just a matter of using a foreach() loops. I would suggest having an HTML mockup of a sample report in advance so it's just a matter of sprinkling that with enough template code to insert the data as needed. Another few thoughts. Is the report likely to change often, or just a few times in a day? If it's static for some period of time it might be worth caching the View output so you're not generating it on every single request unnecessarily - just when the data changes. Model would need a modification check for the Cache logic to use in determining whether to server the cached View or allow a refreshed View to be generated and cached in turn. Finally, if the report is a long list of data pagination may also prove useful when viewing it online (presumably a printoff/export would still need to present everything up front though). P. Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Sam Davey <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, May 31, 2007 10:41:45 AM Subject: [fw-general] View Logic Like many developers a proportion of my time is spent creating reports based on database data. Sometimes if it is a very simple report which may never be reused I may even simply create a flat php page to get the data out to the user. I do this because I know I can knock it up in about 15 minutes and the job will be done. I have been following the development of the framework with great interest and I have learnt a lot about MVC and the obvious benefits seperating the logic from the presentation. So I just want a bit of advise regarding these typical day to day tasks. If I were to create a CMS system which creates numerous reports based on data in a database using the Framework and adhering to the MVC architecture, how should the data be transfered to the view? Should the model grab all of the data from a database and generate a large multi-dimensional array which basically mirrors the table to be displayed to the user? Then pass this data to the view (via controller) and create the HTML using somesort of 'for' loop. Does that qualify as not having logic in the view layer? What if you are working with a large amount of data. Is filling a massive array really the most efficent way of achieving this? -- View this message in context: http://www.nabble.com/View-Logic-tf3845561s16154.html#a10890623 Sent from the Zend Framework mailing list archive at Nabble.com. ____________________________________________________________________________________Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
