He creado una versión en castellano del blog, donde, en principio, quería traducir los mismos posts...
Pero me ha parecido demasiado aburrido...Así que me he puesto a hablar de otra cosa...Visítalo!!
Friday 11 January 2013
Wednesday 9 January 2013
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:
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!
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!
Wednesday 2 January 2013
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:
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:
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.
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.
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.
Subscribe to:
Posts (Atom)