Siviglia Templating and Bootstrap

I've been looking around for some nice, simple UI framework to implement as a base widget library for my Siviglia templates project, and include it in the distribution.
To keep the spirit of the templating system, this is a dual process.The  first problem to solve is finding a good set of abstractions used in web UI development.
There are a few obvious abstractions, like "page", "header", "footer", "menu"...Those concepts will be the widgets to implement.
Then, for those widgets, there could be many different implementations, using different frameworks.
But, as long as templates are expressed in terms of those abstractions, they'll be independent of the implementation of those widgets, so simply changing the widget include path, the whole UI could be generated using a different framework.

The Boostrap UI framework is a simple, nice looking UI framework, and makes it an ideal candidate for a first implementation. And, what it's also important, it's to use the names ("abstractions") it uses for some common elements found in web page design, like the "Carousel Jumbotron" .

The carousel is a set of images, of which only is visible one at a time.It could include some sort of navigation between those images, and some content associated with each one.
When building a template for your PHP site, that's all the detail you should give to the underlying widget.How  the navigation is managed, where the content is shown, etc, it's defined by the widget.
Of course, you could create a few carousel widgets.One with a thumbnail navigation, other with text links...
The important thing, in the end, is that reading the template should give an inmediate idea of what's going on in the page.
For the  "Carousel Jumbotron" example, the template should be something like this:

[*PAGE]
    [_CONTENTS]
         [*/MENU/BAR]
               [_ITEM][_LABEL]Project name[#][_LINK]...[#][#]
               ....
         [#]
         [*/CAROUSEL/JUMBOTRON]
               [_ITEM][_IMAGE]....[#]
               [_CONTENT]
                     [*/PARAGRAPH/TITLED]
                           [_TITLE]Example headline[#]
                           [_CONTENT]....[#]
                     [#]
               [#]
               ....
         [#]
     [#]
[#]

Creating the template in this way, helps you to separate what you want to have in the page, of how you'll implement it.And that's what i mean with "templates expressed in abstract UI concepts".

There are a few more UI abstractions used (and named) in Bootstrap.If you have more ideas, please comment about it!

Siviglia Templating Published

I've finally published a first version of my templating system for php , Siviglia Templating.
But, despite the code is relatively new, the idea behind is something i've been working on for some years now.This implementation is the first that fullfills all the requisites i wanted for it.
There's a manual with examples that i hope is enough to get started, but, after some years building web sites based with it, i'd like to share some advanced uses of the template system, not covered in the manual.

As you can use a widget path to define where the system will look for the widgets used in a template, you can have different paths for different user agents (full-blown browsers, mobile browsers, search engines), output types (html, json, xml) or any other criteria (skins, language...).
You can combine this with the way the engine works when a certain subcomponent of a widget is not specified, or doesnt exist..
For example, suppose you have 3 news boxes in your homepage.Your template may look like this:




[*PAGE]
    [_CONTENTS]
          [*HOMEPAGE_NEWS_CONTAINER]
                   [_NEWSBOX1]...[#]
                   [_NEWSBOX2]...[#]
                   [_NEWSBOX3]...[#]
          [#]
     [#]
[#]

Now, you want to have a version for mobile devices, that only displays the news box specified in NEWSBOX1 in the homepage.

You could do it like this:




[*PAGE]
    [_CONTENTS]
          <?php if(!$deviceIsMobile) {?>
          [*HOMEPAGE_NEWS_CONTAINER]
                   [_NEWSBOX1]...[#]
                   [_NEWSBOX2]...[#]
                   [_NEWSBOX3]...[#]
          [#]
          <?php } else { ?>
          [*HOMEPAGE_NEWS_CONTAINER]
                   [_NEWSBOX1]...[#]
          [#]
          <?php } ?>
     [#]
[#]

The problem with this approach is, not only that it's a bit uglier, but also, you'll have to code the HOMEPAGE_NEWS_CONTAINER widget to work well if all three or only one of the newsboxes are specified.
An alternative solution, is to create two different HOMEPAGE_NEWS_CONTAINER widgets, stored in the same relative path, but in two different folders.And to leave the template device independent.

The device detection code now is moved to the template engine initialization.




  ....
  /* You'll need a different cache file for each kind of device. Specify a file name
     for the cache file, and specify it along with the TEMPLATE definition */
  if($deviceIsMobile)
  {
     $widgetPath=array("/widgets/mobile/");
     $cacheFile=....;
  }
  else
  {
     $widgetPath=array("/widgets/nonMobile/");
     $cacheFile=....;
  }
  $widgetPath[]="/widgets/common";
   
  $oManager=new CLayoutManager("html",$widgetPath,array("L"=>array("lang"=>"en")));

    $definition=array("TEMPLATE"=>PROJECTPATH."/templates/PathWidget.html","TARGET"=>$cacheFile);

  $oManager->renderLayout($definition,$oLParser,true); 

Now, you can add two different implementations for the HOMEPAGE_NEWS_CONTAINER,
one located in widgets/mobile/HOMEPAGE_NEWS_CONTAINER.wid,
and other in widgets/nonMobile/HOMEPAGE_NEWS_CONTAINER.wid.
In the mobile version, only one of the newsboxes is handled, while the other are left empty.Of course, most probably, even the PAGE widget is different for each device, so the same strategy apply. In this way, the template file is kept clean, device-independent.And, also, expressed in a very high level, so in a glance, its purpose can be understood.

Layouts

The traditional way of using templates is: First, you jump into your code, initialize vars, and then, execute a template that includes some sort of pseudo-language to insert those vars inside markup.
Let's start with HTML.HTML is a language that, by reading its own and related (css,etc) specs, it's composed by tags that are meant to stylize what's inside them.Only a bunch of those tags have some sort of notion of what it's outside them, so they are part of a bigger structure: &lt:td>, inputs in a <form> , <li> etc.
But websites are not made of a bunch of independents, stacked <div>'s .
There are menus, sidebars, headers, footers, and quite a few different ui elements, each one of those composed by a few divs, and each one of those divs has a semantic role , in terms of that ui element.
Divs are to UI elements what assembler is to C.We're creating user interfaces using the most simple elements possible.There are no intermediate abstractions.We (struggle to) create a menu for our website, by combining divs and css.But that menu has only existence once it's rendered, and the user interprets those coloured divs or uls, as a "menu".
Nowhere in our code (except comments), has assigned that role to that bunch of markup.Once you start creating the user interface, you directly jump in the HTML and CSS madness.

So, it's not strange that Javascript has taken the role of creating the user interface.Libraries / frameworks like The Dojo Toolkit do a great work leveraging the concepts a programmer has to use to create user interfaces.
I think that's a big slap in the face to HTML.Sorry, HTML5, you're so great at doing things Flash was doing a decade ago, and still, fail miserably at giving any better support for creating serious UIs.

So, HTML has basically been reduced to the <div> tag, that you can convert to anything, using CSS (then, some folks still try to give "semantic" meaning to HTML).And, on top of that, use javascript to do the real rendering.
To see things in perspective: it's like we were writing components in the old Visual Studio 4, instantiating objects, but also, editing the .res files by hand.We're creating user intefaces programatically (javascript), and fighting with divs, css and browser incompatibilities.

So, after all that, is there a way to describe an user interface, in a more abstract way, and without resorting to javascript-based UI construction (so we keep javascript's small resources for our own purposes instead sustituying the browser rendering engine?)

What about this:

   [_MENU]
        [_MENUGROUP]
                [_TITLE]Main Navigation[/TITLE]
                [_OPTIONS]
                          [_OPTION][_LABEL]Home[/LABEL][_URL]http://...[/URL][/OPTION]
                          [_OPTION][_LABEL]...[/LABEL][_URL]http://...[/URL][/OPTION]
                          ...
                 [/OPTIONS]
        [/MENUGROUP]
        [_MENUGROUP]
                 [_TITLE]Support[/TITLE]
                 ....
   [/MENU]                                                  

Again, just by reading the above code, you'd know what's supposed to do.If i had written all that in its <div>, <ul>, <a>, etc equivalents, with all their css classes, attributes and so, you'd still be looking at the code trying to figure out what's its purpose. And, again, i've said nothing about how this code should be rendered.Is it a navigation bar?Is it some sort of tabbed widget? That doesnt matter; again, we're using abstractions we all know, like "Menu", and leaving out implementation details.That will be solved at a lower level. I've attempted to write template engines (like this one) to support this kind of structures, and, although they're not perfect, they did the job.But now, i think i've found the right way to do it...And hope to post some code soon! Stay connected!