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

On Wed, 2002-12-18 at 02:39, 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) I'm thinking more along the lines of what should be in the application code vs. what should be in the templates. What I'm trying to get at is this: {if $is_editor} .... {/if} is cleaner and easier to maintain than this: {if $smarty.session.logged_in eq "Y" and $acls.editor[$edit_id]} .... {/if} The latter has application logic buried in the template. > > > 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. It depends on your definition of a button. I'm thinking of a button as an element on the page that is required by the application design, which the programmer should know about. My button examples won't work if the programmer doesn't know what buttons are on the page. But then how does the programmer know what action to take when that button is clicked? This is not something the template designer decides as they make templates. Now maybe "button" is a bad term, I should use "element" instead because the designer may decide whether those are buttons, links, etc. > > > 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. The app should already be designed (maybe with mockups and logic documentation) before the programmer or the designer start on anything. The programmer should already know exactly what elements should be on every page of the application, and so should the designer. By element, I mean something on the page that pertains to the application design. A submit button on a form is an element. A new stylesheet to control table colors is not (designer can add that at will.) If you build your applications in a "code-as-you-go" method, then maybe my methodologies don't apply. But that is not good programming practice IMHO, it is good to have a destination before leaving :-) > > > 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. Why would you ever need hundreds of rights for a page? You should know what information is needed to draw a particular web page. I've never had to assign more than a handful of these per page, even in huge CMS systems (this is not including content variables FYI, just presentation logic vars such as $is_admin) But if you don't like assigning variables, you can certainly use an object. But still, keep the information in the template to presentation logic. Objects definately have a more complex syntax to them, but still work the same. Some basic ones could look like this: {if $info->is_admin} ... {/if} {if $info->logged_in} ... {/if} More complex example, listing a bunch of categories with edit access to some. without objects (assigning all vars): ------------------------------------- {section name=cats loop=$categories} {if $categories[cats].has_edit_access} {* display edit icon *} {/if} {$categories[cats].name}<br> {/section} with objects (only assign array of cat ids and object): ------------------------------------------------------- {section name=cats loop=$cat_ids} {if $catinfo->can_edit($cat_ids[cats])} {* display edit button *} {/if} {$catinfo->name($cat_ids[cats])}<br> {/section} To reiterate my whole point of this thread, notice I'm using "can_edit" which is all the template needs to know to show the edit button or not. What is masked (in the application logic) is how that flag is determined. Maybe the user has to be logged in, or have a certain level of ACLs, etc. > > 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. You bet, I've already cleaned up a bunch of the compiler code that I'll be committing later today, that's a start. This is something that will take some time and concentration though. > > Greetings, > Ivo > > -- > Ivo Jansch <ivo@ibuildings.nl> > ibuildings.nl BV - information technology > http://www.ibuildings.nl -- Monte Ohrt <monte@ispi.net>