Parameters vs Templates

[MasterChief]

Just want people's thoughts.

We current have a lot of parameters to turn things on and off and around, print icons, title links etc. Now, while it makes the code look like a spider on speed, php can handle all the what-if logic statements.

But, when we move to templating, putting all this logic into the template is starting to look messy. So here's a proposal.

Using content as a reference point, what if we drop out the parameters dealing with presentation and, instead, replace them all with a single selection list for a templte variant. Although we might have 20 parameters there are probably only 3 or 4 combination used over the whole site.

For example, this code has a lot of logic built in to test whether butons are active, etc (it's incomplete by the way):

<table class="contentpaneopen{PAGECLASS_SFX}">
	<tr>
<mos:tmpl type="condition" conditionvar="item_title" varscope="body">
	<mos:sub condition="1">
		<td class="contentheading{PAGECLASS_SFX}" width="100%">
			<mos:link src="content-title" />
			<mos:link src="content-edit-icon" />
		</td>
	</mos:sub>
</mos:tmpl>
<mos:tmpl type="condition" conditionvar="print" varscope="body">
	<mos:sub condition="1">
		<td align="right" class="buttonheading" width="100%">
			<mos:link src="content-print-icon" />
		</td>
	</mos:sub>
</mos:tmpl>
<mos:tmpl type="condition" conditionvar="email" varscope="body">
	<mos:sub condition="1">
		<td align="right" width="100%" class="buttonheading">
			<mos:link src="content-email-icon" />
		</td>
	</mos:sub>
</mos:tmpl>
	</tr>
</table>

Now, what if we had instead 2 or 3 templates like this:

<table class="contentpaneopen{PAGECLASS_SFX}">
	<tr>
		<td class="contentheading{PAGECLASS_SFX}" width="100%">
			{ROW_TITLE}
		</td>
	</tr>
</table>

The above template might be named "Title - no icons"

<table class="contentpaneopen{PAGECLASS_SFX}">
	<tr>
		<td class="contentheading{PAGECLASS_SFX}" width="100%">
			<a href="{LINK_ON}" class="contentpagetitle{PAGECLASS_SFX}">
			{ROW_TITLE}</a>
		</td>
		<td align="right" class="buttonheading" width="100%">
		<mos:link src="content-print-icon" />
		</td>
	</tr>
</table>

This (above) might be "Linked title with print". Here the print is linked to a template because in this case there is a state change on the button. We could also just as easily write:

<table class="contentpaneopen{PAGECLASS_SFX}">
	<tr>
		<td class="contentheading{PAGECLASS_SFX}" width="100%">
			<mos:link src="content-title" />
		</td>
		<td align="right" class="buttonheading" width="100%">
			<mos:link src="content-print-icon" />
		</td>
	</tr>
</table>

Please ignore the 'table' tags all ye X-HTML-ers. Yes, that can be changed later.

What I'm getting at is putting the control of the output squarely in the hands of the HTML developer. In the code, we just prime the template with all the information we've got. The web master can then choose from a set of templates rather than a set of parameters.

Pros
- greater control/scope for the designer
- less pressure on the php code to cope with presentation logic

Cons
- lots of templates to choose from could get confusing (maybe couple this with a preview?)

Of course, with this method you are no longer locked into the order that Mambo wants. You can have print icons at the bottom of your page, etc.

Constructive thoughts and comments welcome.

[hyper]

Andrew, I love this idea - this would make Mambo layouts a lot more configurable, allowing creatives to have a lot more fun and, as you say, putting more control into the developer's hands. One caveat, however: documentation :-)

Greg.

[mambosolutions]

pros: more flexibility for the designer. this i like

cons- less (lots less) flexibilty for the non html/designer type of site admin. (i.e. most paying clients)

I'm not sure that this is a flexible enough approach....my guess is that instead of leaving it soley up to the designer...how about a scenario where you give the designer more flexibility (perhaps have a master variable that determines whetre or not to use system A or system B) that is included in the template.

System A) like it is now...keeps the control within the reach of the normal 'site admin'

Sytem B) put some or all of the control in the hands of the template designer.

function(paramsNoob) {

if($paramsNoob == 1){

print "handle parametrs the 4.5.1 way";
}

if($paramsNoob == 0){

print "handle parametrs the NEW way";
}
}

--make any sense?

also..maybe keeping the option for the 'non coder admins' but cleaning up the UI would be possible by putting most of all these options on the global config page...most apps i know that are similar to Mambo have a huge gloval config setting page...at least its all in one place and intuitive to find that way...and its hidden out of the way with one click...

[MasterChief]

We should still be able to provide a 'parameterised' template...it will just be a whoa (pronounced who - a).

May I ask what are the normal questions that a client ask? It is:

A) how do I turn off the title, email button, etc
or
B) how can I put this button in a different place, can you float the TOC somewhere else

If the questions from your clients are more like "why am I locked into this layout for my content" then I'm happy to put the look into devising a system to support this. It's certainly a cleaner approach from the templating side of things.

[mambosolutions]

hey MC

It totally depends on the client...I have had both type A) and type B) questions from same client, i have had no questions from some clients, etc.

Type B questions are (are now) left up to the designer to figure out, hack etc. Anything you can do do make it more flexible will be appreciated and helpful.

When you say we will still be able to provide a parameritised template, are you speaking backend admin template?

sorry if I seem confused...its not hard to do, confuse me that is

*edit*

another thing that goes with this...is the output of components... i guess we touched on this subject in another thread (pat template i think)


Will this also mean it will be possible to 'style the layout' of components without hackage?

Originally Posted by MasterChief

We should still be able to provide a 'parameterised' template...it will just be a whoa (pronounced who - a).

May I ask what are the normal questions that a client ask? It is:

A) how do I turn off the title, email button, etc
or
B) how can I put this button in a different place, can you float the TOC somewhere else

If the questions from your clients are more like "why am I locked into this layout for my content" then I'm happy to put the look into devising a system to support this. It's certainly a cleaner approach from the templating side of things.

[booger]

This discussion and ideas behind it is why I wrote the Modular Template Package. I wanted ways to change layouts with just a button, to turn the site name and or pathway with just a button, so on and so forth. The ability for anyone to completely change the look of the site without diving into the actual code.

I would love to see something like this in the core.

[MasterChief]

Oh, sorry, I way to much thinking in draft here. I AM talking about the individual views of components using pT. The above code is for say a file called showcontent.html. What I'm thinking is that you provide:

showcontent.0.html
showcontent.1.html
showcontent.2.html
showcontent.3.html

Each has it's own layout variation for showing the content item, a blog list, etc (actually, you only have two super types, one for showing an item and one for showing a list - a blog and a table are just variations on a theme). It would include some sort of description in the file (like, 'Simple Layout - no buttons'). The ability to share different sorts of component templates could open up a whole new realm of possibilities.

So, yes, we can have one mother-of-all-templates that includes twisted logic to do the tick-and-flick parameters think. We can also provide templates that just target what need to be displayed. For example, I want the ability to be able to write a template for a blog list so it can look like this: http://www.php-tools.de/site.php

I realise the word 'template' is going to overlap here. We are not talking specifically about the overall 'site' template (it's already using these principles), we are talking about the output of components.

Does that make it a bit clearer?

Please don't be afraid to push back on some of the concepts (emphasis on I am thinking in DRAFT). You people are the ones explaining to client why Mambo is so great but, oh, you can't to this or that.

[mambosolutions]

thats more clear to me now....

now it reminds me of Xoops2

in Xoops2 they have (agin overlapping terminology) templates for each content output...

so to put in mambo frame of reference, imagine you have youe Frontend overall look and feel of your website 'Template' (what we all commonly know now as mambo templates)...then there are content level 'templates' for each kind of content output (in our case Mambo Components)...so as further example 'News' or 'Links' could have any number of

'contentTemplate'

(C) 2004 mambosolutions





Are we on the same page MasterChief? (or at least the same book )

[MasterChief]

Exactly. Trick is to make it simple to use and deploy. So, generically, we have the following super-types of templates:

Site Templates (the ones we know and love, module positions and all) = ST's
Object List Templates (how you present a list of 'things') = OLT's
Object Templates (how you display the individual 'thing') = OT's

Now, I'm thinking there could be a lot of variations just for displaying a content item. We'd need for you to be able to 'disable' certain OT's. Example would be you have a dozen or so to present to your client. They settle on 3 different OT's for content for 3 areas of their site. You turn the other 9 off so that they only even have the option of selecting the 'published' (if you like) OT's.

Now, the really wild stuff (and this is starting to run off topic a little) is that you can then go into customising patTemplate itself to insert a random image, or advertising, or a comments form into your OT. Hmmm, that could take the pressure off some mambots...have to think about that one (note to self).

[mambosolutions]

gotcha... becoming clearer


i like the idea of the possibilities this concept presents...opens things up

this is further going off topic..but somehow related to this and to the useabilty aspect we have been discussing in general:

I know that terminolgy is neccessary to communicate concepts, and we all need to label things to be able to differntiate between Apples and Oranges..so...however I reccommend keep the terminolgy as simple and descriptive as we can...

So maybe a small thing like instead of labeling thiese new critters abbrevaitions like ST's OT's and OLT's - why not make them more descriptive like 'Templates' (as this by now is what most everybody, certainly all people that use mambo but will never post on this forum) know 'ST's' as....

and for 'OT's' and 'OLT's' how about simply ' Content Templates' or Content Stylers' and perhaps ' Content List Templates' or Content List Stylers'


i realize this is a small point, but making things easier to understand to me means looking at all the small points, because together all the small things affect the whole. people will get confused if the word 'template' is used in 5 differnt places.

Site Template
Admin Template
Object Template
Object List Template
umm that was only 4 Template

what do you think?

[MasterChief]

We can work on the terminology/taxonomy later I was just throwing something in to aid discussion. I used the term 'Object' because that's how it's refered to (internally) in the ACL. We could just as easily use 'node' or 'item'. You'd then make the appropriate replacement in the derived use, eg for WebLinks you'd have Weblink List Template, and so on.

But, yes, they will all be referec to as templates (breeding like rabbits).

My abbrev's were simply to reduce the number of characters to type

[YTW]

Templates overwriting default Parameters values

I would second this approach. The designer needs full control on the layout. Give him complete freedom. If the price for that is to learn a new html derivative language (patTemplates & so called "objects"), the designer will simply do it. Don't doubt that

IMHO, the philosophy should be:
1. In 80% of the cases, a "standard" user will not need that knowledge to use Mambo and customize the layout
2. For the 20% of the cases requiring an advanced customization, make sure the "standard" user will find plenty of docs & learning examples if interested to know more of the subject

[Jinx]

Originally Posted by MasterChief

Just want people's thoughts.
Using content as a reference point, what if we drop out the parameters dealing with presentation and, instead, replace them all with a single selection list for a templte variant. Although we might have 20 parameters there are probably only 3 or 4 combination used over the whole site.

Great ! This is how it should be done, strict MVC seperation between logic and output.

Cons
- lots of templates to choose from could get confusing (maybe couple this with a preview?)

True, i don't believe we need to give the user all content templates at once. We could present the user with let's say 3 different possibilities and allow a user to add other content templates as necessary. Much like u install site template at the moment a user could be given the possibility to install content templates.

I'm sure the community will react, current template sites can offer content templates for download, maybe a new site devote to content templates pops up ? Who knows ... I would leave this to the community.

I would however make sure that a mambo template package can contain, the site template together with a set of content/object templates. This will greatly improve a template designer's power. It will require a change in the template installer but it's definitly worth it.

[timpascal]

Does this mean that I wouldn't have to edit content.html.php in the core directly to get the content object to look the way I want it to? If so, then this is definitely a step in the right direction.

The current list and content layouts could be bundled with Mambo as templates - designers could use these or create their own (much the same way site templates are proliferating). If these templates were treated similarly to site templates, could the Administration back-end be extended to manage them? That is, list the current list/content templates (with thumbnails?) - enable them by default, or assigned - enable upload/installation via the xml package mechanism already in place etc...

We are trading one level of complexity for another - with clear benefit to the developer I guess. I think it can work as long as the Administration structures are robust - I don't think the templating effort will be too bad provided the core examples are reasonably complete and representative of what is possible.

I'm eager to see Mambo under patTemplate and how it is moving towards XHTML/CSS compliance. Design (as well as parameterization) can be moved out of the core through a combination of templating and div/class abstraction. This is very interesting discussion and I'm eager to see some of it in action (- not asking when, just indicating enthusiasm <g> -).

[dknight]

Over here, our Designer *finalize* the template designs before handing it over to client. Majority of them will not be fiddling with the template output anymore after the handover. We spend most of our training session to teach them how to handle content, ordering, publishing, explaining what is section/category etc. So yes, I'd like to see more control of the output given to Mr. Designer and less parameter to fiddle with to the user.

There is certain tradeof here, ie: More learning curve to Designer and "Simplicity" for Client. We always choose simplify the Content Management part to our client

Suggestions [1]:

Site Template #1
----------------
DESC: this template will have all the params turned ON plus all the fancy stuff (image bullet, body background etc)
FILES:
- showContent.html
- listContent.html
- showContact.html
- etc

Site Template #2
----------------
DESC: will have all the params turned OFF. Simple & Clean type of template
FILES:
- showContent.html
- listContent.html
- showContact.html
- etc

Site Template #3
----------------
DESC: somewhere in between template #1 & #2 ?
FILES:
- showContent.html
- listContent.html
- showContact.html
- etc

My proposal is to allow user to choose OTs (Object Templates) and OLTs (Object List Templates) for each component/content from another template.

Suggestion [2]

Site Template #1
----------------
CONFIG:
- Enter Background file
- Show Print icon?
- How many leading story?
- etc
FILES:
- showContent.html
- listContent.html
- showContact.html
- etc

This method works similar to the current working of Mambo module. We must be able to 'clone' this template and create a duplicate one with different configuration. The cons is we're going to put more instructions and conditions to the template itself.

---

Not sure if the above works, just throwing some ideas around

Cheers,

[MasterChief]

Originally Posted by timpascal

Does this mean that I wouldn't have to edit content.html.php in the core directly to get the content object to look the way I want it to?

Yes, you wouldn't.

Jinx, yes, it's exactly like we run the Site Templates at the moment. You start with something you like and tweak it from there. We've never gone for the approach of some system where you have all the module positions parameterised...there are just too many options.

The key is to make the whole system simple and managable (because it can easily fall into complex and unmanagable). The idea of 'installing' different OT's and OLT's would be a plus, whether they are aligned with a template or in the core I'm not sure yet. I know there are questions about "can I have a template that completely 'skins' mambo, icons and all". We'd try and make this easier but, equally, I don't want the core looking in 4 or 5 different places. Will require some thought to balance that.

[Jinx]

Originally Posted by MasterChief

Yes, you wouldn't.

Jinx, yes, it's exactly like we run the Site Templates at the moment. You start with something you like and tweak it from there. We've never gone for the approach of some system where you have all the module positions parameterised...there are just too many options.

Agreed, in my opinion the right way to follow.

The idea of 'installing' different OT's and OLT's would be a plus, whether they are aligned with a template or in the core I'm not sure yet.

Just remember that styling isn't the responsibility of the core. If u add different OT's and OLT's in the core, i would do this so that they can be removed. Think about the OT's and OLT's as standard templates.

I know there are questions about "can I have a template that completely 'skins' mambo, icons and all". We'd try and make this easier but, equally, I don't want the core looking in 4 or 5 different places. Will require some thought to balance that.

Maybe u could use a 'if not defined use deault' approach ? Meaning that template designers can create a full blow template that completely defines mambo look and feel (OT's, OLT's, Template, Icons, CSS, JS, ...) If one of the parts isn't defined in a custom template Mambo falls back on the default template ?

[eko38]

I think that the proposal is excellent, but would like to see more emphasis in the templating system on accessibility and would appeal to the Master Chief to put the accessibility of MAMBO as its top priority not only because so far most if not all CMS systems seem to lack compliance. XMambo was going the right direction, but seems to be relatively dead since the development of 4.5.1a.

[MasterChief]

but would like to see more emphasis ... on accessibility

With the presentation layer separate from the code this is no longer an issue. Since the 'html' is no longer buried in the php the emphasis is put back on the html designer to get the output right. So don't think of X-Mambo, think of X-Templates. Mambo will just spit out what it's told to.

[mambosolutions]

on the fringes of this topic, how about including a set of site templates in the core that match in look and feel and cover a general range of purposes like a 'business' design, a 'gamer' design a personal home page' design etc...

i think this might add to the userfriendliness factor for mambo new users...

I am thinking only 3 or 4 to keep the overall size of Mambo down..


thoughts?