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.

An alternative to traditional MVC architectures for web development

In the previous post, i pointed some incoherencies about the "traditional" way frameworks apply MVC to web development.
Now, i'll propose a slightly different architecture, hoping it'll be more natural, while solving the incoherencies of plain MVC.I'll call it "Stacked MVC", but i suppose somebody else, in some place, has already described it, and called it in some other way..Duh!..

What it's shown there are 2 MVC systems.One of them, is strictly managing the bussiness side of the system.If it's an art gallery, it manages all CUD operations, like adding an artist, adding a picture, or a comment to a picture,etc.This MVC subsystem should not know anything about HTTP variables like $_POST,$_GET,$_SERVER,$_SESSION...
The controller should be invoked with User, Request, and the parameters required to serve that request.Ideally, the existence of those parameters, the sanitization,etc, has already been done.
The "V" of this sub-system, is nothing more than datasources, in a fixed format.For example, an "artist info" view, would return this info as an array, an xml, or any other format suitable to store data.
It may have it's own, private database, storing only bussiness-related data.

What invokes those "views"? The Web subsystem.
Most frameworks try to push down to the View Layer anything that is related to HTML.But, once there, it becomes obvious that the problem is not just generate HTML.A website is more complex than just HTML.There are headers, footers, metas,sidebars, client-side scripts, css files, language/i18n files..

And somehow, all that must fit in the View layer, that, having so much responsability, must use concepts completely extraneous to MVC like 'layouts', 'helpers','snippets' and all that kind of..."scripts", to finally be able to render a page.

When it should be obvious, that what it's called "layouts", is a "controller".A "Page", a "Section",a "Header",a "Footer", a "Sidebar", are objects that exist in the context of a website, so they're Models.A web page is much more than simply a bunch of HTML.There's a logic between all the components of a web page, much like there are relations between artists and their pictures.
To render bussiness subsystem data, the website subsystem uses the previously mentioned datasources, the same way it uses a database;The "model" objects in the website subsystem ("Section"), "queries" the bussiness subsystem to fetch the data it requires, and sends it to a certain "Section View".

Any "R" request arriving at the web server, is sent to the website subsystem.
Any "CUD" request, is sent to the bussiness subsystem, and, if that request is configured to generate a "R" request after the bussiness subsystem has processed it (onError, onSuccess), adds to the famous tuple of $_POST and $_GET, information about the result of the processing done.

This is just a quick intro to this idea.There are more advantages, gotchas, and ideas around it.But, to finish this intro, i'd like to say that i'm not trying to say we need MORE frameworks (O-M-G)..This architecture is more about having a guideline on how to distribute the application code, than using (insert bloated framework name here) to solve it all.

Describing vs Coding

I like to start the development process just doodling some circles and lines in a blank paper page.I dont use formal symbols..and almost always, after two days, i really cant decypher what i was trying to express in it.

I think doodling is something many of us programmers do.What it's interesting, is that those doodles are the first bits of information about the system.Yes, very rough, too general, and too simplistic.But still, "information".

For me, this raises the question "The description of a system, is data, or code?".And, "If it's data, where is it?".The doodles are some sort of strange data.But, could it be possible to save that data in some way that it's usable for actually develop the system?

There are other ways to express the problem.If someone describes a website as having a menu, with 4 sections, one of them having a form where you can enter a comment, i bet that, with just that, you can already imagine a lot about that website.Because, implictly, the words "menu","section","form","comment" already have a lot of meaning.

Is it possible to actually start development with such information?

Ok, let's suppose we start developing the website, creating this file:




<?php
         $myWebsite=array(
                        "TITLE"=>"MyWebSite",
                        "SECTIONS"=>array("Home"=>"BLOG",
                                          "My Gallery"=>"GALLERY",
                                          "About"=>"PLAIN"),
                        "ALLOW_USER_REGISTRATION"=>true
                        );
         ?>
   

That would be a "doodle" written in php.I still don't know what the keys and values of that array really mean, or how they will be processed.But, i bet that, just reading that array, you may have an idea of what kind of website it describes.And that idea contains much more information than what it's strictly specified in that array.Intuition is being translated as "reasonable defaults" in computer programming.

Now, suppose you drop that file in the top folder of your project.Deeper folders will add finer detail.

Suppose we create then a "Sections" folder, and add the following file, Sections.php:



<?php
/*....*/
$sections["My Gallery"]=array(
     "GALLERY"=>array(
     "VIEW"=>"PictureList",
     "ITEMS"=>20,
     "OBJECT"=>"Picture",
     "SINGLE_ITEM_VIEW"=>array("VIEW"=>"PictureDetail", 
                               "ALLOW_COMMENTS"=>true),
     "HEADER"=>"DEFAULT",
     "FOOTER"=>"DEFAULT");
     /*.....*/
    

In the first file, it's specified that "My Gallery" is a section that follows a "GALLERY" pattern, whatever is that.It's still a vague notion, but it's safe to say it's some sort of listing.In this second file, we parametrize the pattern, with, again, more vague details.

In this file, i try to express that this gallery shows 20 Picture objects per page, and will use the "PictureList" view to render them.Also, if i choose to see a single item, i'll use the "PictureDetail" view to render it, and i allow adding comments to that item.

Still, i don't know how i'll handle all those "VIEW","ITEMS","OBJECT" concepts.I haven't decided what framework i'll use, what kind of database, if those arrays will be loaded each request, or used to generate code.I'm still describing the system, instead coding it.Iteratively, adding information about what the system is, in a format that is easy to manipulate and transform, so they really are *used*, they're not simply doodles in a paper.

Of course, the above examples are not really good examples for describing a website. In fact, it may be hard to express things in a php array (or xml, text..whatever) that intuitively you can see clearly in your mind.

I've been using this kind of approach for 5 years now, and use it almost anywhere, from model object definitions, to views, forms, pages,states,storage...Sometimes, the first time programmers in my team see those arrays, they are sort of surprised.But my experience is, once they understand the core of it (describe as much as you can, and code less), they seem to be happy with this "paradigm".