template hierarchy in 0.8 blog site

[unny]

For what it is worth, I drew the "template map" of the default blog site in zotonic 0.8 and have attached it with this message. Please let me know of errors and omissions. Hopefully it will be of use to some of you.

[Arjan Scherpenisse]

Nice map!
This is definitely useful for people who want to build upon the default
blog site or just want to get an overview of which templates are used.

Maps like these could actually be generated as well, since it's
basically tracking {% extends %} and {% include %} blocks.. :)

Arjan

[ll...@writersglen.com]

Hi Unny,

 

Nice work.

 

This map tells me something that I've been feeling for some time now: templates are fine for relatively simple sites.  But for sites with complex grids they become increasingly difficult to manage. Maybe it's just me, but have the feeling that there's got to be a better way.

 

All the best,

 

LRP

[Andreas Stenius]

I think that the templates as is works great. What is lacking is organization and documentation.

I feel that simply dumping all templates in a single folder leaves little more than a mess, at best; when there's more than a handful of templates. Take then that you can inherit and override templates from a big heap of such buckets of templates... I get your point, Lloyd :)

From a technical point of view, I find it is perfect, we only need to find some structure to it.
Some structure with regard to the end users device is taking shape by introducing the tablet, phone, text, etc sub folders in the template directory, but more can be done regardless of the end device - by categorizing the templates into folders based on their use and place in the templating world.

Something like (not taking the device class into account here, that would simply be at the top of the tree, for each class):

templates/
 base.tpl
 ... and any other top-level class templates, if any

 pages/
   home.tpl
   search.tpl
   about.tpl
   page.tpl

   common/

     _sidebar.tpl

   article/
     article.tpl
     _article_keywords.tpl
     _article_sidebar.tpl

    

   collection/

     page.collection.tpl

     _collection_sidebar.tpl

  ... etc

I think this would make it easier to navigate, comprehend and find the pieces you want to edit...

//Andreas

2012/5/16  <ll...@writersglen.com>:

[Dmitrii Dimandt]

This reminds me:

http://groups.google.com/group/zotonic-users/browse_thread/thread/df99fc5f9561ce27/20ec190edea26cce?lnk=gst&q=dmitrii+dimandt+include#20ec190edea26cce

Skip the entire message and start reading at "If the site is quite large, you will end up with lots of templates" :)

[Andreas Stenius]

Nice (but it would've been easier to find that sentence with this link: https://groups.google.com/d/msg/zotonic-users/35n8X5Vhzic/4OoMSmncWHQJ )

I think if we get away with being able to include "article/sidebar.tpl", that'll do just fine :)

Haven't tried if this is already supported or not...

//Andreas

2012/5/16 Dmitrii Dimandt <dmi...@dmitriid.com>

[Arjan Scherpenisse]

Also, the "catinclude" methodology already introduces organisation.

I often structure templates the following way:

page.article.tpl
page.person.tpl
page.tpl

When including a template with the option {template, {cat, "page.tpl"}}
it will take the category of the page into account and use that to
lookup the most specific page.tpl variant.

This naming convention is already very helpful.
For instance see the Miraclethings site's template folder:

https://github.com/arjan/miraclethings/tree/master/templates

Arjan

> 2012/5/16 <ll...@writersglen.com <mailto:ll...@writersglen.com>>:

[Andreas Stenius]

That is good for keeping things organized, indeed. However, it is limited to the resource category.

I'd like a little broader perspective (and that the catinclude brings structure to the templates directory is more of a side effect, in my opinion).

//Andreas

2012/5/16 Arjan Scherpenisse <ar...@scherpenisse.net>

[ll...@writersglen.com]

Hello,

 

Logical structure of template names and files definitely helps.

 

As a content guy, however, I find the more complex templates visually noisy and distracting; e.g. the mix of <blip> {% blop %} tags obscures content, making it difficult to envision what the page will look like and particularly difficult to proof read. Of course I can flip back and forth between the template source and the rendered browser, but that adds just that many more clicks and disruptions to the creative work flow. I suppose, I could support two monitors at the cost of greater hardware investment, configuration complexity,  and desk space. And care in how clauses in the template are arranged in the source definitely helps.

 

But why not let the computer do the tedious and error-prone stuff that computers do so well and provide an interface that allows the human developer to be as efficient and creative as possible?

 

There's an understandable and unavoidable tension between the needs and perspective of the page designer (graphic design), the content developer (text), and the html coder (templates and tags). A successful site requires all three perspectives. Development teams that have distinct division of labor can set up effective work flow to by-pass the problem all together. But many of us work as an "army of one---" creating content, designing the page, marking up the copy, and proofing the result. Aside from whatever skill we bring to the job, time is the most crucial asset in our inventory.

 

So, I'd argue that templates as now deployed, are a useful and necessary step toward a more effective tool for producing excellent websites. But I'd further argue that the evolution toward the most efficient tool possible should not stop with templates. Perhaps what could be considered is a set of extensions or even separate tools that maximize human productivity and creativity.

[Andreas Stenius]

Hi Lloyd, and others,

As a content guy, you wouldn't need to look at the templates, and get distracted by the blip's and blop's, which by the way shouldn't be content, in them selves. Proof reading ought to be carried out in the end result (the rendered web page, or whatever resource is generated from the template) rather than in the template itself. As it will also hold the content to be proof read, which is only represented by blip's in the template.

But, as you say, being a man of many hats, you may end up as a coder guy writing templates. Content shouldn't be of an issue under this hat.

Granted, there are plenty of room for better and more feature full tools to aid the development from idea through templates and design to a finished end result.

In the final conclusion you write "I'd further argue that the evolution toward the most efficient tool possible should not stop with templates" is far more positive towards using templates, than the "[...] that there's got to be a better way [than using templates]" that spur off this discussion. Maybe I mis-read your initial message... or have you re-evaluated and simply looking for a improved tool set (of which templates is a part)?

I am all for more effective tools. As I see it, they would fit on top of the existing technology of templates, dispatch rules and modules (and the rest of core zotonic).

I like your distinction of roles for graphic design, content developer and template coder. Although, I feel that the graphic designer has very little actual work to do in the end product (zotonic, or whatever technology is used to actually produce the pages); rather, the graphic designer would use some illustration tool to create mockups that show how what the resulting pages should look like - and it is then the coder that will make that happen (and the content creator to fill the pages with content). How far off am I?

So, if I'm not too far off, from zotonic's perspective, there is rather two roles to accomodate, that is, the coder guy (for html/template/css) and the content guy (working in the web gui).

The content guy currently has the admin interface to manage resources (pages, media files, etc). 

The coder guy currently has to rely on external tools to produce the text files that should end up in the zotonic directory tree. 

I'm comfortable enough with this setup to not being able to see what the next step would be to improve this. 

I do day dream about having an easy way to generate html/template code for forms and other layout stuff.. but it's not really concrete yet.

Cheers,

Andreas

2012/5/16 <ll...@writersglen.com>

[ll...@writersglen.com]

Hi Andreas,

 

I hope folks don't take my comments as criticism of Zotonic. I'm a great fan. My comments are meant as food for thought as Zotonic evolves. The thing about creativity is that you can't really predict what the end result will look like. And the more ideas going into the process, even nutzo ideas, the more likely a true break though will emerge.  Is Zotonic as good as it can possibly be? Will it look the same a year from now? Three years from now. I doubt that even Marc or Arjan would argue that it will.

 

All the best,

 

Lloyd

[Andreas Stenius]

Hi Lloyd,

Likewise, I hope my reply didn't come across as too harsh. I value all ideas, and encourage everyone and anyone to participate that has a wish to improve and extend zotonic.

Perhaps my wordings was a bit defensive. That was an unintentional effect of my lack of expressability (in search for a better word, and failing, making up words instead, I'll stop now ;)

//Andreas

2012/5/16 <ll...@writersglen.com>