Nested componentization for advanced Web portal solutions

1. Nested componentization for advanced Web portal solutions SveborPrstačić, dipl. ing., Dr. sc. Ivan Voras, Dr. sc. Mario Žagar

2. Agenda • Mission and features • Implementation • Future work ITI 2011

3. 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 ITI 2011

4. 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 ITI 2011

5. Features • Components should be usable as plug-in applicationse.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 ITI 2011

6. Features ITI 2011

7. Features • One line extension reuse • As easy as HTML tag reuse • Provide a context • Enable extensions to hook without relationaldependencies • Provide user data • Provide permissions ITI 2011

8. Implementation - MVC • 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 ITI 2011

9. Implementation - MVC • 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 ITI 2011

10. Implementation – execution context • 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’’} ITI 2011

11. Implementation - hook data • 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’’); ITI 2011

12. Future work • Improve implementation • Identify integration interfaces and integration workflow • Framework - triggered events • Dynamic hooks ITI 2011

13. Thank you. ITI 2011