#257 ✓ invalid
Zdravko Balorda

Template elements

Reported by Zdravko Balorda | May 16th, 2011 @ 05:23 AM

The system of elements ni very powerfull. I wish it could be extended to templates, too, so that elements could be assigned to templates in much the same manner as they are assigned to stories.
Like for a story, there would be $template global, and for template element perhaps $templment?!
The values would be site specific (or Mason-like category specific) while if undefined the default could be inherited like the template code is.
This would provide for something called modules in other systems only zillion times more powerfull.
People could write pieces of templates which could be configured and assembled in a number of different ways. It would allow for high level of code reusability. One could load say, a Facebook interface via SOAP, install it by attaching to his own higher level elements, configure it and start using it. The compexity would be removed from users, who would need only to attach some "Facebook flag" signalling the template to display this element. And I can think of many many more complex usage.

I wonder what do you think. Regards, Zdravko Balorda.

Comments and changes to this ticket

  • theory

    theory May 16th, 2011 @ 04:33 PM

    • Tag set to element, template

    I am confused. There are three kinds of templates:

    • Element templates are associated with elements. They can be top-level document (story or media) elements or subelements.
    • Category templates wrap the execution of element templates
    • Utility templates are unaffiliated templates you can use for libraries of commonly-used functionality.

    If I read your message properly, element templates already do exactly what you want. The $element variable in an element template is the element for that template.

    Am I missing something?

  • Zdravko Balorda

    Zdravko Balorda May 17th, 2011 @ 05:50 AM

    Yes, they do. I wish the elements could be attached to a template, and the values populated from a template, as it works for story. One could then patch the template, too, not only a story. Beside defining a (different) site based template structures, template elements could be also configured on a site basis. In short, the functionality of elements on stories, which is left to writers, could be offered to designers, too. The thing is that there are many elements on a web page that are outside the scope of the story. Thus, all of them needs to be hardcoded. And anything you do is hardly ever reusable.

    In short, the top level element would also be a Template.

  • theory

    theory May 23rd, 2011 @ 04:43 PM

    The top-level element does have a template: It's the only element type that's required to have a template.

    If you want to provide a way to manage non-content stuff, you can. For example, for some clients I've created a "Nav" story type in which folks can manage elements that define the structure of navigation menus. The template for that type then outputs an include file that other story templates just emit a link to.

    Anyway, I'm sorry, I think I'm still not really understanding what you're asking for. Maybe you could post to the list and explain what you would ideally like? It's possible that what you're thinking about is already there…

    Thanks,

    David

  • Zdravko Balorda

    Zdravko Balorda June 24th, 2011 @ 11:16 AM

    No, this time it's not there. :)

    If it were, there would already be several predefined template patterns, navigation menus, and a number of different plugin modules, like joomla and Drupal have, only useful, too...

    Zdravko

  • theory

    theory June 24th, 2011 @ 04:36 PM

    • State changed from “new” to “invalid”

    There are some here and here. Bricolage does not ship with very good templates, but there are a number of patterns that have developed over the years. Someday, someone will have the tuits to add some decent ones to the shipping product.

  • Zdravko Balorda

    Zdravko Balorda June 27th, 2011 @ 05:44 AM

    Maybe you'll come to this some other time. I have 20 sites built by now, using this concept, from the same set set of templates. That's why I consider the concept to be proven and I dared to suggest the right way to incorporate it. I'd love to defend this further if you let me, as I believe it would make a great improvement.

  • theory

    theory June 27th, 2011 @ 04:58 PM

    You may well have a great pattern here. I just have not been able to understand what it is, or whether it's already there.

    By design Bricolage ties templates very closely to elements. But they are not tied closely to each other except to the extent offered by the templating engine.

    I'm sorry, I just have failed to understand. :-( Maybe if you post your idea to the list someone else will?

  • Zdravko Balorda

    Zdravko Balorda June 28th, 2011 @ 08:36 AM

    Well, I've got more from Bricolage than you have designed it for. That's how good the design is! Unfortunately my implementation is not shareable. Doing this I have find out that if templates were treated like stories, in a sense that one can Add Element to a template too, it would make a great difference. If there was an Add Element button, this would provide for "tying elements to each other", as you put it, above. Everything else could stay the same, apart from new global variable $template_elements. The rest are implementation issues, like having site/(category) specific element sets, while the code stays output channel specific, etc...

    The thing is, that for any HTML, it seems that hierarchy and element order is enough to completely define a DOM. And that's what Element type provides for: ANY structure. That's all there is. Nothing engineously rediculous. :)

    If anything is unclear, please ask. Even if you understood it all, the idea could still not be very useful, though.

    Best regards, Zdravko.

  • theory

    theory June 28th, 2011 @ 04:23 PM

    Can you explain to me how, exactly, you associate a subelement template with another template in the UI, and what that causes to happen during the burn?

  • Zdravko Balorda

    Zdravko Balorda June 29th, 2011 @ 05:28 AM

    We need a new top-level element Template, like Story. Only it would be associated to template workflow, and deployed instead of published. The content would be the template code, and elements would be assigned just like they are assigned to stories. autohandler.mc would be the contents of this top-level Template element (let's name it Autohandler), to which other elements are attached.

    For the sake of simplicity, let's say that autohandler.mc contains:

    $burner->display_element($_) foreach ($template_element->get_elements);

    To Autohandler a yui_grid element would be attached, containing head, tail, hand and body.
    These elements would have their own subelements, say, head would contain top_menu. Etc.
    This of course would go further and it requires careful DOM decomposition. Probably other DOM decomposition exists, too, so yui_grid would be just one of them. Anyway, all these would be called via $burner->display_element interface.

    Body element would at some point call:
    $burner->chain_next(); which will burn the story itself.

    Could this work?

  • theory

    theory June 29th, 2011 @ 04:27 PM

    Could this work?

    I suppose, but I don't really see what it gains you over using utility templates and something like:

    $m->comp("/util/$_") for qw(head tail hand body);
    

    Except that there's a UI way to create those relationships. AFAIK, template developers tend to be coders, and so they think about things in terms of writing code, rather than in terms of assembling content.

    Best,

    David

  • Zdravko Balorda

    Zdravko Balorda June 30th, 2011 @ 05:51 AM

    If you put it this way, not much. My thinking goes toward setting up a template whith less or no programming. And toward having reusable components. The above can be programmed, Bricolage can still be used as before, but by using elements one can simply change settings, and reuse the code on another site.
    By moving an element one can also move the content, which comes handy many times.
    Changes to template can also be done by other people who think content, not just by professional programers. Bricolage being static can benefit from using potentialy complicated modules.

    All that joomla and drupal claim to have. IMHO, it would be much more powerful in Bricolage.

    Thanks for hearing me, Zdravko.

  • theory

    theory July 1st, 2011 @ 05:24 PM

    If you put it this way, not much. My thinking goes toward setting up a template whith less or no programming. And toward having reusable components. The above can be programmed, Bricolage can still be used as before, but by using elements one can simply change settings, and reuse the code on another site.

    Yes, but you can do this with elements already. That's precisely what they're designed for. Templates are designed to be closely associated with elements. So once you create an element and the template(s) to output its content, you can use it in any document type you like and get its functionality.

    By moving an element one can also move the content, which comes handy many times.

    Don't understand what this means.

    Changes to template can also be done by other people who think content, not just by professional programers. Bricolage being static can benefit from using potentialy complicated modules.

    Yes. And this is exactly what document elements are for. If you think about it, templates are an implementation detail for elements. That's it. Document elements are the thing.

    All that joomla and drupal claim to have. IMHO, it would be much more powerful in Bricolage.

    Someone else who is familiar with those CMSs would have to comment on this; I've used Drupal a couple of times, but don't really know how to "think in Drupal."

  • Zdravko Balorda

    Zdravko Balorda July 4th, 2011 @ 06:02 AM

    Obviously we don't understand. Yes that's what elements do. But they do it at the story level. That is in the context of the story, which is a small peace of the web page. The template defines everything else. One can not put a menu subelement as a part of a story, for instance. I hope you see the difference. The idea was inspired by Bricolage Elements, actually. Only I wish they were expanded to templates too, so that they could be used generally, from top to bottom of the web page. Like left navigation menu: you can't attach it as a part of a story! But you could use it as a part of the overall template.

    So, yes elements can do that already! Exactly! But they can be used only by story writers. If they could be applied in the same way to autohandler itself, it would greatly expand their usage. That's why I'm saying templates should have that "Add Element" button by which one can hang the whole page structure and its content to it. And that are exactly the same elements the Bricolage already have! Only this structure would be than be applied to all other stories on a site.
    So, I'm not changing anything about elements. They are perfect! Just wish there were Add Element button on template profile page, like there is on a story profile page. So you can play with the structure and the content of the whole page via UI, istead of writing new code time and again.

  • Zdravko Balorda

    Zdravko Balorda July 4th, 2011 @ 07:27 AM

    Maybe I am begining to see the clouds around my words, here. :) What I am talking about is a top level element Template (like Story), and Autohandler being an instance of that element type... I see now. This Autohandler would be assigned to template workflows. Its content would be autohandler.mc, and subelements would be added like they are on stories.
    ... You've got me here. :)

    Maybe there is a better way to implement this.

  • theory

    theory July 6th, 2011 @ 03:41 AM

    Okay, now I understand what you mean. But I never really thought about Bricolage that way myself, because Bricolage is not a content delivery server like Drupal. How I've done the sort of thing you're talking about is to create media documents that make up things like menus, and publish them as files to be included by the delivery server. Usually that meant developing the PHP files for various parts of the site (menus, etc.), and publishing them. Then the templates include those files on the front-end server.

    On another project, we published to Drupal. The templates just publish the stories to the Drupal server, and the Drupal Bricolage plugin integrates that content into the overall look and feel of the site.

    In both cases, Bricolage, not being the content delivery server, does not provide any of that stuff, though it can be used to manage the code for it (which has its advantages and disadvantages). One way in which I have done something like you suggest, however, is to create, for example a "Nav" story type. Its elements are set up so that an editor can add "Section" subelements, and "Link" subelements. The template then generates the HTML to represent the menu and publishes it as an include file on the delivery server. Then when it's served up, it gets rendered by JavaScript and CSS as necessary.

    So I think you could do something similar to what you're talking about in Bricolage. And yeah, maybe there's a place for that as "template elements." But I personally really don't see it, since all it would do is add include calls to the autohandler, and IME this is almost always done by a coder anyway.

    At any rate, interesting discussion, I appreciate it. And if you were so motivated to work up a proposal for how this would work, get it approved by the dev list, and write the patch, well, I'm always inclined to accept something in the product when someone has worked hard on it.

    Best,

    David

  • Zdravko Balorda

    Zdravko Balorda July 6th, 2011 @ 06:37 AM

    I could easily see how one would add a menu element, fill in related media images for button backgrounds, etc. Or how one would add a link_list element, fill in all the URL and shovel it onto the top of the page. Or just below some image (being related media). And so on. Any combination can be conviniently represented by a Bricolage Element structure. Templates would then interpret this structure while building html and calling display_element when appropriate. A story would then continue by calling chain_next() at some point.

    Templates then can stay the same, and be reused by another site, where the page has different structure, different elements. This would be the goal of such a system.

    You are right one could do the thing in Bricolage. I have done it. :) It's just it works for me, only.

    One thing, though: I've learned how to go around approving probable bugs and fixes.
    See you guys. Bricolage rules! ;)

    Best regards, Zdravko

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

People watching this ticket

Pages