sorry but what do we use view for again?
Permalink
can't seem to find data on the view files,
could you please give me a quick run down as to its uses.
thanks again
could you please give me a quick run down as to its uses.
thanks again
>>MVC framework
I was VERY VERY confused about this too. But having just read about MVC i can see what the confusion is:
There is plenty of V in your Cs.
(To anyone as confused as me about this. I am about to confuse you a bit more, but I promise to explain after it has been explained to me.)
So: the in the default theme the file named default.php has the following code:
and the view.php file has this:
the part
should mean: put the ENTIRE contents of deafult.php here.
The whole idea of MVC is to separate "programming" (C:controler) from display (V:view) (M is for Model and that is the database description roughly).
But here there is plenty of display (HTML) in the "C" making this confusing for a novice trying to figure out WHY all of this complication..why not just put everything in default.php and be done with it?
The benefits of this are only apparent in a team setting or when making changes. First, programmers can work independently of designers. Programmers can supply designers with a set of placeholders that will render final data (like a record set). Secondly, if your design changes, you can leave the programming part alone.
This was VERY confusing to me until I read up on MVC. But it is still a little confusing, because I don't think it is well implemented in the templates.
1. there should be a view.php for every controller (deafult.php, full.php, blog.php) As it is "view.php" is just a "wrapper" for the other files. (this is clever programming, if I ever get around to my own really simple CMS this is one thing I would steal, I just would not call it MVC)
This is further muddied by the use of seemingly redundant header and footer includes (in both the view and the other files). When the header could live happily in a SINGLE file in the view without the need for the include part.
Further.. apparently view.php is NOT REQUIRED...merly "encouraged" so the C% code check for it existence and but works fine without it..it is just not very MVC..but neither are C5's own template implementations..so it gets crazy for anyone new to this.
I was VERY VERY confused about this too. But having just read about MVC i can see what the confusion is:
There is plenty of V in your Cs.
(To anyone as confused as me about this. I am about to confuse you a bit more, but I promise to explain after it has been explained to me.)
So: the in the default theme the file named default.php has the following code:
<?php defined('C5_EXECUTE') or die("Access Denied."); $this->inc('elements/header.php'); ?> <div id="central"> <div id="sidebar"> <?php $as = new Area('Sidebar'); $as->display($c); ?> </div> <div id="body"> <?php $a = new Area('Main'); $a->display($c); ?>
Viewing 15 lines of 19 lines. View entire code block.
and the view.php file has this:
the part
print $innerContent;
should mean: put the ENTIRE contents of deafult.php here.
The whole idea of MVC is to separate "programming" (C:controler) from display (V:view) (M is for Model and that is the database description roughly).
But here there is plenty of display (HTML) in the "C" making this confusing for a novice trying to figure out WHY all of this complication..why not just put everything in default.php and be done with it?
The benefits of this are only apparent in a team setting or when making changes. First, programmers can work independently of designers. Programmers can supply designers with a set of placeholders that will render final data (like a record set). Secondly, if your design changes, you can leave the programming part alone.
This was VERY confusing to me until I read up on MVC. But it is still a little confusing, because I don't think it is well implemented in the templates.
1. there should be a view.php for every controller (deafult.php, full.php, blog.php) As it is "view.php" is just a "wrapper" for the other files. (this is clever programming, if I ever get around to my own really simple CMS this is one thing I would steal, I just would not call it MVC)
This is further muddied by the use of seemingly redundant header and footer includes (in both the view and the other files). When the header could live happily in a SINGLE file in the view without the need for the include part.
Further.. apparently view.php is NOT REQUIRED...merly "encouraged" so the C% code check for it existence and but works fine without it..it is just not very MVC..but neither are C5's own template implementations..so it gets crazy for anyone new to this.
Dogbot,
>> should mean: put the ENTIRE contents of deafult.php here.
Except that it can be either "default" or "right_sidebar" or whatever template within whatever theme you want to use. So the collection of block objects that have been attached to the template you are using are rendered within the view.php.
In your approach of "one view.php per controller.php" - how would you provide this amount of flexibility?
>> But here there is plenty of display (HTML) in the "C" making this confusing for a novice trying to figure out WHY all of this complication..why not just put everything in default.php and be done with it?
What is being display() "ed" is only when the page is in "edit" mode, where you can attach blocks to the area division. There are multiple view.php files. Some within the templates which call the page's collection to be rendered (as you've shown) and some within addon blocks which pull from the addon's controller. The reason for this is so that the C5 core can perform the same action on many files (marketplace blocks) so long as it knows the collection (page) id.
One day, when you write your own CMS, we will all be proud of you. In the meantime, please be careful when soliciting help from those who have written their own CMS - and provided it to you as open source code AND are here answering your questions with a helpful disposition.
Readers: Note the timestamps and logical progression of this thread.
My advice is beneath Mike (Minkras) and Andrew. Take whatever changes or corrections over my input. And have a great day!
>> should mean: put the ENTIRE contents of deafult.php here.
Except that it can be either "default" or "right_sidebar" or whatever template within whatever theme you want to use. So the collection of block objects that have been attached to the template you are using are rendered within the view.php.
In your approach of "one view.php per controller.php" - how would you provide this amount of flexibility?
>> But here there is plenty of display (HTML) in the "C" making this confusing for a novice trying to figure out WHY all of this complication..why not just put everything in default.php and be done with it?
What is being display() "ed" is only when the page is in "edit" mode, where you can attach blocks to the area division. There are multiple view.php files. Some within the templates which call the page's collection to be rendered (as you've shown) and some within addon blocks which pull from the addon's controller. The reason for this is so that the C5 core can perform the same action on many files (marketplace blocks) so long as it knows the collection (page) id.
One day, when you write your own CMS, we will all be proud of you. In the meantime, please be careful when soliciting help from those who have written their own CMS - and provided it to you as open source code AND are here answering your questions with a helpful disposition.
Readers: Note the timestamps and logical progression of this thread.
My advice is beneath Mike (Minkras) and Andrew. Take whatever changes or corrections over my input. And have a great day!
>> steal
meant as a compliment. I have nowhere near the technical ability to do much more than that anyway..so I wont.
meant as a compliment. I have nowhere near the technical ability to do much more than that anyway..so I wont.
>> In your approach of "one view.php per controller.php"
>> - how would you provide this amount of flexibility?
I assume the a controller should provide digested data..like all of the comments of a blog post, or all of the blog post forms set of parameters (this month)
and that the view would only provide formatting: css styles to format the comments and indent them, forms to add comments, etc.
again, controllers would handle the form inputs, and interact with the models to put the data in its places (the database, xml files, or even flat text files)
and then it would be back to the controller file above to interact with the Model to prepare the data and so on.
the flexibility would come in that any number of views could call upon this very abstract controller to view the same data in different ways. For example a well abstracted "blog-like" controller and Models...could be used as a news page, a calendar of events, a blog, a crm discussion or even a forum.
BUT I DIGRESSES.....
>> - how would you provide this amount of flexibility?
I assume the a controller should provide digested data..like all of the comments of a blog post, or all of the blog post forms set of parameters (this month)
and that the view would only provide formatting: css styles to format the comments and indent them, forms to add comments, etc.
again, controllers would handle the form inputs, and interact with the models to put the data in its places (the database, xml files, or even flat text files)
and then it would be back to the controller file above to interact with the Model to prepare the data and so on.
the flexibility would come in that any number of views could call upon this very abstract controller to view the same data in different ways. For example a well abstracted "blog-like" controller and Models...could be used as a news page, a calendar of events, a blog, a crm discussion or even a forum.
BUT I DIGRESSES.....
What you are suggesting is how it works already -- it's just that the terminology is confused to start with and only getting more confusing as this thread develops :)
Let's say your single page is called "signup_form". Your controller, where all of the application logic, form handling, etc. should be is here:
/controllers/signup_form.php
The "view" (as you are referring to it conceptually, where there is just a bunch of data that came from the controller and you are now outputting it with html) is here:
/single_pages/signup_form.php
The file in your theme that's called "view.php" is NOT the "view" in the MVC sense (I'm honestly not sure why it's called that -- it is very unfortunate, as we can all see). It's really more like a "layout" (as it would be called in Ruby on Rails) or a "design wrapper" -- its only purpose is to make ALL single pages look like the theme in question (because you could have a single page in your site and then change the active theme -- now the single page is still going to work, but the "design wrapper" it's in will look different).
Let's say your single page is called "signup_form". Your controller, where all of the application logic, form handling, etc. should be is here:
/controllers/signup_form.php
The "view" (as you are referring to it conceptually, where there is just a bunch of data that came from the controller and you are now outputting it with html) is here:
/single_pages/signup_form.php
The file in your theme that's called "view.php" is NOT the "view" in the MVC sense (I'm honestly not sure why it's called that -- it is very unfortunate, as we can all see). It's really more like a "layout" (as it would be called in Ruby on Rails) or a "design wrapper" -- its only purpose is to make ALL single pages look like the theme in question (because you could have a single page in your site and then change the active theme -- now the single page is still going to work, but the "design wrapper" it's in will look different).
finally this is making sense!!!
Hey dogbot,
Yes, unfortunately MVC is implemented in a very incomplete way in concrete5 -- and even if it were, people would not necessarily use it the right way (it's just a conceptual tool, you can use it or abuse it as you can anything else in programming).
The reason you don't put everything in default.php is because sometimes you are building a site that has several different page layout options. Like some of the pages have a sidebar and others don't. If everything used just default.php, then you would be forced to make every page on your site look exactly the same. If you look at Wordpress, it is much closer to this, actually -- and if you're building a blog where every page *is* the same layout, then this makes sense, but if you want a site that's a bit more complicated it really restricts your design.
1. There *is* a separate view for every controller -- it's the "single_page" (again, yes I know it's confusing terminology and not the most consistent -- large software systems like this don't get built all at once with perfect prescience -- they evolve over time so sometimes things evolve inconsistently -- it's just the way it is unfortunately).
The view.php file is just for making that view look more like the rest of your theme. But you don't have to utilize it that way at all -- you can just make your view.php file contain this one line: <?php print $innerContent; ?>
and then put all of the html/css for each single_page in the single_page file.
Similarly, the separate header and footer files are not a requirement -- just a standard practice. If you want to include the header and footer separately in every file, by all means, go ahead.
Finally, view.php *is* required -- but it's just required to exist as a file. It could, like I said before, just contain <?php print $innerContent; ?> and that's it.
Yes, unfortunately MVC is implemented in a very incomplete way in concrete5 -- and even if it were, people would not necessarily use it the right way (it's just a conceptual tool, you can use it or abuse it as you can anything else in programming).
The reason you don't put everything in default.php is because sometimes you are building a site that has several different page layout options. Like some of the pages have a sidebar and others don't. If everything used just default.php, then you would be forced to make every page on your site look exactly the same. If you look at Wordpress, it is much closer to this, actually -- and if you're building a blog where every page *is* the same layout, then this makes sense, but if you want a site that's a bit more complicated it really restricts your design.
1. There *is* a separate view for every controller -- it's the "single_page" (again, yes I know it's confusing terminology and not the most consistent -- large software systems like this don't get built all at once with perfect prescience -- they evolve over time so sometimes things evolve inconsistently -- it's just the way it is unfortunately).
The view.php file is just for making that view look more like the rest of your theme. But you don't have to utilize it that way at all -- you can just make your view.php file contain this one line: <?php print $innerContent; ?>
and then put all of the html/css for each single_page in the single_page file.
Similarly, the separate header and footer files are not a requirement -- just a standard practice. If you want to include the header and footer separately in every file, by all means, go ahead.
Finally, view.php *is* required -- but it's just required to exist as a file. It could, like I said before, just contain <?php print $innerContent; ?> and that's it.
>>Finally, view.php *is* required
From my own experience and to the absolute bafflement of other newbies in these forums ant statements like that..My sites work fine without it. but I understand. It is "required" in the same way you are "required" heed traffic lights when crossing a corner on a deserted road at 3am
From my own experience and to the absolute bafflement of other newbies in these forums ant statements like that..My sites work fine without it. but I understand. It is "required" in the same way you are "required" heed traffic lights when crossing a corner on a deserted road at 3am
A clarification, then:
1. To get a theme approved in our marketplace, view.php is required.
2. If you try and install any complex add-on that creates single pages in your site that aren't in the dashboard (eCommerce, Discussion Forums, etc...), that functionality will not work without view.php.
3. If you try and use built-in functionality like the blog in 5.4.1 in a theme without view.php, that functionality will not work.
To load a site that has no single pages in the site, or page types with their own page type template (that is loaded from outside the theme), then no, view.php is not required.
1. To get a theme approved in our marketplace, view.php is required.
2. If you try and install any complex add-on that creates single pages in your site that aren't in the dashboard (eCommerce, Discussion Forums, etc...), that functionality will not work without view.php.
3. If you try and use built-in functionality like the blog in 5.4.1 in a theme without view.php, that functionality will not work.
To load a site that has no single pages in the site, or page types with their own page type template (that is loaded from outside the theme), then no, view.php is not required.
No, It is required in the sense that if you don't have it, you will get errors if you have any single_pages in your site or if you want to customize the look of any of the system single_pages (such as 404 error not found, login, registration, etc.).
Remember this thread:
http://www.concrete5.org/community/forums/customizing_c5/instructio...
That's how it all started -- because someone didn't have the view.php file and was getting errors.
Remember this thread:
http://www.concrete5.org/community/forums/customizing_c5/instructio...
That's how it all started -- because someone didn't have the view.php file and was getting errors.
AWWW..right! LOL!
...so that is the answer to carlos...it worked before because he did not have any single_pages!
This is SO enligtening. I am glad I pursued this because that is exactly what I was going to try to do next (404 page) and I would have been scratching my head an making even worse snide remarks all over the forum. I need to place another order for chill-pills if I am going to get my first C5 implementation going with out making life-long enemies here. ;-)
Jordan, you are one patient fella. thanks.
...so that is the answer to carlos...it worked before because he did not have any single_pages!
This is SO enligtening. I am glad I pursued this because that is exactly what I was going to try to do next (404 page) and I would have been scratching my head an making even worse snide remarks all over the forum. I need to place another order for chill-pills if I am going to get my first C5 implementation going with out making life-long enemies here. ;-)
Jordan, you are one patient fella. thanks.
Plus, if your single page has a unique filename, you can copy that filename into your theme and it'll use that template instead, and not wrap it in view.php at all.
e.g. Make the file "signup_form.php" in your theme and you have complete design control over all aspects of it.
(Sorry, just felt like dropping another bomb in this thread ;-) )
e.g. Make the file "signup_form.php" in your theme and you have complete design control over all aspects of it.
(Sorry, just felt like dropping another bomb in this thread ;-) )
What?..wow...handy.
So I just make another file named exactly as my page but in the root of the theme folder?
do I add inside of it?
So I just make another file named exactly as my page but in the root of the theme folder?
do I add
print $innerContent;
No - at that point the entire file will be included as is. So you'd need to put everything from <html> to </html>. That could also include the header or footer like our page type templates to.
This is just another method by which you can override the view.php for specific single pages (by copying them into the theme.)
This is just another method by which you can override the view.php for specific single pages (by copying them into the theme.)
I never knew that. (You must like indiscriminate bombing.) (-:
i think he's talking about view.php in a theme, perhaps?
certain add-ons need it for interface pages like checkout.
certain add-ons need it for interface pages like checkout.
I am thankyou, the view.php found in a template I'm using appears to be similar but with differences to the default.php.
I just wondered why we need it. I understand the css files as per normal but the view file, well I'm sure it's something to do with output of the content in the editable areas.
Thanks again for everyone's help
I just wondered why we need it. I understand the css files as per normal but the view file, well I'm sure it's something to do with output of the content in the editable areas.
Thanks again for everyone's help
It's to show the contents of a single page (as opposed to a page type.) Single pages are pages that only exist in one spot in the system, such as dashboard pages, or pages added by third party add-ons. In order for the content of these pages to be shown using your theme, the theme needs to include a view.php file. The inner_contents refers to the entire contents of whatever single page view.php is showing.
It is also used when a package includes a page type, such as a blog post - in this case you can have multiple pages using the view.php to output the page content, but again, the entire contents of that particular page type (as coded in the package) will be output. If you would like to _NOT_ use view.php for these kinds of pages, you can copy default.php in your theme and rename it to match the handle of your page type. Concrete will use the newly created file to render the output of your page. It's up to you to make sure that any custom code from the package's page type is included in your theme's page type at that point.
I'm sure that probably doesn't make a whole lot of sense if you're just starting out with programming, but that's how the pages work.
It is also used when a package includes a page type, such as a blog post - in this case you can have multiple pages using the view.php to output the page content, but again, the entire contents of that particular page type (as coded in the package) will be output. If you would like to _NOT_ use view.php for these kinds of pages, you can copy default.php in your theme and rename it to match the handle of your page type. Concrete will use the newly created file to render the output of your page. It's up to you to make sure that any custom code from the package's page type is included in your theme's page type at that point.
I'm sure that probably doesn't make a whole lot of sense if you're just starting out with programming, but that's how the pages work.
Model - View - Controller
The Controller can pull data from the model
The Controller does all the proccessing,
The view pulls the generated data from the controller and displays it in the way you want