Re: [SMARTY-DEV] Re: Smarty and object support

I've been following this thread -- and frankly am _very_ pleased to see the new object support in Smarty. I have been building some content management solutions using the PHlexDB framework and the only reason the CMS hasn't used Smarty is the previously more limited OO support. (I wanted to be able to do {$Record->getName()} -- and now I can!). On the issue of the example that Andre provided, I tend to side with Monte. I think, though, that there is a middle ground. Ivo, you're right that the application / business logic shouldn't concern itself with the UI -- i.e. which buttons get displayed. _BUT_ most importantly templates should only store display logic -- and determining whether to show an "edit" button based on membership in certain groups, etc. is definitely not something that should be in the template. My take on it would be that the various roles & tasks are known to the business logic, but that actually setting $display_edit_button is probably not the best way to communicate those permissions to the template. Perhaps Ivo's idea of an array of permissions would work fine here -- e.g. {if $userrights.edit}<img src="editbutton.gif">{/if}. This leaves the actual role & permission logic to the application, while giving the template enough flexibility to redesign the UI. I think Smarty comes under attack most frequently for having too much support for logic in the templates. I think that Monte & crew have, actually, a very clear understanding of what display logic is -- and have built Smarty along that vision. But you can certainly _abuse_ the power of Smarty to handle business logic in your templates. I think that one of the real advantages of using a templating engine is the implicit "contract" that you are setting up between business logic and display logic in your application. It is always going to be a bit more work to implement a templating solution, because your business logic is going to have to be explicit about which variables a template should have access to -- but obviously there are huge benefits -- specifically the designer-friendly templates & the layered caching potential & simply the fact that there is a layer of separation between the display and the PHP. Anyway, my 0.02 -- and hats off to the Smarty team for the new object support! Cheers, Hans Ivo Jansch wrote:

Hello Monte, Monte Ohrt wrote:

I don't agree. Yes, the template needs to know whether to show or hide an icon, that is presentation logic. BUT, the template does NOT need to know WHY the button is being shown or not (user permission, whatever), that is the application's job to inform the template whether or not that button is shown.

First of all, I think you can't make this assumption if you don't know what tasks the designer and the developer have. Yes, in a perfect world the template designer would just only do the layout and the developer would make all those decisions. Speaking from experience, I can say that the line isn't always drawn right in the middle. There are situations where the template designer does have to make these kinds of decisions. Ok, the example with the object might be a bit overkill for designers, so I would suggest using an array with the permissions. In the application logic, call the $nextgen->user->isAuthorized stuff and put the results in to an array, say, $userrights. (but keep on reading, I have a case below that justifies calling functions)

The application logic should do this user permission mess, then set a simple boolean template var such as $show_edit_icon. This way the template is cleaner and tends only to its purpose, and if you one day decide to change procedure (such as the method that a user is authed) you don't need to muck with the template.

But Monte, this is just the other way round, and could be considered wrong as well. Now you don't have application logic in your template, but you have layout logic in the application code. The developer shouldn't need to know that there will be a button or an image or whatever. So I think just setting meaningful variables, like the authorization array I mentioned above, is the best way to separate the two.

Eh? The designer should be following the application design. If they need to add new elements depending on some new criteria, you didn't finish the application design before coding the app.

Again, in a perfect world. Designers tend to change their minds a lot a long the way. I would design the app such that the developers don't get affected by that too much.

Make sure everything the designer needs is assinged, they can go from there.

True statement. As long as you do it on the data level, not layout level. ($authorized instead of $show_edit_button).

Check to see if the user holds at least one CourseManager role: {if $rolehelper->hasRole( $current_user, 'CourseManager' ) }

    ...

{/if}

{if $show_course_manager_button} ... {/if}

Apart from the object orientation (which I think is a programming concept that a template designer should not need to master), I think the first approach is more flexible. For smaller applications, the second is probably best, but given a large enough application, with hundreds of rights to assign, this approach is going to kill your performance. You can't just compute and assign hundreds of variables for each template, if your designer is going to use only 3% of it in each template. It's better to have a function that checks the rights you need. A few months back, I proposed a multistage parser (are you still considering this by the way?), which could increase performance even more. In the first stage the function would determine which rights it needs to load, and in the second pass, it performs exactly those queries it needs. Greetings, Ivo