Note to CodeIgniter nerds: please, no looping code in your views.
I was researching things ‘nerd’ on the Web today, and I found myself at the CodeIgniter website.
For those of you who may not know, CodeIgniter is an MVC PHP framework.
What is an MVC framework?
I won’t go into details here since we’ve covered MVC basics elsewhere. Let me just say though, that an MVC framework is a bunch of PHP code organized into a reusable structure/system designed to make building web applications easier.
MVC is short for:
– Model
– View
– Controller
The general idea is to keep code separated by it’s function.
For example:
Code used to talk to the database is contained in the ‘Model’ part of the code base. And the ‘view’ is the code (typically mostly HTML with some small bits of PHP mixed in) are basically the pages/views that people actually see … your basic web page.
… Don’t worry, I’m going somewhere with this.
I’m wondering about CodeIgniter’s decision to place PHP looping code in their views.
I had a few minutes to spare and so I watched their ‘Hello World’ video tutorial.
What caught my attention in this video was how the author was using PHP looping code in his ‘view’ template! This may not seem like a big deal to you, but consider these two points:
- The whole point of the ‘view’ in MVC is to keep as much PHP code out of the view templates as possible. For me, the main advantage of doing this is to keep your web designers from busting your PHP code.
- Looping code is the messiest PHP code you can possibly have in your pages … get it out of there!
… I remember back in 1996 (in my classic ASP days) where the biggest problem was trying to cleanly loop through recordsets in such a way so that web designers wouldn’t break the ASP code.
My own simple solution was to build the table rows in a page-widget helper object and then shoot back a simple string variable to the view. The web designer would then simply wrap the one line of PHP in a table tag:
<table> <?php echo $client_list; ?> </table> |
This way the web designer is free to style the table anyway they want, and it’s way harder for them to break the page.
–
I haven’t really looked much at CodeIgniter, but if this introduction video is representative of how they do things … I’m wondering: why?
Thanks,
Stefan Mischook
www.killerphp.com
www.killersites.com
Hopefully I don’t get crucified over this, but what you outlined above is my biggest beef with MVC frameworks in general. The concept that the View must have little to no (server-side) code in them is, I feel, an hopeless ideal. I’ve never been able to conform to that restriction and consistently have for loops and if-statements in the files that are analogous to Views.
Maybe that’s wrong of me, but the need for separation within the MVC framework has actually caused me more headaches in my years of programming than they’ve saved. I consistently try new frameworks that come out every now and again, but I’ve always found them to be too restrictive and the time spent conforming to the framework I could have been spending writing code and solving problems.
I feel like I’m missing something.
I sincerely disagree with your approach. Not only do you pollute the controller with logic that should not be there (if you do it at all, then at least do it in the model. It should not be there either, it should be in the view, but if not in the view… the model is better than the controller), you also put some HTML (tr and td tags) – this is markup – into a part of your application where it does not belong. So if the designer somehow decides something needs to be done about those tr or td tags (I don’t know, add an empty space somewhere, or th tags).
And looping code isn’t that hard anymore. There is no reason why the view shouldn’t contain looping code. As long as it doesn’t contain any complex logic anymore, just simple loops, there is no problem.
Hi David,
I understand your frustration .. believe me, I’ve been there too.
That said, I think the answer is found in light weight frameworks that solve 80% of the problems than some massive framework that tries to do everything.
In my own professional work as a Java web application developer I used my own framework which was very, very lightweight and so it was very flexible.
Stefan
Stefan,
I used to like keeping my model objects as simple as possible so that they could be reused in other projects.
.. For me, the controllers are the throwaway components in the MVC trinity.
As far as having table row and cell tags in the controller; I don’t see a problem since they are structural and the web designer should be using CSS to style and position any elements (include the td’s and the tr’s) on the page.
Stefan
Basically you are attacking the framework because designers shouldn’t be given the opportunity to mess around with the php code?
For me the views have to contain all the markup to enable the designer to finetune the details of the design. In your example if a designer wants to change the table to a list he has to ask you to change the tr’s and td’s to li’s. This is counter productive i think.
Your second point on why loops shouldn’t be in the view is because is produces messy code. In a loop you only echo the values of the array/object so the messy part would be that the designer is unaware of the array/object construction. Naming the parts according to their output and datatype is one step to make the contruction clear. Using list to extract values from a one dimensional array is another.
My rule of thumb is; is the designer codeblind go template engine, is the designer code aware write your views like your other code, in almost English and comment where needed.
“Basically you are attacking the framework because designers shouldn’t be given the opportunity to mess around with the php code?”
Not exactly:
I am saying that I think it is a bad idea to have looping code in your view pages because web designers WILL trip over it and break things.
… I’ve seen this over and over again.
“if a designer wants to change the table to a list he has to ask you to change the tr’s and td’s to li’s. This is counter productive i think.”
You could easily solve this by created a small widget lib that takes a recordset to build what ever page component you want:
$widget_builder->make_widget(recordset_name, TABLE_ROWS);
$widget_builder->make_widget(recordset_name, LIST_ITEMS);
That said, I can’t think of a case where data that would be presented in a table, would then be switched to a list.
” … so the messy part would be that the designer is unaware of the array/object construction.”
No, the messy part is that you have opening and closing php tags that the web designer and / or the software they use could screw up the php code block.
… Code weaving is fragile.
Stefan
As i wrote in my previous response if you don’t trust your designer use a template engine. I like to use phptal because it doesn’t mimic the php escaping and you can set up output examples.
The counter productivity is not the changing of the tags but the time you don’t spend on the project you are working on at that time. The few minutes it takes maybe futile but it disturbs your train of thought which makes you lose more than the time to make the changes.
Hiding tags in php backfires most of the times as far as my experience goes.
You criticize the framework for allowing PHP in the views (ok, I understand the point here – this is where a templating language helps reduce risk), then you go on to say you build a table in the controller. In my opinion, your solution is worse than using PHP loops in the view. If anything, building a table like that should take place in a helper or other assistive object. So much as the view is there to be the template, the controller is there to handle the requests and return back the format and status code requested.
Thoughts?
Maybe the issue is that I’m both programmer and designer. I’ve yet to work on a site with a team greater than three or four people and all of us were in the same office at the same time. The ability to simply speak to the people you were working with to clear up inconsistencies perhaps solved many of the problems that the MVC model was developed to solve.
Further, I’ve never worked with a “designer” as you seem to indicate above. The people who manage the content for my sites have always had access to the site using various CMS tools. Now, with CushyCMS making headlines, that becomes even easier! I guess I don’t see a reason to separate Views from controlling logic when the only people with access to that controlling logic are the programmers.
View = display logic. The idea is to separate display logic from business logic NOT removing programming logic.
Display sometimes needs loops! If a designer wants to change from a table to a list they shouldn’t have to call the developer.
A designer shouldn’t be required to have PHP expertise, but if a designer is going to work in the web world they will need some basic knowledge in some programming language even if its to read instructions that say “don’t touch the following lines”. I’d much rather have a programmer occasionally touch a view than a designer to ever touch a controller.
If your designers can’t follow the instruction: “Don’t touch anything inside the php blocks”, you should really be looking for new designers 😉
What happens if your designer realises that the data in one of the columns needs to be wrapped in a span so they can style it?
Keep view logic in your views, not in the controller!
note: I’m a CakePHP coder, but the rule still stands 😉
Controllers are for logic, views to visualize it . I think it’s easier to understand if you realize that view can be not only html but also pdf, json, csv, or anything. And logic should be processed in the way that enables to present data in any form you want in the view, and to switch any time. Besides, is it really so hard to learn simple if, foreach, etc for template makers?
Nate,
“If anything, building a table like that should take place in a helper or other assistive object.”
I agree.
I just reread what I wrote and it was a typo – I used what I called ‘page-widget’ objects in my framework to build the various page elements that were bound to dynamic data.
In the Java world, I would have this basic sequence of events:
1. Database object pulls the data and returns arrays.
2. The page widget object’s methods accept arrays of data to build things like table rows and list.
Note: I would not build entire tables; I would only build the rows so that the designer could wrap the collection of rows in a table formatted to their liking.
3. The invocation and the brokering of the two types of objects would occur in the controller.
I’m not saying this would be the best approach, but at least gets the looping code out of the views and is simple to understand and build. Again, for me, the controllers are the throw away objects.
This simple dumb object approach made for REAL reusable objects: in a short time I had a productive framework that made my contracting days very, very profitable since I was able to build things in like 10% the time!
… So I would charge 50 hrs on a job that would normally take 100 hrs (a deal for the client) but it really just took me 10 hrs because of my framework.
Stefan
David,
“I guess I don’t see a reason to separate Views from controlling logic when the only people with access to that controlling logic are the programmers.”
The problem is that designers are typically elbow deep in the views …
Stefan
‘View’ in MVC does not mean “just dumb HTML”. The view can contain display-logic and that means code, in one form or the other. Looping code, if it’s just looping through a set of displayable data, is perfectly in it’s place inside the View.
And PHP is an excellent language for scripting view-logic, that’s what it was originally made for. The View in MVC is not a sandbox for designers that can’t code. If you need such a sandbox, use a separate templating system, but the View != Templates. Views aren’t meant to be touched by non-developers, they are part of the code, part of the software.
Besides, any team still using technologically clueless designers to code their HTML output is living in the 90s, when web pages where just that, static pages. Front-end development is a profession, not something to be done on the side by pixel pushers.
Stuffing logic that only applies to the View, or even worse, construct HTML output, is probably the dumbest solution imaginable. It completely defeats the purpose of separating concerns. The Controller, nor the rest of the system, shouldn’t even be aware the output happens to be in HTML.
I work on a lot of websites where design is very important, which is one reason why I really disagree with this post. It’s actually necessary to allow the designer to modify ALL the HTML in many cases. Consider a detailed list (/) that is very common in today’s web pages ( are in many cases a thing of the past in standards-based CSS).
Product 1
Lorem ipsum
Dolor sit amet
Product 2
Lorem ipsum
Dolor sit amet
Product 3
Lorem ipsum
Dolor sit amet
Now do you want to render the HTML, IDs and class names for all that in the controller? As mentioned above, the point of MVC is to separate markup too. Markup goes in the view.
Consider that even if you did, the designer (and the Javascript developer) wouldn’t be able to add class names as required, and if they did, they’d have to go to you to change them. If you’re developing AJAX apps, you need the flexibility to add and remove IDs to use the content on the page.
In a heavily design-centric website, it’s just not realistic to provide pre-rendered HTML to the view, and I hate it when libraries or plugins do that – I always opt for an array of information that lets me control the HTML and therefore the structure and design as I need it.
Are PHP template tags really that bad?:
<img class=”thumbnail” src=”” />
And as for PHP templating languages like Smarty or Blitz – they are available, but when you really get down to it, they’re actually pretty much the same as PHP template tags. (You could even use the short form tags etc.)
EDIT: Oops, tags were removed in my first post.
I work on a lot of websites where design is very important, which is one reason why I really disagree with this post. It’s actually necessary to allow the designer to modify ALL the HTML in many cases. Consider a detailed list (<ul>/<ol>) that is very common in today’s web pages (<tables> are in many cases a thing of the past in standards-based CSS).
<ul id=”productList”>
<li>
<h4>Product 1</h4>
<img class=”thumbnail” src=”/images/product1_thumb.jpg” />
<div class=”description”>
<p>Lorem ipsum</p>
<p>Dolor sit amet</p>
</div>
</li>
<li>
<h4>Product 2</h4>
<img class=”thumbnail” src=”/images/product1_thumb.jpg” />
<div class=”description”>
<p>Lorem ipsum</p>
<p>Dolor sit amet</p>
</div>
</li>
<li class=”last”>
<h4>Product 3</h4>
<img class=”thumbnail” src=”/images/product1_thumb.jpg” />
<div class=”description”>
<p>Lorem ipsum</p>
<p>Dolor sit amet</p>
</div>
</li>
</ul>
Now do you want to render the HTML, IDs and class names for all that in the controller? As mentioned above, the point of MVC is to separate markup too. Markup goes in the view.
Consider that even if you did, the designer (and the Javascript developer) wouldn’t be able to add class names as required, and if they did, they’d have to go to you to change them. If you’re developing AJAX apps, you need the flexibility to add and remove IDs to use the content on the page.
In a heavily design-centric website, it’s just not realistic to provide pre-rendered HTML to the view, and I hate it when libraries or plugins do that – I always opt for an array of information that lets me control the HTML and therefore the structure and design as I need it.
Are PHP template tags really that bad?:
<?php foreach ($list as $item) : ?>
<li>
<h4><?php echo $item[‘name’]; ?></h4>
<img class=”thumbnail” src=”<?php $item[‘img’]; ?>” />
<div class=”description”>
<?php echo $item[‘desc’]; ?>
</div>
</li>
<?php endforeach; ?>
And as for PHP templating languages like Smarty or Blitz – they are available, but when you really get down to it, they’re actually pretty much the same as PHP template tags. (You could even use the short form tags <?=$item[‘name’]?> etc.)
Occasionally I see people write posts like this where their point is: “the view should not contain code”.
This is the wrong interpretation of the MVC paradigm.
“the view should contain only display logic” is a better interpretation.
A loop, e.g. to loop through a set of data, is perfectly fine in a view. Whether that’s done with a php loop (if you use php as a template language, which technically it is), or with a template engine loop (such as smarty’s).
View: display logic
model: business logic
Controlle: application logic
Hi Ivo,
My remark regarding whether you should have looping code in your view is an opinion based on practicality, not theoretical correctness.
As I said, when I’ve had looping fragments in my views, I’ve had web designers break it many times.
That said, you guys have made compelling arguments.
Stefan
“Now do you want to render the HTML, IDs and class names for all that in the controller?”
CSS (as I know you know) can be very specific without having to tag the elements directly with classes or IDs:
For example, you can wrap a dynamic widget in a tagged div container and then use CSS to target the child elements that are contained in the dynamic element. That has been my preference.
That said, this may come down to the way that you structure the development of your projects. When I find time, I will play around with CodeIgniter to see how the ‘other side’ thinks.
Thanks for the interesting responses.
Stefan
I use pure-php templates in CI, and I do looping all the time in it. Generally my controllers just deliver the data strictures to the view, and it’s up to the view to handle turning it into HTML. I sorta like the idea of putting as much presentation logic in the view as possible.
That being said, I rarely ever have a separate “web designer” work on the views, so that circumstance is a non-issue for me. It’s possible that I might need to alter my approach in a case like that.
Spelling is clearly not a strong suit of mine.
I can’t believe we still live in a world where developers expect designers to be going anywhere near any code whatsoever. The clue is in the name. They design. Not build.
Don’t get me wrong, it’s perfectly feasible for a designer to learn to program views. But the key is *views require programming, by a programmer*. In many cases the view logic can be by far the most esoteric and complex of an application (note, logic, not necessarily code itself, depending on the abstractions used).
A view is the underlying manifestation of a design, not the design itself – just as a well defined model is the manifestation of the real life objects it represents.
As explained in a previous comment, the MVC paradigm was designed to separate the logic of an application in to well defined categories. Show me one accepted definition of MVC where it states that code should not be used in a view. You wont find one.
Without such code, a view just becomes a static page and we may as well be using plain html – unless the code is moved somewhere else; this “somewhere else” however absolutely MUST still be in the view domain, otherwise you lose all the benefits of the MVC paradigm. In fact you’d likely be better off going back to the old page controller setup of yesteryear.
When it comes down to it, an ideal development team will have the expertise of a model programmer, a controller programmer, a view programmer and a designer. It may well be the case that one person can take on more than one of those roles, even all of them, however the skills must be aquired in each role to do so. The ideas brought forward by this blog post represent the wrong solution to the wrong problem.
PS. Apologies for the rant-esque nature of my post.. This is in no way derogatory towards anyone in particular. I just find this whole topic rather frustrating!
Totally agree with David Dashifen Kees.
—
The model contains all your application (business) logic including access to the database (which is hopefully provided by another (database access) object that exists within the model object)
—
I am the designer and the programmer and all my co-workers are designers and programmers too. CSS isn’t actually that hard. Even if you can’t “create” the concept you can easily take the concept from image to html+css yourself.
—
The ‘view’ portion and all this debate about where to put logic related to the visible output is what had me still using inlcude(‘header’) for so many years. If i’m supposed to show 1 of 3 possible sidebars and headers depending on the users $_SESSION[‘level’] where am I supposed to put that IF statement? It only makes sense to me to put it in the view. The same with looping.
—
It’s annoying to me to have to write a ‘page-widget’ object for every little building block of the layout and the associated html. If it’s just one quick if() to swich 1 sentence and loop out 4 anchors in the footer based on if you’re logged in or not, I don’t think that justifies a whole new widget object.
—
@Keith Jackson – Display ALWAYS needs loops. I have not had a single project where there wasn’t lots of looping all over the place. News categories, photo gallery images, paginated search results, related documents, select lists, all need looping through an array or result set.
—
We recently reviewed a couple of our sites and generated some html widget objects from the most common elements. The very next site we did, while using the same features that used those widgets, needed to look so completely different that the widgets were of no use to us. But since the controller was already giving the needed data to the widget I decided to make the widged return both the original data and it’s version of the html out put so that if need be we can simply loop through the original data in the view to do what we need instead of just echoing the widget’s default markup.
—
Also, totally agree with Rick.
As you are seeing, there are lots of different ways that PHP developers interpret MVC. It mostly boils down to either a Strong Model or a Weak Model. In a Strong Model system, the brains of the app (and most of the work gets done) inside the Model objects. In a Weak Model system, the Model is little more than a minimally intelligent shelf that manages the data. It can validate, it can get and store data, but the application’s decision making has to occur elsewhere, which usually means it’s mixed in with the Controller.
From what I’ve seen, the cleanest separation of responsibility (and the most flexible implementation) is a Strong Model, which has been brilliantly characterized by Bill Karwin, in a discussion thread on his own blog last week: “Ideally, the Controller should serve as a thin layer to pass application inputs to the Model classes, and then pass the Models to the Views.” This puts the smarts of the app into the Models, which are hopefully designed to be able to export that updated data into formats that can either be prepared for databases/repositories or formats that can be parsed easily by Views and ViewHelpers.
A Strong Model IS your application. It just executes instructions that have been parsed by the Controller/Request and it can relay its data (upon request) in formats both the database and the Views can use. To answer your issue, a View/ViewHelper should be smart and capable enough to render either string data or to parse arrays as necessary, but under no circumstances should either a Controller or a Model render HTML. The fun part is that there is no rule which says a Strong Model can’t know how to use a Weak Model for database interactions.
In an ideal world, of course.
HI Stefan
I am going deviate from the argument presented in this thread slightly. I have been learning and developing in PHP on/off for a few years and just recently strongly felt the need of framework. Hence the quest began and i came across your tutorials. Which by the way are the BEST so far and i would really like you to add more tutorials and probably some full fledge applications as that is the best way to teach someone (slightly spoon fed but hands on). Anyway i tested a few frameworks in the last few weeks namely Zend, Symfony, Cake, And CodeIgnitor. And I really find CI is the only one which is close to common sense and give you the tool kit (in other words a real framework). With the others it almost feels like you have to learn them first and then be able to do anything which defeats the whole purpose of a framework to start off with. Let me put simply from an every day life example. Task “Change the car tyre”. Now i know how to change it, I could pick up a manual tool (traditional approach) or an electric tool (framework) but then i should not have to sit there and teach myself how to use this electric tool for hours and hours before i could even get to lift my jack.
Moving on, i was wondering if you would look more into CI and put a few hands on tutorials on your site ?????
And in regards to the view issue really we are trying to separate salt from the flour !!!!!!
Emron,
I may get to it at some point but for now, I have a lot on my plate.
Interesting takes on using PHP in the view. First, I’d like to say that it’s very important that every bit of HTML that is needed for the page layout has to be available in the view. While many of us are probably doing the view on our own, or working closely with a designer, the view should dictate all elements of the page that a designer can change. Yes, you can get pretty granular by using CSS selectors, but the purpose of the view is to let the designer do whatever he wants. You provide the data and get out of the way. As developers it’s easy to forget that the UI is the most important part of your application. You could have the most beautiful, efficient code, but it doesn’t mean anything if the interface that uses your code is garbage. If you have the chance to work with a very good designer, let the designer do his thing, and don’t limit him by saying “just imagine it’s a table, the trs and tds will be there in the end and when you publish it everything will work”.
That is the whole point of the view, to allow the designer to take it and run with it by adding class names, ids, whatever, then be able to test that without having to publish it to a web server. This is very important: some designers will not be publishing to a testing server every 30 seconds to test a design. If they’re working in Dreamweaver or some other WYSIWYG app, a designer will get a rough idea of how the design is working. When I set up a view to use this loop:
this works in Dreamweaver. Yes, the actual data is not there yet, but the designer can see how the CSS is behaving (roughly) without having to publish to a server. Also, I’m using the template-style PHP syntax since that is more easily understood by the designer.
Better yet, using the standard Code Igniter parsing system, you can do this:
{things}
{things_t}
{/things}
Code Igniter takes care of the data structure, and the designer can see the {things_t} in the design to get an idea of where the final data will go. And this templating style is pretty easy for a designer to figure out what’s going on and what he should change and not change.
Long story short, give the designer everything he might ever need to update the design so you don’t get a call a year from now when they want to do a refresh. Your job is to make your data structure work, not tell the designer what to do.
1. How can your web designer modify the table appearance (for example, adding a caption)
2. You should read (or re-read) the PoEAA book : logic is allowed in the views, but PRESENTATION logic, and not BUSINESS logic
Conclusion : you wrote another useless post, which will help to confuse even more people who still doesn’t get MVC. For them, thank you…
goldoraf,
To answer your questions:
“How can your web designer modify the table appearance (for example, adding a caption)”
Easily since table appearance is controlled in the CSS and since the table tag itself is not generated in the PHP.
“You should read (or re-read) the PoEAA book : logic is allowed in the views, but PRESENTATION logic, and not BUSINESS logic”
I am not a dogmatic nerd, my opinion is based on my experience. My experience has shown if you logic in the views (business or presentation) web designers can easily bust it.
Conclusion – you are an angry nerd:
http://www.killerphp.com/articles/angry-self-righteous-tech-nerds/
If I have to prepare the whole stuff in the controller, then I can scrap the view altogether, and instead of loading view files, just print the html stuff directly from the controller to the browser… but then wasn’t it like the old days of php when you can put the whole thing in ONE script , yes, ONE piece of script :p db connection, queries, html tags, and molasses of if-else and case switches… and it still works as intended as an application.
I know i don’t make any point here , sorry… but here’s the thing :
Using template engine is no different with putting looping code of pure php. Template engine is just another layer of php logic which parses “designer friendly tags” into final presentation. The logic, is still very much the same. template engine tags also has loops, and conditionals, and also prone to be broken by designers. But then, in the case of designers breaking the code, I absolutely believe that when they do so, it’s a sign for me to get their replacement, heheh..
get code aware designer, it won’t hurt the budget that much. If you think that code illiterate designer worth maintaining, ie: they can create venus de milo of web design, keep them, but just switch the work flow.
Let them design their masterpiece, have them weave the html+css beautifully, then let the programmer pour in the necessary code. Works all the time for me, at very least.
I use CI for some time now, and after a dozen plus projects I still see no problem in the way CI’s view works. Lighten up, designers may break code, but coding in php and web is still fun because you can just refresh and see what is going wrong then fix it quickly. compare that to coding in J2ME, no designers, too many devices, programmer does breaking codes, and no nothing you can count on except System.out.println().
“Presentation logic in view is good, business logic in view, bad !! ” ( DHH of RoR, leader of opinionated, pragmatic software… huh ? opinionated what ??? )
I have to disagree with the main point of this post too. I have yet to work with a designer (which should be referred to as an HTML/CSS developer in this case) that couldn’t figure out how to work around and understand php and looping code in CodeIgniter views within about 15 minutes. If I have an HTML/CSS developer working on my HTML templates that can’t grasp what the few PHP tags mean in the super-clean CodeIgniter views then it’s time to find another developer that can
Well, this post has two sides.
On one side we have the MVC pattern which is there for a reason, and sure, we SHOULD remove as much code as possible from our Views. But I think loops aren’t that big of a deal because they only serve to DISPLAY the data.
On the other side, some people argue we should format the output in the Controller and only print it in Views. Sure, this is fine for a CMS, but it doesn’t really make much sense in a real world app which probably will never change it’s design.
We should always stick to the DRY principle, which goes in favor of the second approach. In CakePHP we could make a new method in the AppModel called (e.g.) “formatComments” which would format the look of comments of (e.g.) an article and then pass it as a variable to the View, but it is resource consuming.
I guess it’s all about how much time you have on your hands and what kind of project you’re working on. CMS sites should stick to DRY, others, well, it’s up to you 🙂
I use Codeigniter regularly and what I like about it is that I have the option to either cobble together an application in almost no time by adding some PHP direct into the view files, but when I am building a larger app or working with a front end programmer to handle the views I can use the parser class, and all code is removed from the view.
Add to that a set of custom libraries and models to do my dirty work, I end up with either a very clean app, an app that was built in no time, or an app that is both!
Flexibility is the best thing any framework can give a user, from the simplest CSS framework to the biggest MVC framework.
Hopefully I’m not too late – I had stumbled upon this discussion while searching for some MVC tuts.
Being a front-end dev/designer (html,css, javascript), I would have to agree with Mr.Murray, and disagree with the author.
You can’t limit designers by saying “this is the output, deal with it.” In a way, you’re practically saying that your way of doing front-end (your html output) is the be-all and end-all of it, and they should simply “beautify” your output.
That’s not the way things work, unfortunately.
Anyone with any extensive experience with CSS and Javascript, and all the ridiculous behaviors that the different browsers throw at you when you are building complex-designed websites, know that it would be a major time-eater to keep giving the PHP developer a call saying that the code’s output needs to be changed to XYZ.
It’s our job to do the front-end: UI, markup, presentation, behaviors, et al; and it’s your job to make things dynamic and manage the data. Most of us – the decent front-end people – can easily understand code. If your front-end people can’t, then it’s time you replaced them.
Honestly, It’s really that simple.
I’m not sure if anyone has commented on this subject, but I think this is pretty much a moot point mainly because CodeIgniter has helpers and libraries specifically for HTML generation, such as The Pagination Class, HTML Table Class, Form Helper, and HTML helper, just to name a few. CodeIgniter seems to have a lot of tools available for developers to generate portions of their HTML. I think if you are an HTML designer, you should have a general (if not excellent) understanding of the server side languages you are working in order to be able to make slight modifications if needed without breaking the whole thing (such as adding a class name or ID to something). As a developer, I also think it’s important that you keep things like this in mind as your developing and provide the designer a set of classes and IDs to help make styling the HTML much easier. If you give the designer 1 variable with an entire table of data inside, he’s going to come right back to you for changes or get you to put more code in the view. I think I too agree with a lot of the comments in that a lot of the code needs to go in the controller, but there’s still some that is OK to put in the view. IMO.
“I think if you are an HTML designer, you should have a general (if not excellent) understanding of the server side languages you are working in …”
I agree on this point 100%. That’s why I created Killerphp.com in the first place:
1. To promote PHP as basic skill in web design.
2. To make learning PHP easy for designer types.
Stefan
I have a bone to pick with this one…
My designers all easily understand the concept of a loop. Often times, for various reasons, they need to drop in an extra blank table cell in the middle of every row or toss in a checkbox for this one special thing or they in some other way need to add extra stuff to the table, including manipulating the individual rows.
To be honest, when we try and abstract things out like the author suggests, it’s just like so many here have already said – the designer will come back to you over and over again and ask you to change it. It’s not as simple as you make it out to be. CSS really does not always cut it, especially in a world that still includes IE 6. Maybe if people really do get their act together on some standards, and we get CSS3 and HTML5, and manna falls from the heavens, in a decade, perhaps, but there’s a reality that trumps anything the W3C might want to dream up in this regard. Honestly, even Safari can’t do everything in CSS yet. You simply cannot manipulate a table every which way without getting down to the row-level detail in the HTML – CSS only allows so much – not without nth-child accessors and the like, at least. Building helpers to get around this is needlessly overcomplicated and difficult to explain to designers when they generally easily understand the concept of foreach: endforeach;, and all understand basic HTML. I’m finding it difficult to imagine the designer who can’t get it, and have not had my designers “bust” my code anywhere near as frequently as you’ve suggested. Get SVN, and a deployment system… they shouldn’t be working on your production code anyway. If the site stops working, it’s almost never their fault.
I’ve just stumbled on this while looking for something else completely – but going back to the initial article:
I think the video you speak of is just to demonstrate how to create a basic page. It doesn’t actually use the MVC approach.
Next, if you don’t want PHP in your view (like me), then just use the parser class and keep all php away from your view.
“I think the video you speak of is just to demonstrate how to create a basic page. It doesn’t actually use the MVC approach.”
Hi,
I guess you are talking about the CodeIgniter video?
Thanks for the comment.
Stef