Overview

Vihv LCC stands for Vihv Loosely Coupled Components.

The key concept is:

Library should be compatible with ANY application architecture

However, components themselves have their standards and their architecture inside.

So, what makes VihvLCC so flexible:

  1. Clean interfaces
  2. Everything can be overriden
  3. Class mapping
  4. Event handlers
  5. Access control lists

On top of these core concepts we put some default classes which can be overriden any time. Good example - All Unit framework, which is build on top of VihvLCC and there lots of things are overriden.

Build-in technologies:

  1. XSLT as template engine (very nice, love it)
  2. XML based ACL
  3. XML based class mapping
  4. Mysql
  5. Key value emulation based on mysql
  6. Document oriented models based on mysql

The purpose

I can say that VihvLCC is universal, but I wont. Too much libraries/frameworks are promoted as 'one lib for everything'. So, I'll be more accurate here:

VihvLL can be used for different tasks, but there are a few at which we are the best.

One feature is pretty unique - using VihvLCC as universal theming engine.

How:

First of all lets split website in 2 pieses:

  1. Backend. Here CMS and e-Commerce engines have strong positions. For most tasks there is no reason to create your own backend.
  2. Frontend. Well, lets face it: most CMS owners leave frontend to thirdparty - to theme developers, to plugin developers. To you. VihvLCC is not the one option - there are lots of libraries to simplify theme creation process. But VihvLCC can be used together with any CMS in the same manner.

One skill for all CMS engines. Less time to learn. More time to earn.

Lets dive a bit into VihcLCC component architecture

Component principles

  1. Each component implements MVC pattern incide.
  2. Component can contain child components. Children can contain their own chindren. Dept can be infinite.
  3. Logic of each component is independant from other components.

Component architecture

Controls. Business logic layer.

VihvLCC Controls are in the middle of all this.

Controls implement business logic. They are pretty similar to CBuilder or Delphi Controls.

  • Each control deside himself if it should be active on current page.
  • Control react to events, like onCreate, onPost, onBeforeDisplay, etc. There are lots of buildin events and you can create your own at any time.
  • Control call model layer to work with data.
  • If control get data to be displayed with view - it should serialize it as associative array and store to be used by template engine later.

Here is basic wordpress example class BlogPostControl extends \vihv\Control {

  public function onCreateEvent($sender) {

    /* this control should be enabled if current page is single post page
     lets check and enable */
    if(is_singular()) {
      /* here we call CMS function, but we can use \vihv\Cms::isSingular() to make this theme more universal, just keep reading */
      $sender->enable();
    }
  }

  public function onEnableEvent($sender) {
    /* now lets grab some data*/
    $post = \vihv\Cms::getPost();

    /* and store it to be used by View layer*/
    $sender->pushData('post', $post->getDataAsArray());
  }

}

Models. Working with data.

One may say: "But different CMS have different architecture, work with data in different way, manage urls in different manner!"

Here comes the Wrapper Class, also known as Decorator. Look at this code:

use vihv;

Cms::setImplementation('vihv\\wordpressWrapper');

$siteurl = Cms::getSiteUrl();
/* will call wordpress funtion get_bloginfo('url');
 siturl is string, so this is obvious */

$posts = Cms::getPosts();
/* will call Wp_Query, than decorate results with build in class WpPost which implements universal interface ICmsPost */


Now lets move this code from Wordpress environment to Drupal environment, all we need - to change first row

use vihv;

Cms::setImplementation('vihv\\drupalWrapper');

$siteurl = Cms::getSiteUrl();
/* will call drupal function base_path()*/

$posts = Cms::getPosts();
/* will get nodes for current location, than decorate results with build in class DrupalPost which implements same interface ICmsPost */

Okay, we learned how to grab some data. Whats next?

View Layer

By default VihvLCC use XSLT. XSLT is basically an instruction to convert XML stream into anything else, this instructions themselve are written in xml too. If you want - you can change it to Smarty or any other template engine you like. Howevere XSLT is pretty cute:

  1. Much easier to create valid html code. Xslt processor will fall to error if you miss closing tag or quotes. But if you need to display wrong formatted html code - you still can do it.
  2. You can switch between different standarts of html with no/few changes in templates.
  3. As for it is different language, not php - it's technically impossible to mix view layer with model layer or business logic layer (controls). So your code is more clean.
  4. XSLT templates can be used on server side (default), but you can also move xslt processing to client side - into browser. Most browsers already support this feature.
  5. XSLT is designed to be extremely fast.

My favorite: XSLT make you better as skilled professional. This skill will be valuable even if you switch to different language. C#, Java, C++, Python - most languages have XSLT implementations in em. If you once will stop working for web and switch to something different - you can use bring xslt with you. Each minute you spend to learn XSLT will make your life better in future.

How it works:

  1. Control store data as associative array, as we saw in example above
  2. VihvLCC serialize this array to XML (and you are able to view this XML with VihvLCC debugger at runtime)
  3. Data from all active controls combined together
  4. Theming object search for XSLT template for each control
  5. XSLT processor load both serialized data and xslt templates
  6. XSLT processor process templates and output HTML

Example:

PostControl store data from CMS engine as array like this

array(
  "post"=>array(
    "title"=>"My Post Title",
    "content"=>"<p>Lorem ipsum <a href='http://dolor.local'>dolor</a> sit atmet</p>"
  )
);
In Developers Eye debugger on single post page we will see this XML

<PostControl>
  <post>
    <title><![CDATA[My Post Title]]></title>
    <content><![CDATA[<p>Lorem ipsum <a href='http://dolor.local'>dolor</a> sit atmet</p>]]></content>
  </post>
</PostControl>
In config/theme.xml we need line like this, for VihvLCC to find the proper template

<theme>
  <PostControl>design/PostControl.xsl</PostControl>
</theme>
And our XSLT template design/PostControl.xsl will be something like this

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" encoding="utf-8" indent="no"/>

    <xsl:template match="PostControl">

        <div class="article fullwidth">
            <article class="article__inner">
                <h1 class="article__title">
                    <xsl:value-of select="title"/>
                </h1>
                <div class="article__content">
                    <xsl:value-of select="content" disable-output-escaping="yes"/>
                </div>
            </article>
        </div>

    </xsl:template>
</xsl:stylesheet>
First 2 lines and last 2 line are same in most cases, so we have vihvlcc plugin for NetBeans IDE, so you should not worry about them.
Third line needed to indicate what part of XML we are processing with this template.

As you can see - each file is rather small, andeasy to understand.
What if we need huge web page with lot's of content on it?

On huge web page you will have bunch of small content blocks. Each block will be created with different and simple control.

This will simplify your work a lot. You do not need to keep in mind the entire webpage anymore. The best benefit of VihvLCC, is that components are Loosely Coupled. All files in your project can be small. And while you work with one file - you can forget about all the rest.

When you work with model layer - you can write unit tests and forget business logic.
Controls also can be tested with unit test, but you also have Developers Eye, to check if all needed controls are enabled on web page and if they store correct data to be displayed.
If you work with XSLT - you can process same template even with no controls at all, just using some test data.
So you always work with tiny bits, but as soon as you finish the last bit - your website is ready.

Think less - do more.

What's next?