templated if's

[dagfinn]

You can put presentational logic in viewhelpers. If you put it in the template, where's the distinction between template-view and serverpage ?

I think there's a minimum of logic that needs to be available in a template language.
You need basic looping and a basic conditional construct. That's all, the rest can be in a view helper. Do you disagree with that? If you do, how would you handle conditional HTML?

[kyberfabrikken]

I think there's a minimum of logic that needs to be available in a template language.
You need basic looping and a basic conditional construct. That's all, the rest can be in a view helper. Do you disagree with that? If you do, how would you handle conditional HTML?

Well - I'm being a bit of a devils advocate here, since I agree that it's putting things on the extreme. However, conditionals can easily be handled from outside the template, as I already demonstrated in post #6 (If I need to elaborate, say so).

As with every arcitechtural choice, separating presentational logic from the view is a complication, and thus has a cost. If you don't need it, it will be baggage. The benifit of separating them is a higher degree of decoupling. In this case, one concrete benifit is, that the template-programmer needn't know how to write presentational code. Eg. the HTML-dude doesn't need to touch the PHP.

I haven't really got the time to get academical, but Fowler has a nice article about separating the presentational logic from the view. It's mostly concerned with traditional GUI's, but I suppose the conclusions could be projected onto a web-application.

[Ren]

There is also the WACT method of having logic within the template

http://www.phpwact.org/tag/core/default, thou again WYSIWYG editors probably would not like it.

[33degrees]

Well - I'm being a bit of a devils advocate here, since I agree that it's putting things on the extreme. However, conditionals can easily be handled from outside the template, as I already demonstrated in post #6 (If I need to elaborate, say so).

That's not a bad approach, although I'd say an improvement would be to use <div>s with id's instead of <block>, so that the template is 100% valid html.

As with every architectural choice, separating presentational logic from the view is a complication, and thus has a cost. If you don't need it, it will be baggage. The benifit of separating them is a higher degree of decoupling. In this case, one concrete benifit is, that the template-programmer needn't know how to write presentational code. Eg. the HTML-dude doesn't need to touch the PHP.

I don't think it's a huge benefit, especially when you need to do something extremely simple, like showing negative numbers in red. And if the HTML-dude decides that this number needs to be in red, he's either going to have to dig through the PHP, or bug a programmer to do it for him.

The cost of seperating the two is that you now have logic without any context; you'll need to have both files open to make any meaningful changes to either. And since they're highly dependant on each other, you're not really promoting reuse. So this is an area where I don't think the benefits are worth it.

I haven't really got the time to get academical, but Fowler has a nice article about separating the presentational logic from the view. It's mostly concerned with traditional GUI's, but I suppose the conclusions could be projected onto a web-application.

Traditional GUIs and web applications are very different beasts... the issue in traditional GUIS is that it's very easy to mix the View and Controller layers, since it's your view elements that capture user input. This differs quite a bit from the web model, where your input comes from a single point of entry.

I think most of the people arguing that the template should have no logic at all are doing so because it can be a slippery slope, which leads to things like Smarty, basically providing all of php to the templates. In other words, that it's hard to maintain MVC seperation once you start allowing logic in the templates themselves. But it is possible provide useful amount of logic without breaking the seperation; you might want to have a look at this article http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf , which explains a very powerful templating system that provides just that.

[dreamscape]

The benifit of separating them is a higher degree of decoupling.

Actually I think you are wrong on this one. I mean, you can do templates how you want, but I think you're misleading yourself if you think removing simple presentational logic from the templates produces a higher degree of decoupling.

Let's think rationally about it. When presentational logic is allowed in the templates, then the only connection between the controller and the view is the data for the template, ie, the template variables.

If you move presentation logic into the controller, now your view is tied into the controller on the data AND the presentation logic... how exactly does that qualify as a higher degree of decoupling?

I'm assuming you have the presentation logic in the controller, which I think is what you said earlier, but I don't exactly recall

[dagfinn]

However, conditionals can easily be handled from outside the template, as I already demonstrated in post #6 (If I need to elaborate, say so).

You're right, I missed that. But it seems to me that from the template designer's point of view there isn't much of a difference. It basically looks the same except it's called "block" instead of "if".

[devosc]

<block id="is5">
A is equal to 5 
</block>

<!-- If foo = 1 -->
  <p>Foo is 1</p>
<!-- EndIf foo -->

So they're both doing the same thing on a primitive type ? How or where was that value defined.

So if I create a value object of some kind from db data, this object is directly related to that of its source...

But then in when it comes to displaying page dependent of the nature of this objects properties... where does the above singular value get defined, most likely some kind of helper (if not in the controller ?) all that just because one would have two write a template language to handle

 <?php
   if (in_array($tpl['obj']->getType(), array('a', 'b', 'c'))) {
     ?>
         <span>hey</span>
     <?php
   }
 ?>

[Ren]

I like the idea of using a state machine for controllers, and using the final state of the controller for picking the which part of the template to use. So a form controller could have final states of new, invalid, and accepted, and 3 or less subtemplates for it.

Still would need some method of presentation logic tho, for this like alternating row colours on tables.

[kyberfabrikken]

You're right, I missed that. But it seems to me that from the template designer's point of view there isn't much of a difference. It basically looks the same except it's called "block" instead of "if".

The result is the same, but I'd say that there is a conceptual difference between the two, in that the "block" way is passive, while the "if" way is active. It boils down to imperative vs. declarative.

I think most of the people arguing that the template should have no logic at all are doing so because it can be a slippery slope, which leads to things like Smarty, basically providing all of php to the templates.

That's dead on. As long as the "logic" is purely dealing with presentational details, such as the color of negative numbers it's fine. But it's very easy to overstep it and begin to put application logic in there too. If the logic alters the application's behaviour, then I don't think the template is the proper place for it.

Perhaps as a rule of thumb we could say that choosing whether to show something or not should be decided from the controller, while choosing how to show something should be decided by the template.

To stay with the negative numbers, this is fine :

You balance is :
<if condition="$balance < 0">
<span style="color:red">$balance</span>
<else>
$balance
</endif>

While this is problematic :

You balance is :
<if condition="$balance < 0">
<span style="color:red">$balance</span>
<p>Your account is overdrawn, please insert some money.</p>
<else>
$balance
</endif>

It's a very fine line though, and certainly an unexperienced programmer (such as the aforementioned HTML-dude) will get it wrong. By removing logic all together from the template, you effectively enforce the separation. You can then provide viewhelpers in form of customtags to deal with the formatting-"logic".

I don't think it's a huge benefit, especially when you need to do something extremely simple (...) the HTML-dude is either going to have to dig through the PHP, or bug a programmer to do it for him.

That entirely depends on your audience. If you want you HTML-dude to only mess with HTML, then there are limitations to what he can do. On the other hand, he doesn't need to learn any programming-stuff either.

It may be an un-supported claim, but I think that thoose HTML-dudes will prefer custom tags, which hides the implementational details, over in-template logic.

[Dr Livingston]

which hides the implementational details, over in-template logic.

That is also benifitial to WYSIWYG editors, in that those tokens are displayed much like the rest of the HTML markup; Web designers should not concern themselves with application logic

[arborint]

Perhaps as a rule of thumb we could say that choosing whether to show something or not should be decided from the controller, while choosing how to show something should be decided by the template.

I don't think I agree with this, not your negative number example. The problem I have with HTML TemplateView is that the Template is -- in essence -- another Model for the View. By that I mean that the template provides much of the same kind of data as the "conventional" Model does -- which is text of one kind or another. Sure there is "formatting" in the HTML, but there are a lot of text and numbers as well.

You example of not having the text of the error message in the template is a good one. I think moving error message text to the Controller is a bad thing. It does not belong there and just adds one more place you have to make changes to presentation.

Regarding the Controller, I think a good rule of thumb would be that you should be able to make most (and even large) changes to the content of the presentation, whether contained in the View or Model, without having to touch the Controller.

[dagfinn]

To stay with the negative numbers, this is fine :

You balance is :
<if condition="$balance < 0">
<span style="color:red">$balance</span>
<else>
$balance
</endif>

While this is problematic :

You balance is :
<if condition="$balance < 0">
<span style="color:red">$balance</span>
<p>Your account is overdrawn, please insert some money.</p>
<else>
$balance
</endif>

I would do something like this:

$numberclass = ($balance >= 0 ) ? 'positive' : 'negative'; 

<span class="$numberclass">$balance</span>

CSS:

.negative { color: red }

[arborint]

I would do something like this:

<span class="$numberclass">$balance</span>

I try stay away from fancy tricks like that if I possibly can. The main reason is that designers really can't easily build something like that because <span class="$numberclass"> cannot be displayed. I'd prefer to have as much valid HTML in the templates as I can and let the designers create each variation in a way that can be displayed and visually approved.

The problematic part of kyberfabrikken's code was this:

<p>Your account is overdrawn, please insert some money.</p>

I would rather keep that text/HTML in the template because that text is just presentation data that can change a lot depending on the whims of the designer. As soon as you put that error message into the View code (or worse the Controller) you have split-up the content. And what's worse is that now you (the programmer) are probably now responsible for changing that text rather than letting the template builder or CMS user do that work.

[kyberfabrikken]

That example was probably rather weak, and I haven't completely thought it through, admittedly. I'll have to ponder over that during the hollydays.

As soon as you put that error message into the View code (or worse the Controller)

On a sidetrack, I can't help noticing that you seem to operate with three layers ; Controller, View-code and Template. Is that correct - and if so, what exactly is the distinction between Controller and View-code ?

[dreamscape]

That example was probably rather weak, and I haven't completely thought it through, admittedly. I'll have to ponder over that during the hollydays.

I really don't see what is problematic about the 2nd one. I think someone tried to say because it has an error message; however, that message is neither an application error nor an application message. The way I see it, it is entirely a presentational choice to display a message that the balance is below zero, just like it is entirely presentational choice to display a negative balance in red.

That could depend on the application as well. That kind of error message *could* be an application error, but without any kind of context, I'm forced to take it for what it is, which in that case, I think the decision to show a message like that or not is entirely presentational. It is a business decision as well, but it belongs to the business of the business using the application, not to the business of the application itself (unless the application does have business in that, but again without context I will assume not).

[dagfinn]

I try stay away from fancy tricks like that if I possibly can. The main reason is that designers really can't easily build something like that because <span class="$numberclass"> cannot be displayed. I'd prefer to have as much valid HTML in the templates as I can and let the designers create each variation in a way that can be displayed and visually approved.

If I understand you correctly, what you're after is a template that will show both styles when you view it in a browser or WYSIWYG editor. You have a point; that might be the best way to do it. I would do that, based on my previous example, by implementing the template in PHPTAL as follows:

<span class="positive" 
  tal:attributes="class numberclass" 
  tal:content="balance">2043</span>
<span class="negative" tal:replace="">-2043</span>

When you view the template itself, the browser or editor ignores everything but this:

<span class="positive">2043</span>
<span class="negative">-2043</span>

When processed by PHPTAL, it could end up like this:

<span class="negative">-4000</span>

This is how it works:

tal:attributes overrides the value of the class attribute, setting it to the value of $numberclass, in this case "negative"

tal:content replaces "2043" with the value of $balance, in this case 4000.

tal:replace in the second <span> removes the entire second <span> (=replaces it with an empty string)

[33degrees]

Regarding the Controller, I think a good rule of thumb would be that you should be able to make most (and even large) changes to the content of the presentation, whether contained in the View or Model, without having to touch the Controller.

Yes. The presentation is the view's domain, without a doubt. One of the big problems that people have with MVC is that, while the seperation between the Model and the View is quite clear, the seperation between Model and Controller and between View and Controller isn't. My approach is to move as much as logic as possible into the View and the Model, leaving the Controller as the bare bare minimum required to connect the two. There should be as little coupling as possible so that the model and the view used can be changed without having to modify the controller.

Getting back to templates, I think it's perfectly acceptable to have logic inside the templates, but I can understand the objections to that. The answer then, is to split the View layer into two, with the template containing the presentation data, and a helper class containing the presentation logic. In fact, one could split up the view layer even more, with logic in the Helper, markup in the Template, presentation in .css files, behavior in .js files, and the actual non-model text in some kind of internationalization module.

[Haleden]

I'm a huge fan of phpBB's template system. Comes with phpBB, and if I understand correctly (based on the comment in the file), you are free to use it as you wish for other applications.

[arborint]

Yes. The presentation is the view's domain, without a doubt. One of the big problems that people have with MVC is that, while the seperation between the Model and the View is quite clear, the seperation between Model and Controller and between View and Controller isn't.

The separation between the Model and the View and the seperation between Model and Controller are the SAME separation -- that being the separation between the Model and the Presentation layers. Remember, MVC is two separations, not three.

My approach is to move as much as logic as possible into the View and the Model, leaving the Controller as the bare bare minimum required to connect the two. There should be as little coupling as possible so that the model and the view used can be changed without having to modify the controller.

I agree that this is the best approach, plus lean Controllers are a thing of beauty.

[arborint]

On a sidetrack, I can't help noticing that you seem to operate with three layers ; Controller, View-code and Template. Is that correct - and if so, what exactly is the distinction between Controller and View-code ?

I'm not sure that it is three layers, but it might not be a bad way to think about them.

I'm not sure I have a clear rule about where the View/Controller division is, but I find that reality usually sets if for me. The View, for me, is about creating the presentation given all the data provided. And I know in clear-cut cases that when there is a request to change a View I talk to a designer; when there is a request to change a Model I talk to some business department. That makes my job to show the business department's data in the way the designer wants it.

I have found that if I keep the designer in the Template and out of the View code I am happier. Likewise I find that if I keep the business depts. on their side of Gateways and Mappers then I am happier too. Happiness == Changes are not painful.

In parallel with the above, when I am dealing with the designer I prefer to only make changes to the View code; and likewise when I am dealing with a business dept. I prefer to only make changes to the Model code. If the above does not happen (and I have to muck with Controller code) then I usually try to refactor.

That's more of a process influenced definition than a functionality division.

[33degrees]

The separation between the Model and the View and the seperation between Model and Controller are the SAME separation -- that being the separation between the Model and the Presentation layers. Remember, MVC is two separations, not three.

Well, I think there's a certain set of logic that could be called controller logic, that is neither view nor model, so I believe there is a third seperation. But what I meant is that there are often instances (especially when starting with MVC) where it isn't quite clear wether a certain piece of code belongs in the view or the controller, and in those cases it's best to put it into the view.

[arborint]

Well, I think there's a certain set of logic that could be called controller logic, that is neither view nor model, so I believe there is a third seperation.

It is my understanding that there are conceptually two separations. The first (and primary) is between the Model and Presentation (View+Controller) which is a layer separation. The second separation is between the View and Controller which is often not a layer separation. It is one of the confusing subtlies about MVC.

But what I meant is that there are often instances (especially when starting with MVC) where it isn't quite clear wether a certain piece of code belongs in the view or the controller, and in those cases it's best to put it into the view.

Though I think the idea of trying to keep the Controllers as lean as possible generally (but not always) produces the best results.

[lvismer]

I'm not sure that it is three layers, but it might not be a bad way to think about them.

I'm not sure I have a clear rule about where the View/Controller division is, but I find that reality usually sets if for me. The View, for me, is about creating the presentation given all the data provided.

Apologies for this seemingly silly question, but if you have a template and view-code, what code do you normally include in the view. Does it relate to logic related stuff that affects presentation. Perhaps some conditional stuff that you rather keep outside of the template, or maybe a different template to be used inside the view depending on some suttleties within the model?

For my current purposes I have managed to get away with having a controller, model and template (which in my case is the view then). I am just exploring when one would actually need the combo of creating a view that incorporates template/s.

--
lv

[Ren]

View code is all about generating presentation from base model. An extreme example which I'm developing still atm is generating charts, using inline svg.

http://ren.dotgeek.org/ex/example.php

[Requires FF1.5, a recent version of Opera (8.5 or 9 iirc), or IE with Adobe SVG Viewer plugin, apparently Safari nightlies have added SVG support so possibly could work in that too.]

[33degrees]

It is my understanding that there are conceptually two separations. The first (and primary) is between the Model and Presentation (View+Controller) which is a layer separation. The second separation is between the View and Controller which is often not a layer separation. It is one of the confusing subtlies about MVC.

I think this depends on your approach. In GUI MVC, the controller and view are neccesarily intertwined and could be considered a single layer, whereas in Sun's Model 2 architecture (which I believe is the first use of MVC for the web?), the Controller (servlets) and the View (jsp) are more distinct. So it's not really a confusing point; either way can be considered 'real' MVC, it's a detail of implementation.

Though I think the idea of trying to keep the Controllers as lean as possible generally (but not always) produces the best results.

I'd say we're in agreement about this, but I'd also add that the way to keep controllers as lean as possible is by decoupling them as much as possible from the views, which is best done treating each as seperate layers.