Hi,
I guess you are talking about the CodeIgniter video?
Thanks for the comment.
Stef
]]>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.
]]>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 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
]]>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.
]]>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.
]]>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 🙂
]]>