21
Catzwolf
Re: Cutting out the Geeky stuff!
  • 2003/11/18 1:45

  • Catzwolf

  • Home away from home

  • Posts: 1392

  • Since: 2007/9/30


I am maybe going to go against the overall thinking of this thread, but I believe that performance here is not really the issue.

While I agree that adding a variable to every single part of a module would be a waste of time and effort, I however believe we have to take in the broader picture here.

The fact is this; every time we release an update it causes web designers in time which could be better spent else where and not having to update their client’s sites each time.

I think smilies and those 'geeky' images could be handled system wide using MYTS and could save countless hours of removing them.

Other area's such has logos, headers, footer, usernames and read counts etc should be handled by the module itself and thus allowing the module interface easily changeable without having to dive into the code to achieve this.

As Draven stated, we will be providing more than just one template for each module and also a way of easily changing them from the module itself in the future. But, we do have to balance this whole issue out and realise that while we want to give you a fast CMS, we also need to make it easily changeable.

Not all XOOPS users are web designers and do not know how to dive into code either.





22
gstarrett
Re: Cutting out the Geeky stuff!
  • 2003/11/18 3:07

  • gstarrett

  • Friend of XOOPS

  • Posts: 174

  • Since: 2002/3/12


Quote:
hsalazar wrote:

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.


Yes! Some sort of standard way of describing the smarty variables exposed per module and their definitions. I haven't looked into many templates {whisks off to spot check a few standard templates....} but as it is the web designer would have to basially reverse-engineer the variables from the existing layout. Not hard, but something every designer will have to do with every module they want to create a template for.

Some sort of xoops_version entry or text file or even standard comment block would go a long way to making it easier to find the name and meaning of smarty variables output by modules / block functions.

This is even more important if the module designer includes some "extra" variables that aren't in the default template set and wants them to be discoverable by a web designer. For example, a news item doesn't contain a smarty variable for number of posts by the author, but what if the module designer added it only to the module "in case" someone wanted it? Granted, this might not be the best example but I hope you can see where I'm going with it.

23
Per4orm
Re: Cutting out the Geeky stuff!
  • 2003/11/18 3:21

  • Per4orm

  • Documentation Writer

  • Posts: 145

  • Since: 2003/11/14


Draven:

Whilst I agree that the MAJORITY of display issues can be resolved through editing the templates, I have to point out that much of the problem here results from the use of composite arrays or variables.

For example, the reason that "Comments?" still appears in articles when comments are disabled, is because the phrase is a composite component of <{$story.morelink}>, which means it cannot simply be removed by editing the template.

Another example within the news module is that the title and topic also become a composite array, so they must be displayed on the same line. This is often undesireable - I know for example that I prefer to see a topic heading ABOVE the headline of the story.

Designers choose to use a CMS because it saves time for both them and their client. Whilst redesigning the look and feel of the site is part of their job, they should not be subjected to programming (or re-programming) PHP where it could be avoided - if we were all PHP experts, we would write our own CMS after all.

24
Draven
Re: Cutting out the Geeky stuff!
  • 2003/11/18 4:14

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


While I agree there are a few short fallings there are still ways around even that. They aren't pretty but can be done.

Gstarrett, I'll tell you what, would it help if I made a header comment outlining all the variables and their use for each template? It wouldn't take too much effort to add this when I'm making the default templates. Perhaps this would act as a mini guide for each template and all the available variables and their uses. Just a thought.


25
gstarrett
Re: Cutting out the Geeky stuff!
  • 2003/11/18 4:35

  • gstarrett

  • Friend of XOOPS

  • Posts: 174

  • Since: 2002/3/12


Quote:
Draven wrote:

Gstarrett, I'll tell you what, would it help if I made a header comment outlining all the variables and their use for each template? It wouldn't take too much effort to add this when I'm making the default templates. Perhaps this would act as a mini guide for each template and all the available variables and their uses. Just a thought.


Yes, it certainly would. Thanks!

26
Draven
Re: Cutting out the Geeky stuff!
  • 2003/11/18 4:47

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:

Yes, it certainly would. Thanks!


Ok, just to warn you my writting skills suck, but I'll try when the time comes.

27
Per4orm
Re: Cutting out the Geeky stuff!
  • 2003/11/18 4:52

  • Per4orm

  • Documentation Writer

  • Posts: 145

  • Since: 2003/11/14


A guide to the variables and their uses within modules would be a great help. Finding them within the code and editing them isn't the major problem... it's just making sure we're editing the right bits that takes up time!

28
gstarrett
Re: Cutting out the Geeky stuff!
  • 2003/11/18 4:59

  • gstarrett

  • Friend of XOOPS

  • Posts: 174

  • Since: 2002/3/12


Quote:
Per4orm wrote:

For example, the reason that "Comments?" still appears in articles when comments are disabled, is because the phrase is a composite component of <{$story.morelink}>, which means it cannot simply be removed by editing the template.

...


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):

<{$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!

29
Draven
Re: Cutting out the Geeky stuff!
  • 2003/11/18 5:21

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:

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!


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.

30
mvandam
Re: Cutting out the Geeky stuff!
  • 2003/11/18 8:35

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


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.

Login

Username:
Password:

Lost Password? Register now!

Who's Online

79 user(s) are online (41 user(s) are browsing Support Forums)


Members: 0


Guests: 79


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: May 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits