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.

Is MVC a good paradigm for web development?

It's like you'll get laughed at , if you dare doubting about it.Checking Wikipedia article on MVC you'll see the *myriad* of php MVC frameworks out there nowadays, so, looks like it's definitely the way to go.
But, still, i miss some kind of reasoning of why MVC is such a great paradigm for web development.Sometimes, i get the impression it has been adopted because one was desperately needed.
Of course, there are plenty of sources explaining what MVC is all about.Let's take the definition of "View", according to Wikipedia:

A view queries the model in order to generate an appropriate user interface (for example the view lists the shopping cart's contents). The view gets its own data from the model. In some implementations, the controller may issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state that require a screen update

Now, let's look at the definition of "View" we can find in CakePHP (taken as example):

Views are the V in MVC. Views are responsible for generating the specific output required for the request.Often this is in the form of HTML, XML, or JSON, but streaming files and creating PDF’s that users can download are also responsibilities of the View Layer

Are those two definitions equivalent?For starters, the second definition includes a new concept, that looks like it's not important enough to have its own initial in the paradigm name: the Request.
But, if we continue reading CakePHP documentation on Views, we'll find quite a few more concepts:

The view layer in CakePHP can be made up of a number of different parts. Each part has different uses, and will be covered in this chapter:

• views: Views are the part of the page that is unique to the action being run. They form the meat of your application’s response.
• elements: smaller, reusable bits of view code. Elements are usually rendered inside of views.
• layouts: view files that contain presentational code that is found wrapping many interfaces in your application. Most views are rendered inside of a layout.
• helpers:these classes encapsulate view logic that is needed in many places in the view layer.

So, the view layer, are composed of a few things, one of them being the "views".But the "views", are a "part of the page".Another new concept that is brought up.So, "views" are part of the "view layer", and the "page".Are those two things the same?
Because "layouts" are defined as "view files" that wraps "interfaces".Again, "views" are rendered "inside" a layout, so i guess it's safe to say that views are also part of "layouts".
So, "views" are something that are part of the "view layer", the "page", and "the layouts".
It's worth noting that "page" is a HTML concept.There's no such thing as an XML or JSON "page", and i dont think "streaming files" can be thought as a "page" neither.
Going back to the MVC definition found in Wikipedia, a view "generates an user interface".It could be argued if generating HTML is exactly the same than generating an user interface.But, i dont think XML, JSON or "streaming files" are exactly "user interfaces".

To finish the soup of concepts, while "elements" are "reusable bits of view code" (they are view code, but they're not views?), "helpers" encapsulate "view logic needed in many places".I swear i could write as "reusable bits of view code" as well.
I'll not go into the "view blocks", another concept introduced later in the same documentation.I think it's enough. We have the "view layer","view blocks","view logic","view code","view files" and plain "views".
This way of abusing the MVC definition, using the word "view" repeatedly, only shows how poorly defined are each concept, and, finally, how the documentation tries to twist concepts to make it fit into the MVC paradigm.
Let me demonstrate that: if i pack a certain user information inside a JSON message, what role takes that JSON message in my system? Is it an "user interface", like the "canonical" MVC definition refers to what is produced by the "views", or is it the way a Model residing in the client, is getting its data, the same way the Models residing in the server get their data from the DB?
Is the "V" doing the same job for our system when it sends HTML (data mixed with presentation), and when it sends JSON (just data)? Can you think in a system where the server does *nothing* about the user interface? (Flash? Desktop / Mobile App? Javascript?).Then, how can we call that a "View"?  Whats a "page" in Flash terminology?
This is why, in the CakePHP docs, they've subtly changed a word from the V definition at Wikipedia. Views no longer generate "user interfaces", but "output".Any "output".Way to generalize an idea to finally push inside absolutely unrelated concepts (as if all "output" has the same role in a system..).

You may wonder if i'm attacking CakePHP for some reason.Not at all.In fact, the first time i've visited CakePHP site, has been for writing this post.I know beforehand most MVC frameworks docs will be extremely vague, inconsistent in this point.Because, simply put, it doesnt fit well.But doc writers really try hard.And most people will read those docs trying to learn, not trying to critisize it.I'd have pick any other framework, and i bet the same inconsistencies would show up.

Those are some of the reasons because i'm not sold on the MVC fever.And, also, because i think there are better, more consistent ways to do web development.

PD: Just checked Symfony documentation.In a whole chapter "explaining" Views (like 15 pages), "model" and "controller" are mentioned a whopping total of..4 times! 3 of those times, in side-notes.All the documentation focus on all those little "helpers","elements","layouts" (read: good old scripts)...But nothing about how the View / Model / Controller interact.

Describing a web page (Describing vs Coding II)

The most common concept in web development...is a web page.
Is possible to describe a web page?
A simple try: lets try to describe a web page where you can see info of a certain artist, along with artwork he uploaded to our site:




<?php
       $webpages["viewGallery"]=array(
             
             "PERMISSIONS"=>array("ANONYMOUS"),
             "RENDERER"   =>"HTML",
             "HTML"       =>array(
                     "HEADER" => "default_header.html",
                     "FOOTER" => "default_footer.html",
                     "RESOURCES"=>array(
                                "CSS"     =>array("viewGallery.css"),
                                "SCRIPTS" =>array("viewGallery.js")
                               )
             ),             
             "PARAMS"=>array(
                              "id"=>array(
                                           "MODEL"    =>"Artist",
                                           "FIELD"    =>"artist_id"
                                           "REQUIRED" =>true,
                                           "SOURCE"   =>"GET"
                                          )
                             ),
             "ROLE"  =>"VIEW",
             "MODEL" =>"Artist",
             "VIEWS"=>array(
                            "ROLE"    =>"COMPOSITEVIEW",
                            "LAYOUT"  =>"STACK",
                            "SUBVIEWS"=>array(
                                array(
                                      "ROLE"    =>"VIEW",
                                      "OBJECT"  =>"Artist",
                                      "VIEW"    =>"Bio"
                                      "PARAMS"  =>array("artist_id"=>"id")
                                     ),
                                 array(
                                       "ROLE"   =>"LIST",
                                       "OBJECT" =>"Artwork",
                                       "VIEW"   =>"artworkList",
                                       "PARAMS" =>array("artist_id"=>"id")
                                     )
                            )
                          ),
       "CACHE"=>array(
                             "TYPE"            =>"TIMED",
                             "INVALIDATE_AFTER"=>30
                      )
        );
   

This array may look complex, but i invite you to read it.Again, bear in mind that this is just a "sketch" of what i want my page to be.It's not related to any particular framework.It just tries to express concepts.

But, what i consider interesting, is that many things that usually are coded, here are described.
Most pages will have a header, and a footer.Many, will require permissions.Lots will use parameters, and will have to sanitize them.Will include external resources. Will include one or some other pages.Other things that may include..headers (encodings,etc), tags...May require a certain "state" to be set.May set a "state".. Things that are easily described, but that usually, are just scattered around in code (if not forgotten).

When you are writing the above description, you're focusing in what you need to create the page.Not in how you'll create it.This is key.
And, as there isn't any kind of formal structure, you can add whatever keys/values that may fit your needings.

If somebody has to maintain my code, and reads the description array, he'll have lots of information that will help him to understand the actual code.Of course, as you may begin to notice, most of that code, could / should interpret that array, or will be generated from it.

And,if someday i want to switch from one framework, or language, even programming paradigm, having lots of information about my system as *data*, instead written in code, will ease the transition.

And this is the main concept; i don't know if there are frameworks using similar ideas, but, that's already a contradiction;my idea is: freely describe your system as data, without any dependency , syntax o requirements a certain framework may impose.
I've written an ORM that i (later) found to be pretty similar to Django for python.But, the fact that model objects definitions are arrays without any dependency on that ORM, is what makes both completely different in philosophy, and it's the philosophy (describe your system, don't just code it) what i consider important.

The challenge is to find the right way to describe a web page may have, from models to db-mapping, views, pages,permissions, in a way that it's, at the same time, intuitive, extensive (covers as much of the functionality as possible), inter-related (so form definitions rely on model definitions), and external dependency-free.

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".