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 2ITI 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 3ITI 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 4ITI 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 5ITI 2011
Features ITI 20116
Features ITI 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 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 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 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 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 Improve implementation Identify integration interfaces and integration workflow Framework - triggered events Dynamic hooks
Thank you. ITI