30
Horacio,
I think we agree on everything here, though maybe I wasn't all that clear:
Quote:
1) First of all, the PHP templates are cached in templates_c and the HTML templates are in the database, so retrieving them shouldn't be a problem. The loss of performance when retrieving a PHP template would occur only the first time the template is invoked, but then the same is true of the HTML template. Or am I mistaken?
...
3) If you use all the variables and then limit their display by handling the HTML template, and if we assume you don't lose performance because you left the PHP file alone, isn't it true that we'd need to consider also the minimal but real loss of performance created by the retrieval of variables that won't be used? In this matter, I think we'd need an efficiency guru to try both approaches (control in the PHP files against control in the HTML files) and get hard numbers about performance.
I think these issues are related. When you retrieve one record e.g. for a news article, then all data associated with that article (in the articles table) are essentially "free". Thus it makes sense just to get everything. But some related data from other tables is not so free. For example, the article contains the ID number of the poster, but not his/her username. The username must be retrieved separately. (Separate retrieval can still occur in the same query though, which complicates performance estimates.) Thus for all the data in the article table, we can err on the side of just getting all the info. For data outside the article table, maybe there is a performance argument for configurability. But note that 'getting' the configuration information to see which variables to retrieve is going to take one query (assuming config info is stored in the database) so this penalty must be weighed against potential savings. This must be done EVERY time the page is shown. i.e. Which fields to display can't (I don't think) be cached in the template.
Anyways, I also don't want to get in a discussion about this. There are some performance tradeoffs and I think we can't say too much without full testing in a deployed site.
Quote:
2) I'd have to agree the HTML templates are a great place to define WHAT to show and WHERE/HOW to show it. However, the first question has to do with the definition of the application's behavior, while the second has to do with the presentation layer. And my take here is that graphic designers should only be concerned about the presentation layer.
...
4) Having said all this, I wouldn't really want to start a discussion about this matter, so I rest my case just saying I'd like the definition of variables to be in the hands of the site manager and the definition of the presentation layer in the hands of the site designer.
Again, I think these are somewhat related. I think the PHP code should generate smarty variables for some given set of data then the templates choose which ones to actually use. (As many have pointed out, certain *current* smarty variables *should* be more granular in certain cases, so templates can achieve the desired control without hacking PHP code.) And as some have suggested, multiple standard templates could be provided. This makes it easy for the admin to choose a 'corporate' look or a 'gamer site' look for example.
I completely agree that the webmaster is not in general a designer. But if the webmaster gets to control via checkboxes which smarty variables are defined, then the designer needs to be a programmer - i.e. the template must handle every case of whether the variable is defined or not defined. As gstarrett and Draven have mentioned, the module could provide a document listing all the smarty variables defined for each particle page (and block). Then template designers are free to choose from this list when designing templates. The module would have to provide a list of variables that is relatively 'complete' and provides nearly everything that designers could want to display.
