| Re: Cutting out the Geeky stuff! |
| by Mithrandir on 2003/11/18 9:16:28 I think a simple list at the top of each template listing available variables and their meaning is a great idea. Just open SMARTY debug and copy-paste the list of variables and then change the values to descriptions. I'll do that in next version of Team Module. |
| Re: Cutting out the Geeky stuff! |
| by mvandam on 2003/11/18 8:42:48 Quote:
This is an important point. There are already a lot of themes out there... I don't know how many 'template sets' exist with replacements for the 'news article' but I'm sure there are quite a few. If the news module suddenly stops providing 'story.morelink', then all these templates "break". I guess for a limited time, both the story.morelink and also the split up version could be provided. The story.morelink could be documented (in the list of variables for the template/module) as deprecated, maybe set to expire in e.g. 6-12 months (at which point it will not be provided by the news module) so template designers would know not to use it. Perhaps the list of variables could include a version number. Then, templates could indicate which version of the variable list they support. Then e.g. the module installer/updated could easily identify mismatches (perhaps giving the option of trying anyways) in module-variable-list-version and template-version. Hmmm.... |
| Re: Cutting out the Geeky stuff! |
| by mvandam on 2003/11/18 8:35:48 Horacio, I think we agree on everything here, though maybe I wasn't all that clear: Quote:
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:
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. |
| Re: Cutting out the Geeky stuff! |
| by Draven on 2003/11/18 5:21:04 Quote:
Just to comment quick here, such changes should/would be listed in a changeslog.txt supplied with the updated version. But I'll try my best to document any such changes in the template, time permitting. |
| Re: Cutting out the Geeky stuff! |
| by gstarrett on 2003/11/18 4:59:27 Quote: Per4orm wrote: I absolutely agree with the granularity issues... and that provides a much more reasonable example for my previous thought (of having what variables are available and their meaning): Backward compatability. I *just* went through this with XoopsGallery. I made a big mistake by not leaving in the old smarty variables when I made the templates more granular. XG used to render half the page with one smarty variable, but now I have that broken out quite a bit to allow the designer more control. In this particular case, I can see <{$story.morelink}> being seperated into (this is off the top of my head): le="color: #000000"><?php <{$story.morehref}> URL to full story <{$story.morehreftext}> Text "Read More..." in selected language <{$story.morebytes}> # bytes remaining <{$story.morebytestext}> Text "bytes more" in selected language <{$story.comhref}> Comments form URL <{$story.comhreftext}> Text "Comments?" in selected language That is a LOT of variables for one small section of the block, but it gives total freedom to the designer to implement as they see fit. Some of these (the "text" ones) are likely repetitive to other smarty variables that might already be available. Now, to the point here: If someone was to patch the News module to do this, what happens to the templates with the old <{$story.morelink}>? How does a template designer know that the old morelink is depricated and the 6 others take it's place other than by comparing versions of templates? Thanks Draven for already looking at adding this! |
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $15.00 |
| Due Date: | Jul 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $15.00 |
|
|