Themes in the Erdiko Framework (Part 2)

In the first post we talked about how themes works in the Erdiko framework and covered important files to configure it. We continue with more advanced Erdiko theme topics and introduce new classes to discover more features, including layouts.

Today, I’m going to show you more concepts around themes in the Erdiko framework.  There are more concepts and classes to know and understand.

Layouts

To introduce the Layout class we need to define what is a layout: it includes the HTML for a basic web application structure in order to provide your own content. After made this clarification, we realize that a layout could be made by one, two, three or whatever number of columns.

Let’s look at the next code from Erdiko framework:

/**
 * Get two column layout example
 */
public function getTwocolumn()
{
    // Set columns directly using a layout
    $columns = array(
        'one' => $this->getView('examples/one'),
        'two' => $this->getView('examples/nested_view')
        );
    
    $this->setTitle('2 Column Layout');
    $this->setContent($this->getLayout('2column', $columns));
}

This code is an action from Example controller from code base of Erdiko framework. We can see how passing an array of views we can get a new layout built with ‘2column’ parameter. This way we instruct to Example controller what design we want to set to our application, and the final result will be something like this:

2columns

It’s important to take care about this latest parameter, it must exist as layout in the layout’s folder and the name must match exactly. Let’s recall our Erdiko folder structure:

layouts

the key method is Controller->getLayout():

 $this->setContent($this->getLayout('2column', $columns));

Under the hood, the controller delegates to a new Layout object composed of 2 views (one for each column) the call to render html code:

return  $layout->toHtml();

Pages

In order to reuse code the framework gives the chance of include html code often used, i.e. Header and Footer. This kind of content normally stay static around  the application. When we say “static” talk about structure however we also could include mustache code within the pages by using the {{ variable }} sintaxis.

Header

The header is a good example of html code that probably will not change in our web app. Erdiko framework installation provides us a nice default html code in the file:
app/themes/bootstrap/templates/pages/header.html

Something interesting to comment is the next piece of code:

<div class="navbar-collapse collapse" id="navbar-main">
  <ul class="nav navbar-nav">
    {{# menu.main }}
        <li>
            <a href="{{href}}">{{title}}</a>
        </li>
    {{/ menu.main }}
  </ul>
</div>

Ok, what is that sort of tag “menu.main”? Don’t worry just let’s say that we can create a html menu programmatically. When we talk about “Regions” will expand a better explanation. One important thing to highlight: the menu is built from the key “menu” in application.json file.

Footer

Footer section is more or less the same concept we talked previously with “header” but applied to the footer of application. Erdiko framework provides a default footer, the big difference against Header is the region used:

<div class="col-lg-12">
        <ul class="list-inline">
            <li class="pull-right"><a href="#top">Back to top</a></li>
            {{# menu.footer}}
                <li><a href="{{href}}">{{title}}</a></li>
            {{/ menu.footer}}
        </ul>
        <p>{{site.copyright}} {{site.full_name}}<br />
           Powered by <a href="https://github.com/ArroyoLabs/erdiko"
                         target="_blank">Erdiko</a>
        </p>
</div>

This time, the region used is ‘main.footer’ and the key used from application.json is “menu.footer”.

FlashMessages

To conclude with pages, another great and useful example is FlashMessages that provides (and being redundant) a flash message on top of the header page and denotes something important to show to the user application.

Unlike Header and Footer, FlashMessages is a helper, and you can call it:

<?php $messages = \erdiko\core\helpers\FlashMessages::get() ?>

‘$messages’ is an array and you are able to loop around it in order to give html structure:

<?php foreach($messages as $message): ?>
   <div class="alert alert-<?php echo $message['type'] ?> 
     alert-dismissible" role="alert">
     <button type="button" class="close" 
             data-dismiss="alert" aria-label="Close">
                <span aria-hidden="true">&times;</span>
    </button>
    <?php echo $message['text'] ?>
   </div>
<?php endforeach ?>

If you can get messages, it’s logic that you can set messages too 😉 :

<?php 
$message ='This is a success message to show.';
//what color we want to show the message? 'danger' is by default.
$type = 'success';
\erdiko\core\helpers\FlashMessages::set($message,$type);
?>

Regions

In the first post when we talked about Mustache we understood how a content is rendered exactly in the right position into the html code. In order to conceive Regions, we can take the same concept, regions is just a “mark” in the html code to teach the framework about what kind of html structure we want to create, just in the right position where should be placed.

Let’s take the region part of footer.html:

 {{# menu.footer}}
     <li><a href="{{href}}">{{title}}</a></li>
 {{/ menu.footer}}

When the framework process this region tag, as result we will get a nice footer created programmatically. The million dollar question is:
– How the framework makes possible to know about footer structure?
Easy, Erdiko reads the section ‘menu.footer’ and iterates the key/values within  in application.json file.

Scripts and Styles

Previously, in our post “sample application using Erdiko Framework” we proposed as example a little dice to roll with a very simple view. That view used the controller method addJs() and addCss() in order to add css and js code to the view respectively. The method signature  is the next:

/**
 * Add Css includes to the page
 *
 * @param string $name
 * @param string $file
 * @param int $order
 * @param int $active
 */
public function addJs($name, $file, $order = 10, $active = 1)
{
    $this->getResponse()
        ->getTheme()
        ->addJs($name, $file, $order,$active);
}

Both methods share the same order and number of parameters.

Views

A view object is a piece of code to provide a visual representation of model data, in object terms is a very simple class where we can modularize our html code. Let’s take an example from Erdiko framework:

$this->addView('examples/about', $data);

here we add the view ‘examples/about’ to the  controller response. The views can receive parameters, here is the constructor:

public function __construct($template = null, $data = null, $templateRootFolder = ERDIKO_APP)
{
    $this->initiate($template, $data, $templateRootFolder);
    $this->setTemplateFolder('views');
}

by reading this code we can understand easy, what kind of parameters a view needs, look how the folder ‘views’ is assigned by default.

There is no more to talk about Views, the content will be rendered by the controller with addView() method internally, calling to:

$this->appendContent($view->toHtml());

Using properties

There are a set of  properties  defined and accessibles to the entire application, we can use it between {{ variableName }} in views or templates because are just keys/values already created in application.json config. file. To mention a few of them:
– site.name
– site. description
– site.copyright

Default.php

Default.php is, paradoxically, the default template theme applied to a given view. In a general manner, default.php is a complete html page with formal sections (head, body, etc) but instead make use of static code, it call the previously defined dynamic pages as header, footer and messages. Let’s see a fragment just to understand how the sections are referenced:

<?php echo $this->getTemplateHtml('header'); ?>
<?php echo $this->getTemplateHtml('messages'); ?>
<?php echo $this->getContent(); ?>
<?php echo $this->getTemplateHtml('footer'); ?>

where the method call:

$this->getContent()

what we want is to render the View code itself.

Conclusion

Erdiko framework provides a very flexible solution to easily change the aspect of a complete web application as complex as we propose it, the key to achieve that is setup properly all our config. files and templates.
Thanks for reading!

Themes in the Erdiko Framework (Part 1)

As web applications and sites become more complex it becomes important to organize your view layers with themes. We explain how to leverage the Erdiko theming engine and how to keep your code tidy and consistent. This is the first of a series of posts about Erdiko theming.

Why do we need themes?

Typically when we start a new web project, we are focused on the workflow and technical details about how the applications will work and what solution will provide to the end user. At some point of the planning process, we should start thinking about how our application will look, what data will offer, and then we begin to define our needs:

  • What is dynamic and what is static
  • What will be changed according our business logic
  • What is the menu, header, footer etc

Most of the time the HTML code will deliver rendered data elements, but half the battle of frameworks is deciding how to organize your code.

remember that design patterns are tools that you can use to solve specific problems , In MVC the Controller is responsible for determining which View is displayed in response to any action including when the application loads, if some parts of the view are very similar probably you need themes, don’t reinvent the wheel!

Currently we can find this behavior in any web application or SPA :

  • The header and footer are consistent across pages
  • The content changes according to the link we click in the navbar
  • The navbar (below the header or left aligned) will probably change according  to user level (admin, operator, visitor, etc).

At the end of the day we can realize that we don’t have to repeat over and over the same code, and we want to promote the re-usability of our code.

Thankfully, much of this work has been solved by many modern frameworks (re-inventing this is not an easy task). Let’s examine how we accomplish this with the Erdiko theming engine.

Paths and files

Let’s discuss what is in our Erdiko folder structure:

paths

For the moment just keep focusing on the “themes” folder and their nested folders. There are a lot of files right? Don’t worry let me explain:

  • themes: where each different theme is stored.
  • bootstrap: the default Erdiko’s theme.
  • views: This is where we put our HTML templates, where we render the data from our models.

Within the bootstrap theme:

  •  templates/layouts: we got templates in the most common variety: 1, 2, 3 columns and a menu.
  • templates/page: this part is the easier to understand, footer and header content, a messages file to show flash message alerts, and two special files: ‘google_header’ and ‘google_body’.  These last two allow us to insert Google Tag Manager and Google Analytics information.
  • theme.json: this file is one of the most important in order to use themes feature. Here we can set up all the previous files we talk, using json format.
  • app/config/{context}/default.json: another important config file to set up what theme will be used by the Erdiko application (theme, namespace, how many columns? And the home url). In order to demonstrate the flexibility of Erdiko framework, you can define many different contexts for a web application (default, production, etc).
  •  Default.php: the backbone file for Erdiko’s themes, here we give the main html5 structure to the final app  and also (and most important) we make use of the previous dynamic files (header, footer, example) calling the method:
Theme::getTemplateHtml().

In the same way we can show the dynamic code corresponding to the footer:

$this->getTemplateHtml('footer');

 We finally don’t know how this magic happens, how to mix dynamic data and html code in the exactly and specific parts. Is a dirty job but somebody has to do it… and the candidate is Mustache!

But what is mustache?

Mustache is a logic-less templating language that can be used to take most of the work out of creating re-usable HTML templates.

Let’s see a little example:
1. define the mustache template:

<h1>{{header}}</h1>

Please note the ‘header’ word between curly brackets.

2. define the model to user over that template:

{ "header": "Hello world!"}

3. Apply that model to the template and render it:

<h1>Hello world!</h1>

This pattern is extremely useful. Not just for re-use, but making debugging far easier.

Currently Mustache offers a lot of useful functionality but this is the most basic and important one. What we got here is the idea how it works, but remember that Mustache is One of many template systems, and the framework is not limited to use it.

Themes

The Theme class is the key element here, we need to understand how it works, their methods names are self-exaplanatory, the most important task is to process data and html templates to obtain a final html code. When a controller is created, a theme attribute is built in order to provide structure to the application. All necessary parts before to render are prepared by the _before() hook:

public function prepareTheme()
{
    $this->getResponse()
         ->setTheme(new \erdiko\core\Theme($this->getThemeName()));
}

Each time we call an action on a controller (except the ajax controllers) we automatically are setting a Theme, by inheriting the class \erdiko\core\Controller. When the action is done, tipically we create a new view passing a data array as second parameter:

$this->addView('examples/list', $data);

Or maybe we don’t want to show a view, we can just show a basic content with controller::setContent() method:

// Entering raw text on the page
$this->setContent("
    <div class=\"container\"><p>
    This is the simplest page possible.</p>
    </div>");

Then if the action is finished, the internal Theme will render their html stored. The most important methods of class Theme are:

  • addMeta(): Manages metadata of the application.
  • setPageTitle() and setBodyTitle(): Manages the title.
  • getCss() and getJs(): their setters add units of code, but the getters retrieves an array of that specific nature (array of css, or array of js stored). The result is a well formed <link> tag according to each array cell.
  • getTemplateHtml($aPartialToBeRendered): we can switch the template for a theme to render html with data.
  • toHtml(): finally we got html rendered.

In this first half of our blog post, we offer a big picture view of how theming works in Erdiko framework. At this point, we know that Controllers ‘under the hood’ already has prepared a theme ready to use with our defined content, and these themes are able of make html code. But they are not the only actors in this movie and the render concept needs to be explained a little more in depth. The next post we will continue talking about themes and discovering more actors and abilities. Thanks for reading!

Electron and Angular2: simple App example

In our first post about Electron, we were covering the main topics about what is and how it works. This time we will cover how to create a dummy application using Electron and Angular2 as a front-end framework.

The application tree should be something like this picture:

tree

we can observe:

  • gulpfile and package.json: we will talk later about this 2 files, by now we can just say that are needed to build the application.
  • assets: The package.json is a file useful to give directives to Electron, with this method we can order show/hide the window borders, icon, maximized/minimized, etc.
  • frontend: here we got the content relative to the front end, more especifically all the Angular2 stuffs.
  • main: contains the index.js referenced by assets/package.json and is the start point of our electron application.
  • Tsconfig and typescript files are needed to transcode the typeScript code into javascript.

The main gulp tasks needed to build and “deploy” the application sources:

gulp_file_main_tasks

from this file, the most important tasks are frontend and electron. The first one copy all the content from the source path.

The principal Electron tasks to run the application:

main_electron_gulp_tasks

 

The  second task begins the transcoding and building of the application.

   The electron package.js, it is useful to pass directives at start time, the format of  is exactly the same as that of Node’s modules, and the script specified by the main field is the startup script of your app, which will run the main process. An example of your package.json might look like this:

package_electron

   We need to remember, if the main field is not present in, Electron will attempt to load an “index.js”.

The main index file loaded by electron at first time looks like a common js file:

main_electron

Then, the final product, the application up and running:

app_running

    we realize that is a common web application, the tick here is to work in the look & feel to “hide” that common details (relative to the chromium browser) and make an effort in order to show the appplication like a elaborated desktop app. It is possible to change icon, task bar, menus, system buttons etc. Even if you don’t like the squared and classical window you can hide the background and create a “floating” app with alpha and the shape you want.

   In the sample app we’ve created a minimal environment with an image background and a button in the middle. If you press the button, you will get as result a notification at the notification area, that position will be according to the SO where the app is running, in my case Im running ElementaryOs so the notification area is in the upper-right conner:

notification_electron

The cool part here is, that notification is executing in real native code. The Electron API does the hard work to communicate to the SO what we are trying to do, in our case, show a notification with a text and image.

That’s all for this second part of Electron, you can download the code from here thanks for reading!

 

A New Framework Architecture for 2016

Why a new architecture?

PHP is the most popular language on the net and has a wide array of frameworks, apps and packages available.  Most of the best ones are open source, free or have a freely available version of their paid app.

That being said, it’s only more recent that the frameworks are being made, or attempts are made, to make them work together as components.  I thinks its about time to rethink or re-imagine how a developer or architect can create complex systems in an incremental and meaningful way.

I spoke a bit about the history and features of PHP previously.  Folks like Facebook and Baidu use it extensively. Some of the PHP platforms that are widely adopted are Drupal, WordPress, Magento, Joomla, Media Wiki, Symfony, Laravel, and Yii.  All have considerable user bases and impressive feature sets.  They all however, have very different conventions, coding styles and theming styles.

Speaking of theming, the way developers create a UI these days is dramatically different than how it was done in the past.  Browsers are more powerful and devices are more diverse.  JavaScript is much more powerful and more uniformly supported than it was a decade ago when PHP 5 came out (don’t forget about the V8 engine too).

  • Theming: Not everything has to be PHP anymore.  We now have
    • Bootstrap, & Material
    • Pre-compiling theme & components
      • Less/Sass
      • Gulp, bower, & grunt composition and code prep
    • Powerful JS frameworks and libraries: Angular, React, & more
      • Many more options than just jQuery these days

What’s missing from existing frameworks

  • Modularity
    • Some frameworks handle it well, but often the modularity is very limited to a smaller ecosystem, or at least an isolated ecosystem.
  • Composibility
    • Things are too often configured (db and config file) and not composed.  That is very convenient, but leads to slow production code and is more limited than a composable system
  • Security
    • Code should be outside the web root
    • Should work with and without a reverse proxy
    • Protect against common attacks
  • Models / ORM
    • The framework should work with any composer based (or modular) ORM
      • With so many rich ORMs and data connection tools available I don’t believe the framework should be relegated to only one ORM or model paradigm
      • Different scenarios call for different model approaches.  How can the framework facilitate the right data tool for the job?
  • Mashability
    • Create components that can easily be used together
    • Easy to add to any framework including erdiko
      • Leverage more code across and between frameworks
        • e.g. Use Eloquent in Slimphp
  • Routing
    • Symfony Request & Response
    • Symfony Router
    • Easy Compiled Routes
      • PhpMatcherDumper
    • Via plugins
      • Database routes (cms content)
      • Application specific routes
        • e.g. Magento, WordPress, Drupal
  • Server Automation
    • Work well with containers, modern deployments and popular coding workflows

The Developer / Architect paradox

This does however have a downside and that is what I call the developer / architect paradox.  This is developers wanting a complete solution and picking a tool that gets them 80% of the way there very quickly but they struggle with the 20% and have to make too many sacrifices and concessions to make the full system work.

PHP mashups and micro frameworks

Over the last two years we’ve been developing our php micro framework.  It came out of the need for more concise theming and mashing up data sources.  This lead to the development of Erdiko.  It’s an MVC micro framework that facilitates lean stacks and cool mash-ups.  Our moto is, “Enterprise Glue.”

We developed a simple yet powerful framework to get work done quickly yet maintain efficiency on the server.  Unfortunately too many of the large php frameworks suffer from performance issues.  Its typically caused by code bloat and or too much automagic happening.  For some projects this is great, for others it just gets in the way.

image

MVC

On the view side, Erdiko supports standard php templates, markdown and handlebars.  On the controller side we package all our content to rendered through a Response object and theme and/or structure the data according to your needs.  A rest api or ajax request does not need a themed page wrapper for instance.  Structured json is preferred.

Here is an example of a coding simple page.  It sets the page title and renders a single view in the page body.  A controller method like, getHello() might look like this:

$this->setTitle(‘Hello World’);
$this->addView(‘examples/index’);

The model layer is the mash up layer.  We actually don’t include much code here intentionally.  The models should be based on what your project is trying to accomplish.  We don’t want to assume we know your data better than you do!  We will be adding support to pull data from Drupal, Magento and WordPress.  If you need an ORM or MySQL connector use Doctrine, Zend Models, or whatever works best for you.  We’ve used a number of data models in the past with erdiko.  Its great to be able to leverage some of the great PHP you already know.  We will be writing more blog posts to show you architectures and code styles that help you make a clean mash up.  We’re talking about sound engineering here, not some frankenstein monster 😉

Router

The router is based on ToroPHP which borrows the conventions from Tornado (popular Python framework).  We have the guts or Toro (single file framework of only 125 lines) underneath erdiko.  We mantain compatibility with toro yet extend it to meet the needs of erdiko.

All of the routes are defined in a simple json file with a concise syntax that supports expressions.  There are also hooks that can be used before and after controller requests

Closing

The framework is a culmination of years of software writing and working with both start ups and large enterprises.  It’s a work in progress but we use it in production and are constantly improving it.  We’ve tried a lot of different techniques and architectures, with the latest version of erdiko we did some serious rewrites and made something we’re proud of.

I hope you find it useful.  Please give us feedback, fork it, remix it, and contribute back.

Check out more at http://erdiko.org/