Re: [SMARTY-DEV] Re: Smarty and object support
| From: | Ivo Jansch | Date: | Wed, 18 Dec 2002 08:39:41 +0000 |
| Subject: | Re: [SMARTY-DEV] Re: Smarty and object support | ||
| References: | 1 2 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-433@lists.php.net to get a copy of this message | ||
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).
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 -- Ivo Jansch <ivo@ibuildings.nl> ibuildings.nl BV - information technology http://www.ibuildings.nlCheck to see if the user holds at least one CourseManager role: {if $rolehelper->hasRole( $current_user, 'CourseManager' ) }{if $show_course_manager_button} ... {/if}...{/if}