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

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. 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 > >