Nested componentization for advanced Web portal solutions

Svebor Prstačić, dipl. ing., Dr. sc. Ivan Voras, Dr. sc. Mario Žagar

Agenda

Mission and features Implementation Future work

2 ITI 2011

Mission Social networks and/or features are unavoidable Implementing the same features over and over again

is common and inefficient Not reusable without standardized interfaces

Problem Components are incompatible Components cannot exist without the framework Frameworks are incompatible and inseparable from

parent applications Many different frameworks

Mission: create a reusable framework3 ITI 2011

The framework, features Framework easily reusable Easy component development

PHP, Smarty, object-oriented, MVC Database access Components can nest and are easy to reuse

Components oblivious to their siblings Type Inner architecture

Communication with the host application

4 ITI 2011

Features

Components should be usable as plug-in applications e.g.: Attach a photo gallery to a blog post Enable commenting for a news article

Recursive usage Allowed but not handled

We call them extensions

5 ITI 2011

Features

ITI 20116

Features

ITI 20117

One line extension reuse As easy as HTML tag reuse

Provide a context Enable extensions to hook without relational

dependencies Provide user data Provide permissions

Implementation - MVC

ITI 20118

Model Where the code is How the PHP files are named

View Smarty template Plug-ins, predefined template variables

Action link URLs Forms Permissions Localization strings

JavaScript Unified and minimized

Implementation - MVC

ITI 20119

Controller An abstract class

Every extension must have one Communication with the framework (execution, context

data) Main purpose - define callable actions

Called if necessary, depending on user input Objects are cached on the server

Properties retained between calls Can improve performance

Implementation – execution context

ITI 201110

Determines how and what a component should render e.g.: CMS – load stuff on a page Blog application – load stuff for the current blog

Extensions Partially inherited from parent (hook data) Partially provided by the framework from the host app (user,

permissions…) Creates unique extension instances

Usage examples {v2ext _name=‘’Comments’’

_content_type_name=‘’news_article’’ _content_id=‘’$news.news_id’’}

{v2ext _name=‘’Thumbslike’’ _content_type_name=‘’comment’’ _content_id=‘’$comment.id’’}

Implementation - hook data

ITI 201111

Consists of data type and payload data Accessed through UniqueID objects

Framework handles instantiation Every controller is provided a UniqueID reference

Downsides No relational dependency Data changes, cleanup?

Solved with event support: Hinders our one-line extension reuse goal:

fireContentDeletedEvent($news_id, ‘’news_article’’);

Future work

ITI 201112

Improve implementation Identify integration interfaces and integration

workflow Framework - triggered events Dynamic hooks

Thank you.

ITI 201113