YAML template

YAML template

Postby coldtobi on Tue Aug 21, 2007 4:09 am

I made a template set using the YAML Layout Framework. (see http://yaml.de for details)

If anyone is interested, please see http://blog.coldtobi.de/1_coldtobis_blog/archive/106_yaml_template_sets.html

Comments, Bugs, Ideas are welcome!

Tobi
coldtobi
 
Posts: 32
Joined: Fri Jun 08, 2007 5:28 am
Location: Germany
LifeType Version: 1.2.7

Postby phunkphorce on Tue Aug 21, 2007 3:54 pm

This actually looks pretty interesting. We have had some discussions going on for a long while regarding creating a "master" template, and this looks to be pretty close to it. I just have a couple of questions/comments :)

I am thinking that if we placed this in the templates/default/ folder, all we would need to do is adapt the CSS file to get the desired layout, right? One option would be to call this the "standard" or "default" template for LT 2.0 and try to port the current templates to this layout, do you think we can reimplement the existing ones into YAML? Would it be a lot of work?

One problem I see with your implementation is that there are way too many files. While we have achieved significant simplification of the template logic with these changes, now customizing things has become slightly more difficult because it's not so easy to find things anymore. Could some of the render_xxx.template files be moved back to the place where they're really used? I for example see no use in having for example render_album.template as a separate file while in fact, its contents can only be used in one place (that is, albums.template)

I think we're on the right track with this, it just needs need some polish :)
phunkphorce
Lifetype Expert
 
Posts: 9028
Joined: Mon Aug 25, 2003 6:34 am
Location: Suomessa

Postby reto on Thu Aug 23, 2007 4:59 pm

Hi tobi
You've worked out an interesting approch to integrate yaml into LT, good job!

Althogh I'll need to take a closer look at your work I agree with oscars suggestions. Plus, you have implemented yaml 2.5.x, right? unfortunately the yaml author has just release version 3.0 which has lot's improvements in terms of modularity. I'd like to see yaml >=3.0 in LT 2.0.
reto | wiki | Downloads
reto
Lifetype Expert
 
Posts: 395
Joined: Sat Apr 17, 2004 12:34 pm

Postby Nomad on Thu Aug 23, 2007 6:35 pm

I still think as well that we need to do more to standardise the templates. I downloaded the current package the other night (For LT 1.2) and some use panel.template, some use links.template - one is a total anomaly all together -> andreas-3-columns and a couple are using the footer with the nav structure in.

If we had a basic standard for the nav structure then plugins could be enabled without the need for editing the template sets for the plugin to display. such as tag cloud for instance - this could then be implemented at post time and would be inserted into the template. Using a standard css div and class structure ie. if we stuck to say div="sidetitle" for the div and then say class="sidetitlenav for the navigation.

As each template set has it's own css file styling would be only affected from there and the plugin could then use the same class structure for display. This would mean the plugin would display with the same style as the rest of the navigation. how the order of the structure would be made I don't know but with a standard set up instead of the numerous styling structures and naming structures we have at the moment.

I'm all for 'Custom' templates but I do think that certain areas should be standardised and those standards be followed so as to implement a far easier plugin system, as I say so the plugin is simply enabled in the control center and the user then has that plugin displayed in there choice of template without the need for the template then to require any form of editing on behalf of the end user or indeed the Administrative user of the system.

I think I've mentioned this before and whilst I love LT (Heck I've used it since 0.3.20 I do think it is the one area where it is let down. I dunno I just think it would be a far easier way to handle the plugins and far easier especially for the end user...
Blog Ireland - now with video posting
Normally most write something meaningful here so many to choose from yet most oft ignored.
Nomad
Lifetype Expert
 
Posts: 645
Joined: Sat Feb 05, 2005 8:40 pm
Location: Eire

Postby coldtobi on Sat Aug 25, 2007 2:15 pm

I was too busy the last days, so please accept my apologizes, that I did not answer already.
If now have only 1/2 hour, so I start now, and maybe finish tomorrow....
(So I will now focus on topics easy to answer)

But thanks for the feedback!

YAML 3.0
Yes, I saw this... I think I am a magnet to this. YAML 3 was released some days after I finished this. I just did not get time to look at the changes,but my plans are defintily to push the version..

phunkphorce wrote:One problem I see with your implementation is that there are way too many files. While we have achieved significant simplification of the template logic with these changes, now customizing things has become slightly more difficult because it's not so easy to find things anymore. Could some of the render_xxx.template files be moved back to the place where they're really used? I for example see no use in having for example render_album.template as a separate file while in fact, its contents can only be used in one place (that is, albums.template)



Well, this was one "goal" for me to seperate all the "objects" (content) into different renders, to make it more easy to find "where" to adapt the changes. Ok, at some places, it might be really overkill (the album), but I wanted to keep it clear, easily identifiable the content by the filename.
Moving the album back would be ok, but on the other side, the "central layout document" would be bypassed, which I think, should be avoided.

I think we're on the right track with this, it just needs need some polish :)


Defintly. See my package as a "working draft". Nothing is final, and everthing needs some polishing.
coldtobi
 
Posts: 32
Joined: Fri Jun 08, 2007 5:28 am
Location: Germany
LifeType Version: 1.2.7

Postby coldtobi on Sun Aug 26, 2007 4:50 am

Nomad wrote: I still think as well that we need to do mo(...)
(shortened to avoid full quote)

ja. it is a mess and one reason of implementing the set "how I did it", First I tried to make my template by modifing an existing one. But I did not get the complete overview how the template works, even after hours. There is simply no structure and not really straight forwarded.

I could imagine, that my approach also can ease the integration of most plugins in an easy way: Every package could also install a renderer which will be then sourced. Condidtional smarty will do the rest then.
coldtobi
 
Posts: 32
Joined: Fri Jun 08, 2007 5:28 am
Location: Germany
LifeType Version: 1.2.7

Postby Nomad on Sun Aug 26, 2007 11:35 am

coldtobi wrote:
Nomad wrote: I still think as well that we need to do mo(...)
(shortened to avoid full quote)

ja. it is a mess and one reason of implementing the set "how I did it", First I tried to make my template by modifing an existing one. But I did not get the complete overview how the template works, even after hours. There is simply no structure and not really straight forwarded.

I could imagine, that my approach also can ease the integration of most plugins in an easy way: Every package could also install a renderer which will be then sourced. Condidtional smarty will do the rest then.


I don't know - I don't see the structure as a mess just the many templates not keeping to a standard. I remember reading about this when I first started using LT when it was pLOG a few years ago now and the directions given then was to help conform to a certain way of making the templates but seems as if a lot never took much notice when building there custom templates which is one of the best things about LT, the ability to do that.

Personally I think that the only files that need to be in the template folder are -> the css, the images for the template and only the files that are needed to construct the xhtml.

Any file that is just smarty code such as say post.template, features.template, posttrackbacks.template etc etc should be in the default folder and then irrespective of the template these can remain standard. They can still be individually styled but that would be done via the template css.

for instance post.template from fblue

Code: Select all
<!-- {$url->postTrackbackLink($post)} -->
{assign var="postDate" value=$post->getDateObject()}
{assign var="postOwner" value=$post->getUserInfo()}
   <div class=entry>
      <h3 class=entrytitle><a href="{$url->postPermalink($post)}">{$post->getTopic()}</a></h3>
      <div class=entrybody>
         <p>{$post->getText()}</p>
         <div class=entrymeta>
         {$locale->formatDate($postDate,"%m/%d,%Y")}
         {foreach name=categories from=$post->getCategories() item=postcategory}
            <a href="{$url->categoryLink($postcategory)}">{$postcategory->getName()}</a>
         {if !$smarty.foreach.categories.last}, {/if}
         {/foreach}
         </div>
      </div>
      <p class=comments_link><a href="{$url->postPermalink($post)}#comments">{$locale->tr("comments")} ({$post->getNumComments()})</a></p>
   </div>


If all templates used that post.template I can style it anyway I want in the css - it just means I give different values in say flblue than what I would in say ice, or standard or even if I'm building my own template say.

This is actually a principle I learnt at csszengarden - they have many templates there or styles - the html for all the styles is exactly the same. In fact they are very specific about this (This is when they used to allow site styling submissions - I don't know if they still do??) - what this means is you can do anything to a template via the css and from what I can see of yaml - that is working on the same principle.

What the end result is in that is (Especially for the developers) that a standardized structure is achieved. It also means plugins (My main part of the discussion) can be easily more implemented especially if we only have to deal with editing one template held in the default folder. So say I want to or need to change a bit of code so tag cloud runs better - instead of like we do at the moment having to edit every single template sets nav structure all that is needed then is to edit panel.template in the default structure and the change will take immediate effect globally.

Currently we have some thing like 70templates (If you include the ones not packaged in the default download) that a lot of editing each time it is required and not all templates use panel.template. Some are using links.template - some footer, some even have the nav in the header etc etc.

So the way I see it is the more we can use the default folder and the less we have in the actual template folders and that they follow a more stricter pattern in naming of div id's and class elements then the more easier it will be to work with them - essentially a few edits of a css file and voila - a new template or adjustments could more easily be made to suit.

I've actually just downloaded the latest copy of 1.2.4 from source forge and have already started to change all links.template to panel.template. The ones using the footer.template - I'm going to strip the nav out and place it into a panel.template. This will have no effect on how the template renders or displays but will give a step towards making the templates more of a standard compliancy. After I have that done I'm going to set about making the default naming for the nav structure in them to sidetitle for the main div and sidetitlenav for the class so I will be left with one standard panel.template change the css to match and then (hopefully) test it will work . I may even place the panel.template then into the default folder and see what happens...
Blog Ireland - now with video posting
Normally most write something meaningful here so many to choose from yet most oft ignored.
Nomad
Lifetype Expert
 
Posts: 645
Joined: Sat Feb 05, 2005 8:40 pm
Location: Eire

Postby phunkphorce on Sun Aug 26, 2007 12:15 pm

One of the things that worries me now is that if we switch to YAML, we either drop the current templates or reimplement them as YAML templates, which probably is a lot of work.
phunkphorce
Lifetype Expert
 
Posts: 9028
Joined: Mon Aug 25, 2003 6:34 am
Location: Suomessa

Postby coldtobi on Sun Aug 26, 2007 1:48 pm

I think, it is neighter feasible nor necessary to drop the support for the current templates and change solely to YAML. I'd prefer to see this as "adding value" to lifetype, not reinventing everything.
(And anyway, not everyone will be glad about YAML, as this is considered by some as "non free", because of the license requirements (invariant sections).


phunkphorce wrote:One of the things that worries me now is that if we switch to YAML, we either drop the current templates or reimplement them as YAML templates, which probably is a lot of work.
coldtobi
 
Posts: 32
Joined: Fri Jun 08, 2007 5:28 am
Location: Germany
LifeType Version: 1.2.7

Postby Nomad on Sun Aug 26, 2007 3:44 pm

phunkphorce wrote:One of the things that worries me now is that if we switch to YAML, we either drop the current templates or reimplement them as YAML templates, which probably is a lot of work.


I agree with coldtobi on this and what they say and anyway I adore some of the templates we have already :)

This is why I suggested that maybe we could implement a two tier system. A custom templates section where templates like what we have already exist and function as they do now but drawing on the abilities of the default template to reduce load or size.

Then a new system that uses either yaml or something similar which we could control the standard of more and make it more functional in the terms of say my favorite subject plugins implementation [ ;) ] - also making it easier for non-technical users who can't code to be able to 'Customise' the template somewhat.

BTW have you ever heard of SUE? It works along side grease monkey apparently and is used a hell of a lot on stumbleupon (I got that functioning btw :D ) SUE is some sort of css thing which I haven't as time yet to look into fully.

I don't know - I think theres a few options and as Reto said earlier building on the already worked upon framework of the default template I think is the way to go but with a more stricter standard compliancy which as I've already explained has a much more versatile platform option in what we can implement (I.E. Again - me with the plugins lol ;) )

overall though I wouldn't want to lose any of the existing templates, well not immediately and over time they could be migrated across to yaml and then once thats done - we could drop the original template format.
What I would see is that yaml be introduced as the way forward as part of the default system template system but that could then be customised to what the end user wants/requires. Eventually migrate the existing templates across to that system and then move on from there.
Blog Ireland - now with video posting
Normally most write something meaningful here so many to choose from yet most oft ignored.
Nomad
Lifetype Expert
 
Posts: 645
Joined: Sat Feb 05, 2005 8:40 pm
Location: Eire

Postby phunkphorce on Mon Aug 27, 2007 1:23 am

My idea would be to either switch to YAML or to stick with the current system because of support issues and documentation. Having two different ways of doing things simply adds unnecessary complexity, and too many choices tend to confuse new users...

About the license of YAML, that's a good point and I need to see if it's compatible with the GPL (or else we can forget about it)
phunkphorce
Lifetype Expert
 
Posts: 9028
Joined: Mon Aug 25, 2003 6:34 am
Location: Suomessa

Postby coldtobi on Mon Aug 27, 2007 6:30 am

Do you have a link to "SUE"? I didn't find it on google..
coldtobi
 
Posts: 32
Joined: Fri Jun 08, 2007 5:28 am
Location: Germany
LifeType Version: 1.2.7

Postby Nomad on Mon Aug 27, 2007 7:02 am

coldtobi wrote:Do you have a link to "SUE"? I didn't find it on google..


ah I see what it is - ok SUE is actually an extension for stumbleupon... just found it here http://sue.sentientdesign.co.uk/

It works with 'GreaseMonkey' which is an extension for Firefox I believe..

article in wiki about it http://en.wikipedia.org/wiki/Greasemonkey and thsi seems to be the main homepage http://www.greasespot.net/

Looking over it I don't think in hindsight that we could use it, anyway was just an idea - no harm in mentioning it I suppose

:)

@phunkphorce In a sense though with the way the default template is being implemented we can develop a principle similar to yaml - that way we could allow end users to add some customization to templates.

in essence we already have a two tier template system. We have the template that a new user selects when first joining a system but then we have a system where that user can upload there own 'Custom' template. Maybe we could change how that functions? So instead of them uploading a custom template set, they can construct it via an interface online?

I think that would be fairly simple to implement and here we would use three basic blanks, header/two column - left nav /-/ header/two column - right nav /-/ header - three column - left/right nav

So they select a template type blank

Then that is styled by a template style control panel where they select different options to construct the style. Once they save that it constructs a css file (Maybe the css data could be held in there user account in the database?? A visitor go's to there page/the system displays the Template blank they have chosen which is only in essence one of three values and the css style data is then applied.

That option is similar to how yaml works - I think? plus we could put the plugin code into all the default blanks and they then only show if the plugin is enabled by the user.

complicated to set up maybe but an option that gives the end user more control over how there blog looks to the outside world...

edit: And utilizes Reto's idea on maintaining development of the default template system which I tend to agree with...
Blog Ireland - now with video posting
Normally most write something meaningful here so many to choose from yet most oft ignored.
Nomad
Lifetype Expert
 
Posts: 645
Joined: Sat Feb 05, 2005 8:40 pm
Location: Eire

Postby reto on Tue Sep 04, 2007 4:43 pm

The YAML License (CC-A 2.0) is not compliant with the GPL and therefore we can only provide "yet another template for LT based on YAML" but not use it as the default (technically) template.

edit: maybe we should use yui grids instead?
reto | wiki | Downloads
reto
Lifetype Expert
 
Posts: 395
Joined: Sat Apr 17, 2004 12:34 pm

Postby coldtobi on Thu Sep 06, 2007 7:39 pm

reto wrote:edit: maybe we should use yui grids instead?


I'll take a look at it after my honeymoon vacation....
coldtobi
 
Posts: 32
Joined: Fri Jun 08, 2007 5:28 am
Location: Germany
LifeType Version: 1.2.7

Next

Return to Templates

cron