Difference between view() override in controller and view.php?
Permalink
In my continuing attempt to try and understand what I consider to be the incredibly confusing and complicated code underneath C5 I have a question :).
I have noticed that sometimes blocks define a public function called view() inside their controllers.
Which function apparently sets some things up for...well...the view.php file (i.e. the View).
What I am wondering is why would one want to use such a function inside the controller when it would seem more streamlined and less confusing to move the code in that view() function into view.php itself?
But alas...in trying that...it would seem that view.php does not have access to the same variables and objects inside itself that the controller does.
So my next question is what kind of calling hierearchy is there between controller.php, view.php, add.php, edit.php, db.xml, and the other files involved in a block?
I mean which one is called first? What is the order of these files being executed? Is there some kind of flow chart around here somewhere?
Any insight on the above from anyone would be appreciated.
One gentleman that I was reading today said this...
"The fact is that it is often the case that if you move certain functionality from the Controller to the "View", the end result will be simpler, more intuitive and a consirably better OO design. Now the "View" will have a much more active role, will have more functionality of its own (functionality which should be in the Controller in a strict MVC design), but the Controller will now be more manageable and more focused on its own role, rather than trying to manage a million different things, most of which don't really concern it.
In other words, the level of abstraction will now be better, with a simpler class design. Rather than have the Controller take care of everything, the tasks will now be better distributed: Tasks related to the view are now in the "View" class, away from the Controller class. The Controller class can now focus on its own core functionalities."
That seems to make sense given my as yet, limited knowledge and understanding of what is happening inside the C5 code.
Carlos
I have noticed that sometimes blocks define a public function called view() inside their controllers.
Which function apparently sets some things up for...well...the view.php file (i.e. the View).
What I am wondering is why would one want to use such a function inside the controller when it would seem more streamlined and less confusing to move the code in that view() function into view.php itself?
But alas...in trying that...it would seem that view.php does not have access to the same variables and objects inside itself that the controller does.
So my next question is what kind of calling hierearchy is there between controller.php, view.php, add.php, edit.php, db.xml, and the other files involved in a block?
I mean which one is called first? What is the order of these files being executed? Is there some kind of flow chart around here somewhere?
Any insight on the above from anyone would be appreciated.
One gentleman that I was reading today said this...
"The fact is that it is often the case that if you move certain functionality from the Controller to the "View", the end result will be simpler, more intuitive and a consirably better OO design. Now the "View" will have a much more active role, will have more functionality of its own (functionality which should be in the Controller in a strict MVC design), but the Controller will now be more manageable and more focused on its own role, rather than trying to manage a million different things, most of which don't really concern it.
In other words, the level of abstraction will now be better, with a simpler class design. Rather than have the Controller take care of everything, the tasks will now be better distributed: Tasks related to the view are now in the "View" class, away from the Controller class. The Controller class can now focus on its own core functionalities."
That seems to make sense given my as yet, limited knowledge and understanding of what is happening inside the C5 code.
Carlos
I think you had it in your quote- its better mvc if its in the controller. Concrete5 core sticks to a fairly strict mvc approach, and packages tend to do the same. So the view() in the controller often initializes variables (with $this->set()) that are gotten from a model or config. In terms of executing, the controller is the parent for all the files- it is called first to see if theres anything in the view(), edit(), add(), on_start() and many other functions or events a controller can have. The controller gets the data from the db.xml file and then can output that into the view, add, or edit files.
Thanks so much for your reply 12345j! Much appreciated.
The quote did say though that it would be better in many cases to move things from the controller into the view.php.
I am not trying to be picky about the concept but rather trying to wrap my head around how C5 does things so that I can better work with it (or adjust how it does things in my own blocks when it seems preferable to do it a different way).
So let's see...
Based on your input then...is the following correct?
- the controller of a block initializes variables to the values found in the block table based on the XML structure found in db.xml file. Those variables are then available to the code inside view.php and edit.php to allow them to do their respective tasks.
- when add.php is called and used it in turn passes the values from the form (the same form as used in view.php) into the block table through the controller which again uses the structure inside db.xml to know where to save it and what to save.
- when edit.php is called it too passes the values from it's form, through the controller, into the block table. Again using db.xml as the structure for the table.
- the form input elements inside edit.php must be named the same as the table fields defined inside db.xml
- the form input elements inside add.php must also be named the same as the table fields defined inside db.xml
Does that sound about right?
Anybody.
Carlos
The quote did say though that it would be better in many cases to move things from the controller into the view.php.
I am not trying to be picky about the concept but rather trying to wrap my head around how C5 does things so that I can better work with it (or adjust how it does things in my own blocks when it seems preferable to do it a different way).
So let's see...
Based on your input then...is the following correct?
- the controller of a block initializes variables to the values found in the block table based on the XML structure found in db.xml file. Those variables are then available to the code inside view.php and edit.php to allow them to do their respective tasks.
- when add.php is called and used it in turn passes the values from the form (the same form as used in view.php) into the block table through the controller which again uses the structure inside db.xml to know where to save it and what to save.
- when edit.php is called it too passes the values from it's form, through the controller, into the block table. Again using db.xml as the structure for the table.
- the form input elements inside edit.php must be named the same as the table fields defined inside db.xml
- the form input elements inside add.php must also be named the same as the table fields defined inside db.xml
Does that sound about right?
Anybody.
Carlos
just about- but the variables in the db.xml file are automatically initialized in the controller (you don't need to do anything.) but any additional values you generally do init in the controller.
If I may ask another follow up question 12345j...what do you mean by "any additional values you generally do init in the controller"?
Do you mean as in if there are any variables that you might want to use in the view.php or edit.php or add.php files?
Variables that you might not want to save in the block table?
Carlos
Do you mean as in if there are any variables that you might want to use in the view.php or edit.php or add.php files?
Variables that you might not want to save in the block table?
Carlos
yeah- like if you want to get data from another block you'd use a model to query the db and then use the controller to call the function.
Hmmm...I think...well...that one's a bit over my head 12345j.
I think I better leave it at that for now. I have enough to work with and am happy developing some additional blocks for a client. I think they are going to be blown away when I show them the blocks that I have developed for their site.
One block to add thumbnails and accompanying text to a Gallery of such thumbnails.
One block to add a FancyBox zooming image to a Photo Page (thanks to Jordan for the initial block which gave me the heads up on how to work with this...though mine is quite different).
Other blocks to add Text, and Page Title, and Camera Specs (all with their unique underlying CSS) to a Photo Page (kinda like Jordan's Designer Content block but again...quite different than his).
I will be adding yet another block to allow for integration of a PayPal shopping cart into each Photo Page.
C5 is actually becoming a lot of fun. Very impressive if I do say so myself.
Carlos
I think I better leave it at that for now. I have enough to work with and am happy developing some additional blocks for a client. I think they are going to be blown away when I show them the blocks that I have developed for their site.
One block to add thumbnails and accompanying text to a Gallery of such thumbnails.
One block to add a FancyBox zooming image to a Photo Page (thanks to Jordan for the initial block which gave me the heads up on how to work with this...though mine is quite different).
Other blocks to add Text, and Page Title, and Camera Specs (all with their unique underlying CSS) to a Photo Page (kinda like Jordan's Designer Content block but again...quite different than his).
I will be adding yet another block to allow for integration of a PayPal shopping cart into each Photo Page.
C5 is actually becoming a lot of fun. Very impressive if I do say so myself.
Carlos
Try and keep view.php to just displaying stuff that has already been worked out in the controller.
Then use the view() function in the controller to do any preparation (working out the stuff above)for the view.php. In most cases it is trivial, such as setting up data.
The idea is that if you want to present something differently, you can have a different view.php (or block/templates/different.php to use the C5 structure for additional views) that uses the same preparation in the view() function in the controller.
So your view() function in the controller could prepare a list of data, and then you can have different view.php (using block/templates) to display it as an ordered list or in a table.
Even if you only ever have one view of the data, if you keep such separation in mind you will usually be creating cleaner code.
Then use the view() function in the controller to do any preparation (working out the stuff above)for the view.php. In most cases it is trivial, such as setting up data.
The idea is that if you want to present something differently, you can have a different view.php (or block/templates/different.php to use the C5 structure for additional views) that uses the same preparation in the view() function in the controller.
So your view() function in the controller could prepare a list of data, and then you can have different view.php (using block/templates) to display it as an ordered list or in a table.
Even if you only ever have one view of the data, if you keep such separation in mind you will usually be creating cleaner code.
Excellent input again JohntheFish! Thanks again!
Carlos
Carlos
For anyone that is interested...I found an excellent if somewhat incomplete explanation of overriding Concrete5's save() function inside a block's controller and also somewhat of an explanation of how to use the view() function inside the controller as well.
It can be seen athttp://www.concrete5tutorials.com/index.php/block-tutorials/concret...
That is the kind of documentation that I am after finding but which is incredibly rare and hard to come by.
Carlos
It can be seen athttp://www.concrete5tutorials.com/index.php/block-tutorials/concret...
That is the kind of documentation that I am after finding but which is incredibly rare and hard to come by.
Carlos
Thanks for the link, it was so helpful in providing a flow along with clear explanations of how the files/functions work and why. Just what I've been looking for to fill the gaps.
