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

Application programmers might want to read through this one, it has some interesting points in it.... On Tue, 2002-12-17 at 13:58, Lee Coltrane wrote: > > From: Monte Ohrt [mailto:monte@ispi.net] > > > > On Tue, 2002-12-17 at 11:08, André Rabold wrote: > > > Yep, basically you are right. > > > > > > The proplem for me is that I use alot of constants for > > example to check > > > access rights within the template. Here's a real-life example: > > > > > > {if $nextgen->user->isAuthorized(null, null, _NGAUTH_EDIT)} > > > <a href="{ng_moduleurl ...}">edit</a> > > > {/if} > > > > The problem is you are crossing the line of keeping application logic > > out of the templates. You really should do something like this: > > > > {if $user_is_authorized} > > ... > > {/if} > > > IMHO, simply checking something like $nextgen->user->isAuthorized() for > purposes of displaying (or not displaying) some markup is not application > logic. There could be thousands of things that a user may be authorized to > do, _NGAUTH_EDIT is only one of those things. It is completely reasonable > for a page designer to decide that he/she needs display logic that shows, or > hides an icon based on a user's permission. 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. 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. > > It's a design decision, thus it belongs in the template...the application > logic would handle the condition where a user actually attempted to do > something he was not authorized to do, whereas the designer would design > pages that (hopefully) prevent the user from having the option of doing > things he is not allowed to do. Usually the only thing the designer is doing is showing/hiding content based on conditions, that's all. The details of why these elements are shown/hide should not be in the template, that is application logic. See examples futher down... > > I'm working on a similar problem. I want the designer to have access to the > full range of permissions (so that I don't have to go add application logic > every time the designer decides to make an element dependent on users' > permissions). It would be unreasonable to set each possible permission into > a smarty variable as $user_is_authorized_for_<SOME_PERMISSION>. 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. ouch! Make sure everything the designer needs is assinged, they can go from there. > > However, I do think that $nextgen->user->isAuthorized(null, null, > _NGAUTH_EDIT) is a bit complex for a smarty template. It's not the use of > the constant that bothers me, it's the two null parameters that concern me. > What are they used for? > > I'm currently planning to do something like this: > (note the use of the string, 'EDIT', rather than a constant) > > {if $current_user->hasPermission('EDIT', $billing_contact)} > ...display a button... > {/if} ugh, this isn't going to be fun for you to maintain :-) I'm only speaking from experience, you are much better off by assigning variables intended purely for presentation, like so: {if $display_billing_button} ... {/if} The application should determine whether that button shows or not, yes? That is not the designers duty to figure out user permissions, that is part of the application design logic. Let the _application_ tell the template if that button is shown via this boolean variable, don't put all the user permission junk in there, that's not what the template needs to know. If the designer needs to add a new button based on some new criteria, you screwed up during the application design phase :-) But hindsight is not typically 20/20, this happens. You will just need to assign a new presentation value for them to use. > > I think that this will work pretty well. The first parameter is the name of > the permission to check. The second parameter may be either an object type > (a string), an object instance (a reference), or it may be omitted - which > is expected depends on which permission being queried. I also want to have > a set of functions on my Role object for checking which roles a user holds. > those would look something like this: > (Role is just a higher grouping of access control on User) > > 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} > > -OR- > Check to see if the user holds the Admin Role: > > {if $rolehelper->isAdmin($current_user)} > ... > {/if} {if $show_edit_user_button} ... {/if} > > -OR- > Check to see if the user holds a CourseManager role for the given Course: > > {if $rolehelper->isCourseManager( $current_user, $current_course ) } > ... > {/if} {if $show_edit_course_button} ... {/if} getting the picture? ;-) > > -AND so on- > > > I don't know if that was useful or not...but I thought it might help out a > bit. > > good luck, > -lee I'll almost guarantee most of your needs are whether or not to show a button or icon. Yes, showing these icons is dependent on different application level criteria, BUT those criteria should not be in the template! -- Monte Ohrt <monte@ispi.net>