[eluser]D_Williams[/eluser]
[quote author="Nick_MyShuitings" date="1283424190"]
[quote author="D_Williams" date="1283378764"]
Controllers: Again my goal for most of this is to leave report-specific code out of the "report engine" itself as much as possible and have pluggable reports. What I'm thinking about doing is sticking to having a "reports" folder and put it under application/reports. I would have a "reports" controller. The index function would quite literally be an index and output a list of all reports in the reports folder and display a link to another function under the reports controller, but I'm not sure where to go from here. I need to keep the ability to have my users be able to choose what to do with their reports (display in page, PDF, email, etc), so I can't just call a single controller function to display it in a page. Right about here is where my thought process starts getting muddy.[/quote]That still sounds like a monster of a hybrid. You could get it a lot cleaner if you dove fully into MVC. For example, you create the controller "Reporting.php". This has the index like you describe that is a list of the methods the controller contains. You have the method "report1". This method calls a model function which gets it the information it needs in a raw format like an array. This method also receives a parameter (or many such as fancy filters in the future to pass to the model so that the array you get back is different), this parameter is the view format to parse the array into. So your method consists of a model call, followed by an if statement that will throw that $data array into a different view file to be parsed out. The view files could hopefully be reused by more then one report at the least, if you made them dynamic enough in creating the tables etc.
Long story short doing it this way you actually start to see the benefits of MVC, such as modifying your model calls for pagination, or filters, and not having to modify the rest of the code. Adding a new report would consist of creating a new method, testing the models to make sure they work, hoping the final output is similar to an already exiting view, if not creating a new view file etc.[/quote]
My primary concern with this is that having the report logic for every report in one controller is going to make one monstrously large controller file. I guess that's acceptable but meh.
Also another hindrance of mine is finding a way to neatly handle the report config. Again I don't particularly want to have a view file for every report's configuration options but where else can I specify which reports need what fields for configuration?
The best thing I can think of is having a very PHP-heavy "report config" view file that takes a list of requested inputs in a data array, or maybe having a helper file to cut down on the amount of PHP in the view.
