Nested componentization for advanced Web portal solutions

rangaleclickΛογισμικό & κατασκευή λογ/κού

4 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

90 εμφανίσεις

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 framework


3

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 2011

6

Features

ITI 2011

7




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 2011

8


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 2011

9



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 2011

10


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 instance
s


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 2011

11


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 2011

12




Improve implementation


Identify integration interfaces and integration workflow


Framework
-

triggered events


Dynamic hooks


Thank you.

ITI 2011

13