Nested componentization for advanced Web portal solutions
This presentation discusses the creation of a reusable framework for advanced web portal solutions, focusing on modular componentization. It highlights the inefficiencies and incompatibilities of common frameworks, emphasizing the need for standardized interfaces. Key features of the proposed framework include ease of component development, nested components, and seamless integration with existing applications. Practical examples of feature extensions are provided, as well as details on implementation via the MVC architecture. Future work will focus on improving integration and dynamic event handling for enhanced functionality.
Nested componentization for advanced Web portal solutions
E N D
Presentation Transcript
Nested componentization for advanced Web portal solutions SveborPrstačić, dipl. ing., Dr. sc. Ivan Voras, Dr. sc. Mario Žagar
Agenda • Mission and features • Implementation • Future work 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 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 ITI 2011
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
Features ITI 2011
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
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
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
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
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
Future work • Improve implementation • Identify integration interfaces and integration workflow • Framework - triggered events • Dynamic hooks ITI 2011
Thank you. ITI 2011
