//Using count and $i I can go to $i+1 and $i-1 to do testing/lookups for special conditions (start, end, odd, even).

?>

I spent a lot of time looking at template engines, and started to come up with a version of my own with various placeholders and loop syntax. I still use it as part of our bulk mailing software, but do you know what I found? string manipulation in PHP is so unbearably slow - finding the TE code, parsing it to find a set of instructions, executing that then replacing the original block of code....page generation times were approaching a second. By using raw PHP and minimising string manipulation I get page generation times of 5 - 30 nanoseconds (down from 15-70 from before installing APC). And it is this speed which is much more important to me.

But let us distinguish between websites and web apps

I've been talking about web apps - for websites I use MODx - a content management framework with a fantastic template engine which doesn't require loops as part of the template code (php or otherwise) and turns MVC on its head by using the templates as controllers, making requests for data and then sending it off to another micro template for formatting (which in turn could request more data, and so on)

However, my framework isn't geared up for outputting HTML - it's geared up for outputting JSON, so $list woul be JSON encoded and client side JS can be used to render the output. At the moment I'm using ExtJS, so that has a simple template structure very similar to my PHP version.

As I mentioned before, for websites, i use the MODx content management framework, which has an amazing template engine, and would be implemented something like this:

Code:

[[!drawList?
&src=`list`
&tpl=`listTpl`
]]
<!-- this glosses over how the list data is sent to the drawList snippet, but it can be seen as a PHP array -->

The listTpl html chunk then has

Code:

<div>
[[+ns.name]]<br />
[[+ns.description]]
</div>
<!-- I've made up the ns. namespace juyst for example; exact usage would depend on how the developer had coded up PHP in drawList, which would just be a way of looping over the data and calling the template chunk for each iteration-->

.

So, I concede that template engines are good for websites but when someone starts talking 'frameworks' my mind goes into webapp mode - simply because I think there are plenty of good CMSs for websites where you wouldn't need a framework

I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

Smarty syntax is a lot less intrusive than constantly having to "<? ?>" in and out of PHP. It also simplifies array syntax.

And you can hand access to those files off to designers without worrying about them accessing the whole of the PHP language; what can be done in templates can be customized. And custom plugins can be created to give designers more capabilities, all the while keeping them in their controlled environment.

Simply take a heavily dynamic HTML page and compare the changes you have to make to embed PHP directly, or to embed Smarty. Smarty comes out looking a lot cleaner and more succinct.

//Using count and $i I can go to $i+1 and $i-1 to do testing/lookups for special conditions (start, end, odd, even).

?>

That to me isn't even a template. That's just a PHP controller with direct print commands. That's how I first began doing PHP (I was never a user of <? ?>), then I moved to putting all the output into a variable and printing once, then I moved to Smarty. That was probably 5+ years ago and I've never had cause to change again since.

I spent a lot of time looking at template engines, and started to come up with a version of my own with various placeholders and loop syntax. I still use it as part of our bulk mailing software, but do you know what I found? string manipulation in PHP is so unbearably slow - finding the TE code, parsing it to find a set of instructions, executing that then replacing the original block of code....page generation times were approaching a second. By using raw PHP and minimising string manipulation I get page generation times of 5 - 30 nanoseconds (down from 15-70 from before installing APC). And it is this speed which is much more important to me.

Agreed. That's why the first thing Smarty does is convert the template into a conventional PHP file with conventional syntax. It doesn't have to parse the template every time, but still gives you the benefit of a clean templating syntax.

I've been talking about web apps - for websites I use MODx - a content management framework with a fantastic template engine which doesn't require loops as part of the template code (php or otherwise) and turns MVC on its head by using the templates as controllers, making requests for data and then sending it off to another micro template for formatting (which in turn could request more data, and so on)

You can do that with Smarty if you really want to; you can have your controllers pass objects to the templates which can then be used to their fullest extent. And I took it to the extreme once, having the View making data requests directly from the Model.

The theory seemed sound: web designers--not the programmer--should have the authority over what's shown on what pages. The programmer's responsibility is to simply provide them the means to get the data.

But the template files got so convoluted with lower level logic that they were just difficult to read, so I backed away from that idea.

However, my framework isn't geared up for outputting HTML - it's geared up for outputting JSON, so $list woul be JSON encoded and client side JS can be used to render the output. At the moment I'm using ExtJS, so that has a simple template structure very similar to my PHP version.

My newest approach is to have different View-layer classes representing different output types, all of which extend the same base class. Before the controller is executed, higher-level logic injects the View class representing the desired output, the controller populates it with all possible output variables, then (depending on the class) it outputs JSON, HTML (Smarty), XML, or other formats.

So the same controller might be able to provide a full HTML page, as well as JSON--maximizing flexibility of the design.

You can also route to controller functionality from anywhere within the code. So one controller can pull the JSON output of another controller.

So, I concede that template engines are good for websites but when someone starts talking 'frameworks' my mind goes into webapp mode - simply because I think there are plenty of good CMSs for websites where you wouldn't need a framework

Strange distinction. If the site is governed by PHP controllers then I consider it a web application. A webSITE would just be a bunch of .html files and you'd have no need for templates at all. Oddly I haven't worked with a website of any notable size in... many years.

I've just recently gone from working with Zend Framework/Doctrine to Ruby and Rails. Interesting differences. Not necessarily better or worse but then it's not my nature to be a "fan" of any technology. It's a tool. I use it in the proper place and then use another tool where it works best. There are things about Ruby that make using pure Ruby for configuration as opposed to config files of other formats in frameworks like rails and active record easier than then they could be in PHP and a system like Doctrine.

in Ruby you can do

Code:

class company < ActiveRecord::Base
has_many :customer
end

and that alone can establish a join connection between two tables. In Doctrine config files and comments have to be parsed to establish a similar connection because that syntax isn't even possible in PHP.

If you want your code to be reusable as much as possible and reasonably well documented and servicable, you are going to end up using some kind of framework. If you code one every time you are wasting your time, but you don't have to use a publicly available framework either. Frameworks exist for a reason and just like CRM and CMS systems, if you offer something to the public, and you want it to be successful, it's inevitable that it can become something other than what you specifically prefer to work in, unless you heavily and ridgedly enforce every convention and api that it uses.

I can't think of an open source project, (framework or whole application) I have used in real work that I haven't had to heavily modify at one time or another because whoever developed the architecture didn't forsee the use I needed it for.

I fully agree with separating presentation from business logic but I don't see the point of things like smarty. It's just a set of pseudo code that gets turned into php anyway. I also disagree slightly with the separation of roles. My designers can't even code html so it's always the dev team who do the HTML anyway. Other places are different, I know that. We're a full service agency, so there's never a third party either.

I've seen a very wide mix of designers in my time. Some push the needle closer to photoshop, others closer to being programmers, others seem to have both skill sets. I have seen where a simpler template language can benefit, but so long as it's reasonably simple, most compitent designers have to have a subborn bias against coding to not get it.

If you want your code to be reusable as much as possible and reasonably well documented and servicable, you are going to end up using some kind of framework.

I've got to disagree with this. All you need for code reuse is good coding standards that are adhered to. A disciplined programmer can achieve that without a framework forcing them to. Providing a good level of documentation should be part of the expected standards, as well.

For instance, even if you use something like Zend, all your custom business logic is going to sit on TOP of it. Without proper coding standards you can still make an undocumented mess of code that'll lack reuseability and be a challenge to service. (I'm kind of dealing with some of that right now...)

I can't think of an open source project, (framework or whole application) I have used in real work that I haven't had to heavily modify at one time or another because whoever developed the architecture didn't forsee the use I needed it for.

Heh, same here. I lost count of how many open source CMS solutions I went through before giving up and writing my own. And if they were reliant on a beast of a framework like Zend, well... I probably wouldn't have even downloaded it. There's no bigger "I'm inflexible!" sign than that.

Originally Posted by Hammer65

I've seen a very wide mix of designers in my time. Some push the needle closer to photoshop, others closer to being programmers, others seem to have both skill sets. I have seen where a simpler template language can benefit, but so long as it's reasonably simple, most compitent designers have to have a subborn bias against coding to not get it.

I'm pretty decent in Photoshop when it comes to web design, so maybe that's why I expect more from professional web designers. I'd expect proficiency in HTML and CSS at least, and a good working knowledge of Javascript is a plus. Knowing Flash, too, would take them from a Jr. to a Sr. position.

If all they know is Photoshop then I wouldn't call them web designers. They're just digital artists; a much more limited role.

I've got to disagree with this. All you need for code reuse is good coding standards that are adhered to. A disciplined programmer can achieve that without a framework forcing them to. Providing a good level of documentation should be part of the expected standards, as well.

For instance, even if you use something like Zend, all your custom business logic is going to sit on TOP of it. Without proper coding standards you can still make an undocumented mess of code that'll lack reuseability and be a challenge to service. (I'm kind of dealing with some of that right now...)

Heh, same here. I lost count of how many open source CMS solutions I went through before giving up and writing my own. And if they were reliant on a beast of a framework like Zend, well... I probably wouldn't have even downloaded it. There's no bigger "I'm inflexible!" sign than that.

I'm pretty decent in Photoshop when it comes to web design, so maybe that's why I expect more from professional web designers. I'd expect proficiency in HTML and CSS at least, and a good working knowledge of Javascript is a plus. Knowing Flash, too, would take them from a Jr. to a Sr. position.

If all they know is Photoshop then I wouldn't call them web designers. They're just digital artists; a much more limited role.

I suppose it depends on what you call a framework. I would say even having a large library of classes and functions to build your application with could be considered a framework. MVC being one design pattern one can use to build an application . For instance .NET is considered a framework but it's not an MVC framework. It's a large API of foundation classes one can use to build an application.

I've certainly seen people make a mess of MVC before. so it is certainly possible. It is what you make of it and I've seen people make a mess with a circular saw with a laser guide on it too. I really think it's inevitable that if you offer software to others, you have to make an effort to allow them to do with it what they want to do. That leads to some people not liking your approach, so I don't blame the developer. Everybody has their way. If you can roll your own and be satisfied good. I've done that myself, but If I took my creation public, I suspect there would be people who hate it. Oh well. Works for me.

My prevsious employer used Zend and Doctrine. It was poorly documented just as the old system it replaced was becauses resources were not allocated to that effort. I didn't mind Zend that much, but the way THEY used it REALLY needed docs. Over time my specialty has become making sense of and troubleshooting messes yet that one was frsutrating. I find that some developers assume everyone thinks as they do, breaks up code into classes exactly the way they do, and they look at you like you are stupid if you don't get what they were thinking.

I suppose it depends on what you call a framework. I would say even having a large library of classes and functions to build your application with could be considered a framework.

Hmm, true. I think my definition has changed a bit since learning Zend and seeing how those sorts of things work. To me those really "frame" an application, determining behaviors all around the custom business logic you write. As such they also don't give you much room to go off into your own direction--you're surrounded by it. Every aspect of the application flow, from beginning to end, is handled by it.

I use to see large libraries, and even things like Smarty, to be frameworks, but now I see those as more of an option to hang off one side of your application. You're not surrounded by it. You can replace the with something else with minimal fuss. It determines a specific functionality, rather than the entire process flow.

I find that some developers assume everyone thinks as they do, breaks up code into classes exactly the way they do, and they look at you like you are stupid if you don't get what they were thinking.

True. It might have been after the fact, but that's why I recently went "Pattern Hunting" to figure out how to define my personal CMS app. Others might not agree with the Active Record pattern, but at least it might help mitigate any knee-jerk reaction to my code if I can at least tell them up front the principles behind it--relative to commonly known conventions.