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

On Wed, 2002-12-18 at 03:13, André Rabold wrote: > I completely agree with you Ivo! > > If you know PHPNuke etc. you know there are modules. My application > uses modules too each can have different access rules. > In my project database users can create, edit and view current projects. > There are many of them and not every project should be shown to everybody. > A person has read access to some projects and editor access to some others, > perhaps he's also manager of another one he created by himself. This all > works > right now. > So know imagine you want to show a list of all projects to the user: > > +-----------------+ > | Project A | > +-----------------+ > | Project B | > +-----------------+ > | Project C | > +-----------------+ > > If user has editor access I want to show the "edit" button. It doesn't work > to > assign only a single variable $show_edit_button. Btw. I don't like this too, > like Ivo. > Okay I could assign an array called $show_edit_button[] with the project's > ID > as index. But what's with the $show_delete_button[]? So we need to assign > another > array. > For more complex databases like a category system you can think of more > access > priviledges: See the category, open and read the content of the category, > add content > to the category, edit and delete content, add a subcategory, edit the > category, delete > the whole category even if content is in it, etc. > This is going a way too complex if you need to handle this with arrays. > Here's were > my isAuthorized function goes in: > > $nextgen->user->isAuthorized ("Categories", $currentCategory, _NGAUTH_READ) > > 1st param: Module name (can be null for current module) > 2nd param: Context (in this case it's the category) > 3rd param: Minimum access level needed for method to return TRUE. > > The $nextgen object is only a container for all core objects which can be > used in the > templates. A bit like the $smarty variable. This is due to avoid name > conflicts with > template specific variables and these objects exists in all (!) templates > regardless the > developer assigns them manually or not. > > Monte, what whould be your solution for this problem? I think the above > function is > the cleanest way to do this. > You could certainly use an object, but keep the info limited to what the template needs to know to display the content: {section name=proj loop=$project_ids} {if $pinfo->can_edit($projects_ids[proj])} {* show edit/delete buttons, etc. *} {/if} <tr><td>{$pinfo->name($project_ids[proj])}</td></tr> {/section} "can_edit" masks the application logic that determines whether this user has edit access or not. > Cheers, > André > > > "Ivo Jansch" <ivo@ibuildings.nl> schrieb im Newsbeitrag > news:3E00344D.7090304@ibuildings.nl... > > 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 > > > > -- > > Ivo Jansch <ivo@ibuildings.nl> > > ibuildings.nl BV - information technology > > http://www.ibuildings.nl > > > > -- Monte Ohrt <monte@ispi.net>