Virtual Widget for Portal Engine
February 16, 2021 | 2:39 am CST
As developers convert websites from Portal Engine to MVC, Many have said there should be a way to allow front end developers to create virtual widgets in MVC, similar to Portal. That way, front end developers can work more independently, instead of relying on backend developers to build MVC widgets and push code changes. With that thought in mind, here is the working concept for allowing front end developers to build virtual widgets without backend code changes. Virtual Widget for Portal Engine First of all, in case you are not familiar with virtual widgets in Portal Engine, here is a quick note on that. You don’t need to write any code for a virtual widget. You simply create a widget with field definitions to manage & store data. Then you use widget container, which has the HTML markup and macro script, to pull data from widget data fields and generate the final HTML output. It’s an easy way to create structured, reusable components for front end developers and content editors to use on pages. Although the widget is virtually built in the admin UI and stored in the database, it needs to be rendered by a default web part. You can typically use the Static Text web part or create a simple custom blank web part as the base. Full Movie Virtual Widget for Kentico MVC My thinking for the virtual widget concept for Kentico MVC consists of the following: First, think the output that you are trying to display as a component. For example, a banner, a tile block contains image and text, or a block of text. You will need a generic MVC widget as the base, to render the component output. Because the based widget has to be generic, the model, controller, and view should not contain any specific definition tie to any component. The data structure (model) can be handled as a Page Type. The data of the component should be stored in the content tree as a node. This way, components will also be reusable. You can utilize a Text/XML transformation to bind the page type data with HTML markup using a Macro resolver. (p.s. I did check with product team and got confirmation that both Text/XML transformation and Macro resolver are staying beyond Xperience 13) The simple idea is to create a dedicated transformation for each of these component page types, with the same naming convention. Certainly, this can be extended to allow multiple transformations with a drop down list for content editor to select. When using this widget, an editor can place the widget into the page, and select the component node from the content tree. The controller of this widget will identify the node class in order to get the matching transformation. Then, using macro resolver API to resolve the node data with the transformation, it can generate the HTML output for the widget viewer to display.