visual web next design concepts winston...
TRANSCRIPT
Visual Web Next Design Concepts
Winston PrakashFeb 12, 2008
Page - A web page being designed such as HTML, JSP, JSF, PHP etc.
Page definition Language (PDL) - Language that used to create the page HTML, XML, JSP, PHP etc
Page Items - The items that compose the final page. It could be simple HTML element, JSF component, JavaScript code, JSP scriplets, PhP or Rails code blobs. Usually page items appears in the palette which can be dragged and dropped on to a web page being designed.
Some Notations UsedSome Notations Used
Visual Web ClassicVisual Web ClassicVisual JSF Framework
DesignerDesigner
ConfigFiles
.java
.jsp
ModelingModeling
Rich Rich Design SupportDesign Support
Overall ConceptOverall Concept
Framework SupportFramework Support
Framework ConfigFiles
.jsp
.xml
.php
.rhtml
Visual Web NextVisual Web Next
DesignerDesignerModelingModeling
Rich Rich Design SupportDesign Support
In Visual Web classic, Visual designing is limited to JSP based JSF web pages created by Visual JSF framework. The framework itself is integral part of Visual Web.
Visual Web Next will expand the scope of visual editing, to web pages created by other frameworks. It will define the scope of Visual designing based on the mime type of a particular web page. Project wide framework related artifacts will be taken care by Framework support.
Opening a web pageOpening a web page
Loader
Web Page
Editor SupportEditor Support
Data Object
Design PHP
StyledDocumentVisualVisual
DesignerDesignerTextText
EditorEditor
In Visual Web classic, the loader and DataObjects (JSP & Java) are defined by the VW framework itself.
In Visual Web Next, there will be one loader per web page. The EditorSupport of the DataObject created by the Loader is responsible for creating the muti-view tab and the corresponding view.
Visual Web registers the designer for that web page mime type.
Registering the web page designerRegistering the web page designer
EditorSupport API
Assume PHP EditorSupport exports an API
public Interface EditorViewProvider{ public MultiViewElement getEditorView();}
PHP Design Support (In Visual Web) implements the interface as
public class EditorViewProviderImpl implements EditorViewProvider{ public MultiViewElementgetEditorView(){ // Creates a returns the designer TopComponent }}
and register the implementation at META-INF/Services
PHP EditorSupport would get the registered Editor View via lookup and adds it to the Editor
Visual Components of Visual Web NextVisual Components of Visual Web Next
HTML Designer
Formatting Toolbar
CSS Visual Aid
Palette
PropertySheet
NavigationView
Formatting Toolbar: To apply predefined styles to the page item being designed.
HTML Designer: Area where the page items are manipulated, rearranged and customized.
CSS Visual Aid: Provides a visual way to apply CSS styles to the page item being designed.
Palette: Provides Page Items that could be drag and dropped on to the designer. HTML elements palette Category is a subset for all type of page design.
Navigator: Provides a hierarchical view of page items in the page. Helps to rearranging of page items.
Property Sheet: A place where the properties of a Page Item are manipulated.
Styled Document to ViewStyled Document to View
EditorEditorStyledStyled
DocumentDocument
HTML DOM
HTML Designer
ParserParser
Simplest form:The data (Page Items) from the Web Page is loaded in to the Styled Document of the Editor.
When the TopComponent of the designer is made visible the Parser (Controller) is notified via (componentShown() event).
Parser fetches the Page Items from Styled Document, parse and creates the HTML DOM and notifies the View (designer).
Parser acts as a Controller - implemented by Visual Web modeling aspect, explained later.
Designer fetches the HTML DOM and displays it.
fetch DOM
Synchronizing Document to ViewSynchronizing Document to View
Simplest form:User edits the Page Items using the Text View the thus causing the Styled Document to change, which in turn fires a Document Event.
The Controller, being a listener reacts to the event as
- Fetches Document- Parses the document, merge and creates the new HTML DOM- Notifies the View (designer) of changes in DOM
Designer fetches the HTML DOM and displays it.
- In Split View react to changes in a orderly delayed fashion.- In Tabbed View parse when user switched to design view.
Consider doing the parsing and merging in separate thread.
Considerations
EditorEditorStyledStyled
DocumentDocument
HTML DOMHTML DOM
HTML Designer
Controller
Document Event
Parse
fetch
User Edit
Old New
Merged
fetch DOM
EditorEditorStyledStyled
DocumentDocument
HTML DOMHTML DOM
HTML Designer
Controller
Parse
fetch
HTML Rendered
Combined
fetch DOM
Controller
Source DOM
Renderer
Document to ViewDocument to View(Supporting Renderable Page Items)(Supporting Renderable Page Items)
Assume the PDL contains mixture of HTML and renderable Page Items (Ex. JSF & Facelet).
The Controller, fetches and parse and creates an intermediate DOM called Source DOM, which is a mixture of HTML and renderable Page Item Nodes.
The renderable Page Items are associated with a Tag Handler or Renderer. On rendering HTML DOM fragments are generated.
After all the rendered DOM fragments are created, they are combined with the HTML DOM to create the final HTML DOM. The View (designer) is notified of the combined HTML DOM
Designer fetches the HTML DOM and displays it.
ConsiderationsThe rendered DOM fragments should be marked for reverse mapping.
Renderable Page Items - ExampleRenderable Page Items - ExampleRenderable Page Items - ExampleRenderable Page Items - Example
Assume we have to create a page for blogging and the page has
- Header- Left bar- Center content section (displays the blog entries)- Right bar which displays recent blog entry list
In case of component based page it would be something like
<div id="container" > <div id="header" > <!-- Contents of header --> </div> <div id="leftBar" > <!-- Contents of left bar --> <!-- Some links for side bar menu --> <div id="content" > <blog:blogEntriesblogEntries count="10"> </div> <div id="rightBar" > <blog:recentItemsrecentItems count="10"> </div><div>
Renderable Page Items – Example Continued ..Renderable Page Items – Example Continued ..
blogEntries & recentItemsblogEntries & recentItems are are components, hence need to be components, hence need to be rendered, which in turn spit out the rendered, which in turn spit out the HTML fragment. HTML fragment.
So in order to have a reasonable HTML So in order to have a reasonable HTML design, the components need to be design, the components need to be rendered first. The rendered HTML rendered first. The rendered HTML fragments are combined with the rest fragments are combined with the rest of the HTML to create the final HTML of the HTML to create the final HTML DOM.DOM. HTML DOMHTML DOM
HTML Rendered HTML
Combined
Source DOM
Renderer
<div id="container" > <div id="header" /> <div id="leftBar" > <div id="content" >
<blog:blogEntries count="10"><blog:recentEntries count="10">
Assume the PDL contains mixture of HTML and non renderable Page Items (Ex. PHP or Rails).
The Controller, fetches and parse and creates an intermediate DOM called Source DOM, which is a mixture of HTML and non renderable Page Item Nodes.
The non renderable Page Items DOM nodes are converted to a displayable DOM element such as <img> with suitable image URL indicating the PDL (Ex )
After all the Pseudo DOM fragments are created, they are combined with the HTML DOM to create the final HTML DOM. The View (designer) is notified of the combined HTML DOM
Designer fetches the HTML DOM and displays it.
Document to ViewDocument to View(Supporting Non Renderable Page Items)(Supporting Non Renderable Page Items)
ConsiderationsThe pseudo DOM fragments should be marked for reverse mapping.
EditorEditorStyledStyled
DocumentDocument
HTML DOMHTML DOM
HTML Designer
Controller
Parse
fetch
HTML Pseudo
Combined
fetch DOM
Controller
Source DOM
Converter
PHPPHP
Non Renderable Page Items - ExampleNon Renderable Page Items - Example
Assume the same blog page and it would be something like
<div id="container" > <div id="header" > <!-- Contents of header --> </div> <div id="leftBar" > <!-- Contents of left bar --> <!-- Some links for side bar menu --> <div id="content" > <p> <?php entries = getEntries() ?> <table> <?php for ($num=1; $num <= 10; $num++ ){ ?> <tr> <td> <?php $entries->getEntryText() ?> </td> </tr> <?php } ?> </table> </p> </div>
(Continued in next slide)
Non Renderable Page Items - Example Continued ..Non Renderable Page Items - Example Continued ..
<div id="rightBar" > <p> <?php recentEntries = getRecentEntries() ?> <table> <?php for ($num=1; $num <= 10; $num++ ){ ?> <tr> <td> <?php $recentEntries ->getRecentEntryUrl() ?> </td> </tr> <?php } ?> </table> </p> </div>
Note, Unlike rendered component most of the HTML elements already exist and only the text part of the HTML elements are generated.
Non Renderable Page Items – Example Continued ..Non Renderable Page Items – Example Continued ..
The Designer could allow design and The Designer could allow design and style most of the HTML in the page style most of the HTML in the page except for the DOM nodes except for the DOM nodes corresponding to the <?PHP> tag.corresponding to the <?PHP> tag.
In order to have a reasonable HTML In order to have a reasonable HTML design, the DOM nodes (<?PHP> tag) design, the DOM nodes (<?PHP> tag) need to be converted in to some need to be converted in to some pseudo elements. The pseudo HTML pseudo elements. The pseudo HTML elements are combined with the rest of elements are combined with the rest of the HTML to create the final HTML DOM.the HTML to create the final HTML DOM.
HTML DOMHTML DOM
HTML Pseudo HTML
Combined
Source DOM
Converter
<div id="container" > <div id="header" /> <div id="leftBar" > <div id="content" > <p> <table> <tr> <td/> </tr> </table> </p> </div>
<?php entries = getEntries() ?> <?php for ($num=1; $num <= 10; $num++ ){ ?> <?php $entries->getEntryText() ?> <?php } ?
PHPPHP
Non Renderable Page Items – Example Continued ..Non Renderable Page Items – Example Continued ..
What about the following caseWhat about the following case
<table> <?php for ($num=1; $num <= 10; $num++ ){ > print("<tr>") print("<td>") print ($recentEntries ->getRecentEntryUrl()) print("</td>") print("</tr>") ?></table>
Since the HTML elements are generated by the script, it Since the HTML elements are generated by the script, it may be difficult to handle this case. Some kind of may be difficult to handle this case. Some kind of interpreter may be required.interpreter may be required.
For initial phase, we could support only the case of pure For initial phase, we could support only the case of pure embedded script based pages.embedded script based pages.
HTML DesignerHTML Designer
EditorEditor ViewerViewerUserActions
HTML DOM
View Layer
Editing Layer
Designer for Visual EditingDesigner for Visual Editing
Consider Designer as a dual layer component
Editing layerEditing layer: All the user actions are restricted to this layer. Users mouse clicks are mapped to the elements in the view layer.
View LayerView Layer: Displays the HTML DOM. User can not directly interact with these elements.
User customization of Page Item in the Editing layer is passed to the HTML DOM via Designer Interaction API.
The view layer receives a DOM change event. Fetches and displays the DOM.
Designer Interaction API
Designer for Visual EditingDesigner for Visual Editing
View to DocumentView to Document
HTML DesignerHTML Designer
EditorEditor ViewerViewerUser
Actions
HTML DOM
Designer Interaction API
Source DOM
Reverse MapperRenderer/Converter
EditorEditorStyledStyled
DocumentDocument
Controller
User modifies the elements (or drag and drop page items) in the editor.
Designer (Editor Layer), passes the information back to the Controller via Designer Interaction API and HTML DOM. Controller translates the HTML DOM modification back to the Source DOM via Reverse Mapper markers.
Controller writes back the information from the Source DOM on to the Styled Document.
The modified Source DOM nodes are translated back to form the combined HTML DOM.
The View (designer) is notified of the combined HTML DOM
Designer (View Layer) fetches the HTML DOM and displays it.
HTML DOM to Source DOM explainedHTML DOM to Source DOM explained
HTML DesignerHTML DesignerEditorEditor
User Action(Table Resize)
HTML DOM
Designer Interaction API
Source DOM
Reverse Mapper
Table
ViewView
Table
(Find Principal Element)
(Find PageItem) (Set CSS
style width)
User clicks on a region in the Editor layer corresponding to <td> in a table component.
Editor Layer, via Designer Interaction API finds the principal element (<table>) corresponding to the selected element (<td>) and displays Table Editor guides.
Assume, user resizes the table. The resize information (style=”width:300px) is passed back to the principal element.
The CSS style is written back to the Page item in the Source DOM corresponding to the principal elementfound via Reverse Mapper.
Page Items in PalettePage Items in Palette
Palette displays list of Page Items that can be dragged and dropped on to the designer.
Assume we have a Palette of Page Items to design blog page.
- Blog Entries- Recent Blog Entries
In case of component based page design, drag and drop "Blog Entries" Page Item may create just one line of code
<blog:blogEntries count="10">
Our design time would provide facilities to bring up a customizer against this "Page Item" to customize, say "No of items to display" to 20, which end up modifying the code as
<blog:blogEntries count="20">
Page Items in Palette ContinuedPage Items in Palette Continued
In case of script embedded page, drag and drop "Blog Entries" page item would end up creating complete code <!-- Begin PageItem: BlogEntries --> <p> <?php entries = getEntries() ?> <table> <?php for ($num=1; $num <= 10; $num++ ){ ?> <tr> <td> <?php $entries->getEntryText() ?> </td> </tr> <?php } ?> </table> </p> <!-- End PageItem: BlogEntries -->
Our design time could still bring up a customizer against this "Page Item" to customize "No of items" to 20, which in turn would rewrite the entry between <!-- Begin Page Item> & <!-- End PageItem> say
<?php for ($num=1; $num <= 20; $num++ ){ ?>
Introducing Visual Web modelingIntroducing Visual Web modeling
In order to support rich design time experience, instead of working on the DOM level nodes (Palette, Navigation, Customizers, Property Editors), it would be easier to work with Java Beans that encapsulates collection of DOM nodes corresponding to a particular Page Item.
Renderable Page Items
In case of renderable page items it is easier because usually an associated object might exist. Ex. JSF components for JSF tags or Tag Handlers for JSTL tags.
<blog: blogEntriesblogEntries count = “10” >
public class blogEntriesblogEntries { int count = 10; public int getCount(){ return count; }}
Introducing Visual Web modeling Continued..Introducing Visual Web modeling Continued..
Script Embeded Page Items
In case of non renderable page items such as Script Embedded or pure HTML elements, it is trickier because an associated object might not exist. In this case some kind of Pseudo beans need to created that encapsulate the tunable attributes of the Page Item as properties.
The “code snippet” corresponding to the Page Item would be re-generated based on property value in the Pseudo bean. <!-- Begin PageItem: BlogEntriesBlogEntries --> <p> <?php entries = getEntries() ?> <table> <?php for ($num=1; $num <= entries.count(); $num++ ){ ?> <tr> <td> <?php $entries->getEntryText() ?> </td> </tr> <?php } ?> </table> </p><!-- End PageItem: BlogEntriesBlogEntries -->
public class blogEntriesblogEntries { int count = 10; public int getCount(){ return count; }}
Visual Web ModelsVisual Web Models Bean RepresentationBean Representation BlogPost.phpBlogPost.php
Introducing Visual Web modeling Continued..Introducing Visual Web modeling Continued..Once a model is created from the beans, now it becomes more generic to be operated up on by the design system.
<!-- Begin PageItem: BlogEntriesBlogEntries --> <p> <?php entries = getBlogEntries() ?> ... </p><!-- End PageItem: BlogEntries -->
public class blogEntriesblogEntries { int count = 10; public int getCount(){ return count; }}
public class recentEntriesrecentEntries { int count = 5; public int getCount(){ return count; }}
BlogPost (.php data objectBlogPost (.php data object))
<!-- Begin PageItem: RecentEntriesRecentEntries --> <p> <?php entries = getRecentEntries() ?> ... </p><!-- End PageItem: BlogEntries -->
BlogPost.jspBlogPost.jsp
<blog:blogEntriesblogEntries count="10">
<blog:recentEntriesrecentEntries count="5">
Unfortunately, this is still not generic enough, because models need to know about beans type.
bean1: blogEntries
bean2: recentEntries
BlogPost (.jsp data objectBlogPost (.jsp data object))bean1: blogEntries
bean2: recentEntries
Introducing Design-time APIIntroducing Design-time APIDesign-time API provides a uniform way to specify rich design time experience for the Page Items. Some of the interfaces are
DesignContext – Corresponding to a page being designedDesignBean – Corresponding to a bean (Page Item)DesignProperty – Corresponding to a bean property
Design-time API are implemented by the framework specific design time support modules. Ex. visualweb.php modules implements these API and adds them to the models provided by the visualweb.models modules. The models themselves are managed centrally.
BeanInfo (static) & DesignInfo (dynamic) are two ways to append design-time functionalities to the DesignBean. Example
BeanInfo.propertyDescriptors - Property Sheet BeanInfo.icon - Navigation Node Icon
DesignInfo.canLink() / link() - dynamic binding (if supported)DesignInfo.propertyChange() - call back property change in the model
Visual Web ModelsVisual Web Models
Design-time API (Continued..)Design-time API (Continued..)Once a model is based on generic Design Bean, it becomes more generic to be used by other parts the design system such as Navigation, Property Sheet, Customizers etc using the Design-time API.
Bean RepresentationBean Representation
public class BlBlogEntriesogEntries { int count = 10; public int getCount(){ return count; }}
BlogPost (.php data objectBlogPost (.php data object))desigbBean1: blogEntriesDB
desigBean2: recentEntriesDB
BlogPost (.jsp data objectBlogPost (.jsp data object))
Design Bean RepresentationDesign Bean Representation
public class BlogEntriesDBBlogEntriesDB implements DesignBean {
private BlBlogEntries ogEntries blogEntries;;
DesignProperty[] dProperties; public DesignProperty[] getDesignProperties(){ return dProperties; }
private initializeDesignProperties(){ .. }
private static Class DesignPropertyImpl implements DesignProperty { ... }}
desigBean2: recentEntriesDB
desigbBean1: blogEntriesDB
Document to ModelDocument to Model
EditorEditorStyledStyled
DocumentDocument
Controller
Parse
fetch
Controller
Source DOMPDL
specificDesign-time
SupportDOM to
Design Beans
Visual Web Model
Convert
The controller fetches the data from Styled Document and parses it to produce the intermediate Source DOM.
Next step is to convert the Source DOM in to Design Beans and add it to the model.
Unlike Visual Web Classic modeling system the task of converting the Source DOM in to Design Bean should be delegated to the PDL specific design-time support implementation.
In case of renderable Page Items, each Source Node may be associated with a single Design Bean.
However, in case of Script Embedded Page Items, the Marker sorrounding the collection of Source DOM may be required to correctly find the corresponding bean and define the Design Bean.
How to support imported pages. Not well known yet.
EditorEditorStyledStyled
DocumentDocument
Controllerwrite
Controller
Source DOMPDL
specificDesign-time
SupportDesign Beans to
Source DOM
Visual Web Model
Convert
Model to DocumentModel to Document
When the model changes it is the responsibility of the controller to write back the changed model content back to the Styled Document.
When Controller is notified of the model changes, the Design Bean Tree is obtained and each Design Bean is traversed to create the Source DOM from it.
Unlike Visual Web Classic, the task of converting the Design Beans to Source DOM node fragments should be delegated to the PDL specific Design-time support implementation.
Model to ViewModel to View
HTML DOMHTML DOM
HTML Designer
fetch DOM
Framework specific
Design-timeSupport
Design Beansto HTML DOM
Convert
Visual Web Model
Just like, when the model changes, the controller writes back the changed model content to the Styled Document, it is also responsible for creating the HTML DOM and notifying the designer View Layer about the HTML DOM change.
When Controller is notified of the model changes, the Design Bean Tree is obtained and each Design Bean is traversed to create the corresponding HTML DOM from it.
Unlike Visual Web Classic, the task of converting the Design Beans to HTML DOM node fragments should be delegated to the PDL specific Design-time support implementation.
View to ModelView to Model
HTML DesignerHTML Designer
EditorEditor ViewerViewerUserActions
HTML DOM
Designer Interaction API
HTML DOM toDesign Bean
Design Beanto HTML DOM
PDL specific
Design-timeSupport
Visual Web Model
Write toDocument
When user modifies the elements item in the editor, Designer (Editor Layer), passes the information back to the Model via Designer Interaction API and HTML DOM. The changes in the HTML DOM is translated back to the Design Bean.
Controller writes back the information from the model to the Styled Document and refreshes the designer View.
The PDL specific Design-time support is used to complete the task of reverse mapping from HTML DOM to Design Bean.
Model to Navigation ViewModel to Navigation View
PDL specific
Design-timeSupport
Design Beansto Openide Node
Convert
Visual Web Model
Navigation View
Visual Web Model
DesignerTopComponent
DataObject
When user switch to the design view the Navigation Controller switches to the Navigation Panel specified via Dsigner TopComponent.
Navigation Panel obtains the model corresponding to the DataObject in the TopComponent Lookup.
The DesignBean tree obtained from the model is encapsulated in Openide Node and displayed via Explorer.
Navigation View to ModelNavigation View to Model
Openide Node toDesign Bean
Visual Web Model
Navigation View
Visual Web Model
Write toDocument
RefreshView
Any user modification to the nodes in the Navigation Explorer (rearrange, rename etc) are translated back to the Design Bean encapsulated by the nodes.
This triggers model change event causing the controller to refresh the view and push the modified data back to the Styled document.
User Modification
OpenideNode
Navigation View to Property SheetNavigation View to Property Sheet
Openide Node toDesign Bean
Navigation ViewOpenide
Node
UserSelectSet as
Activated Node
CreateProperty Sheet
Each node corresponding to the Design Bean has a property sheet derived from the Design Property set of the Design Bean.
The selected node in the Navigation Explorer is set as the Activated Node, which causes the property sheet to display.
Property Sheet to ModelProperty Sheet to Model
Openide Node toDesign Bean
Navigation View
OpenideNode
Property Editor
PropertyChange
Visual Web Model
Write toDocument
RefreshView
When user modifies the property in the property sheet the changed property is set to the DesignProperty of the Design Bean encapsulated by the Node.
This triggers model change event causing the controller to refresh the view and push the modified data back to the Styled document.
Formatting ToolbarFormatting Toolbar
Formatting Toolbar
Button Click
Write toDocument
HTML DesignerHTML Designer
EditorEditor ViewerViewer
HTML DOM
Designer Interaction API
HTML DOM toDesign Bean
Design Beanto HTML DOM
Visual Web Model
Formatting Toolbar is a convenient way of setting CSS styles that are selected by the user.
Formatting toolbar is added to the Designer Editing Layer when the designer top component is created.
When a button in the toolbar is pressed while certain element is selected in the designer, designer passes back the information about the selected elements (along with region of selection) and the button which is pressed.
The controller using the help of PDL design time support decides on how to apply the toolbar button action to the selected element after translating it back to the DesignBean.
For Example, if the selected region is a text inside a <p>, the controller would add a <span><bold> around the text.
CSS Customization ViewCSS Customization View
CSS customization View
UserSelection
Write toDocument
HTML DesignerHTML Designer
EditorEditor ViewerViewer
HTML DOM
Designer Interaction API
HTML DOM toDesign Bean
Design Beanto HTML DOM
Visual Web Model
CSS propertyChange
CSS customization View provides similar functionality to Formatting toolbar except it has no restriction to pre-defined styles, but provide a way to set any CSS styles to the selected Page Item or seclected region of the Page Item
Along with modifying the CSS style property of a page item, it can also provide a way to set CSS selectors from CSS stylesheets added to the web page.
Page Layout Design SupportPage Layout Design Support
●Designer Editing Layer could provide support for designing Page Layouts via guidelines for defining regions like●
HeaderNavigation BarHorizontal MenuFooterSide Bars
●
●However, there should be some kind of design time API support to specify these regions up on which designer could react. ●
●Not well known yet.
Page Template SupportPage Template Support
Creating Page templates:
- Ability to specify templated region.- Ability to specify content region.
Visual Web does not supply its own set of templates. It is up to the frame work to provide pre-defined page templates for specific PDL and the task of creating the web page from the Page Template.
PDL design-time support must provide the proper loader to read from and write to the template file. Also, it is the responsibility of PDL design-time to synchronize the template with that of the pages created from it.
However, Visual Web would provide the following functionalities, closely working with PDL design-time implementation.
Using the Page templates:
- Ability to mark the templated region design only in the designer.
Design-time API might be required. Not well known yet
Visual Web Thread ModelVisual Web Thread Model
Visual Web Classic is plagued with threading issues. While designing for Visual Web Next, proper threading model should be worked out.
Making sure that the following tasks not blocking AWT thread is important.
- Read and write in to the Document- Creating the model- Refreshing the model- Design Bean operations
After the model is refreshed, it should be up to the designer to fetch the HTML DOM and correctly refresh the view in the AWT thread.
Third Party Page ItemsThird Party Page Items
In Visual Web Classic user either gets Rich Visual design or nothing. Visual Web Next should allow intermediate design state too
- Supported degraded design if no metadata is provided. User may be able add Page Items to the page, but should not expect rich design experience. The PDL design-time support should be capable enough to import Page Items based on some sort of configurations files that defines the page items.
Ex. jMaki component definition file specified in JASON format
- Support mid level design experience if some expected metadata is provided via well defined XML format or JASON format.
- Support full fledged design experience if design time API is implemented by the Page Items provider