All:

Here's my two cents on this matter.

Xoops has many instances of whole blocks defined at the core level, which means you can either have the block or not, but the problem resides in the fact that many of those blocks include content belonging to different categories.

Immediately comes to mind the line displayed by default on the news items. The line has the topic name (with a link to the topic), then a colon and then the news item name (with a link to the individual story), and your retrieve this with a single Smarty variable.

I can imagine the reason for doing this: making the job of the webmaster easier.

It's easier, yes, but another consequence of this is that in some cases you can "turn off" these "geeky" stuff while in some others you can't do it without killing things you want.

The long term solution implies two different tasks:

1) To separate all displayable items and put them in separate variables, that is, a still more granular variable assignment process.

2) To include in each block configuration option the ability to include or not each displayable item. This, of course, will have an effect in the code: there'll be more of it, but then again that's the price of more user power.

I agree on the need to control these things, as well as the more than "geeky", "youthful" smilies and more assorted things having to do with the building of communities. XOOPS was born from a dinasty of community building efforts; now it has matured to the point that the lack of corporate seriousness is seen as a disadvantage. Maybe, so I'd say it's time for XOOPS to evolve to a more complete solution, and the granularity of control over what gets displayed it's certainly an important step in that direction.

Cheers.

I can understand the desire put forward in this thread. I can see the benefits of less info. in the templates.

However, I am concerned that making everything a check box item (that then needs to be polled every time there is a related query?) would impact performance.

I still think making stripped down versions of the templates available would cover this without the risk of a performance hit.

I agree that stripped down versions of templates would be an appropriate way to deal with the majority of issues we're facing here. However, there are a number of issues that still need to be addressed in the core code.

For example:

1. When you disable smilies in admin, why do they still show in the forms?

2. When you disable comments in the news module, why does the word "Comments?" still appear in the news item summary?

I know I'm being picky here, but XOOPS is an excellent system and deserves to be given a corporate client base - the easier we can make it for developers to provide a corporate look to Xoops, the easier it will become.

You are right, those would be good to fix.

I have to agree with all of this. We do very little advertising, so when we get new clients, they are almost all word-of-mouth and we have a good relationship from the very first moment. Therefore, I'm able to take the time to explain that anything they don't like I can take out, but I still get a lot of resistance to "cutsie" stuff (the phrase I tend to hear instead of "geeky" stuff, but I think the sentiment is the same). The five things I hear constantly that clients don't want are comments, number of hits/reads, voting/rating, the name of the poster (for news, links, etc.), and smilies. Of course, part of what I am getting paid to do is customize these things to give the clients what they want, but as someone else said, this creates problems when it comes time to upgrade.

I agree! It seems there are some bugs (e.g. comments? on news item with comments disables, same with smileys), and just a couple of template granularity issues. Nothing show-stopping by any means.

It also seems there is a bit of variety in the desired strip-down levels. I'd suggest everyone post their ideas on what they think a "professional" template for news, etc. would contain or not contain. We shouldn't worry about agreement, but rather to make sure that there are a template edits or option to disable functions to cover the majority of the diverse needs.

That's my 0.02

To give a bit more thought and input, here's my thinking:

1. Major settings should be set in module preferences - and it should work properly (e.g. the comments/smilies still there if turned on)

2. ALL smarty variables need to be granular/atomic, meaning that it should NOT be a composite variable.

3. A professional site will (or should?) make custom themes for their site in order to get the proper look. The people, doing this change, are probably HTML people - why not just make it a part of the web development in a company to modify the templates to the professional look? It's all HTML and smarty variables, so it should be possible for the "pixel kings" (as we have kindly renamed the HTML people in my development group) to make it on their own.

I've recently worked with Java Servlets and JavaServer Pages and PHP + SMARTY is SO much more separated HTML from code that it should really be very easy to modify to personal/company taste.

If companies choose someone else to just "install XOOPS and those modules etc. etc." they can hardly expect anything but a standard setting, which should be modified to their liking.

That's just my thinking - I am not in any way connected to a professional company and won't know, what such a company would want, but I do know that catering for everyone will make most people insatisfied.

hsalazar [edit: and some others who posted since I started writing this ],

I think you have found what is the key point here. A lot of things (such as new topic and title) are intertwined at the level of PHP such that they aren't assigned to different variables. If they were, this will make a lot of things more customizable.

I *do* think the template is the place for a lot of these things. e.g. If you don't want the author of the story, then the template is where to remove it - I think you don't want to have config options to enable/disable every single variable. This would be easier for admin, but will really slow down the display of many things. IMHO, templates should control not only how things are shown (visual presentation), but also WHICH information to show.

But certain things like smilies etc. do not fall into this class. This is part of the 'textsanitizer'. It seems there is an issue of providing each piece of data as a separate variable, but also separating the various 'transforms' that are applied to each of those variables. In most modules, there is only one major piece of text that gets transformed (e.g. with smilies, bbcode, etc...). If this can be enabled/disabled at the whole-site level as well as per-module level, this might be sufficient. These options will be invoked when displaying the item, and also when showing the 'edit' form (i.e. we need to hide the smilies and smilies checkbox when they have been disabled).

Anyways, very happy to see this thread... I think it addresses not only the immediate issue of certain particular options that we'd like to have control over, but also the general issue of design and more complete separation of php data manipulation and presentation.

[EDIT: this was posted at the same time as mvandam, sorry]

I'd just like to note that everything people have mentioned so far, aside form the smilie problem in forms, can be easily dealt with in the templates. All the reads/views etc. are just variables being displayed in side loops. Remove the <{$read}> and <{$views}> (these are just examples, not actual varible names) and you solve the problem. Now I understand for the "non designer" type, it'd be easier to just have a switch in the module admin to choose whether or not to show them (which I assureyou we'll do our best to accomdaite in the future), but it's not hard to remove them now if you really need to.

mvandam:

Here's another 2 cents coin. I think you'll agree we need the best performance in Xoops. So it IS important to define what should be the place to handle the inclusion or absence of a variable. Is it the PHP file? Is it the template? Apparently you're sure doing this at the PHP level will slow the system down, so we need to dissect several questions.

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?

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.

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.

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.

Of course: many XOOPS webmasters are at once both managers and designers. So they wear both hats. So it's a matter of preference. Or not?

Cheers.