Visual Web Next Design Concepts. Winston Prakash Feb 12, PDF Free Download

Visual Web Next Design Concepts Winston Prakash Feb 12, 2008

Some Notations Used 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.

Overall Concept Visual Web Classic 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..java.jsp Designer Visual JSF Framework Config Files Modeling Rich Design Support 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..jsp.xml.php.rhtml Framework Support Designer Framework Visual Web Next Config Files Modeling Rich Design Support

Opening a web page 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. Web Page Loader Data Object Visual Web registers the designer for that web page mime type. Visual Designer Design PHP Styled Document Editor Support Text Editor

EditorSupport API Registering the web page designer 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 Next Formatting Toolbar: To apply predefined styles to the page item being designed. Formatting Toolbar Palette 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. Navigation View HTML Designer CSS Visual Aid Property Sheet 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 View 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. Editor Styled Document Parser HTML DOM fetch DOM HTML Designer Designer fetches the HTML DOM and displays it.

Synchronizing 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. fetch Editor Styled Document Document Event User Edit 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. Considerations - In Split View react to changes in a orderly delayed fashion. - In Tabbed View parse when user switched to design view. Controller Parse Old Merged New HTML DOM fetch DOM HTML Designer Consider doing the parsing and merging in separate thread.

Document to View (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. Considerations The rendered DOM fragments should be marked for reverse mapping. Editor Styled Document fetch Controller Parse Source DOM HTML Combined Renderer Rendered HTML DOM fetch DOM HTML Designer

Renderable 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" >  </div> <div id="leftbar" >   <div id="content" > <blog:blogentriesblogentries count="10"> </div> <div id="rightbar" > </div> <div> <blog:recentitems count="10">

Renderable Page Items Example Continued.. blogentries & recentitems are components, hence need to be rendered, which in turn spit out the HTML fragment. So in order to have a reasonable HTML design, the components need to be rendered first. The rendered HTML fragments are combined with the rest of the HTML to create the final HTML DOM. <div id="container" > <div id="header" /> <div id="leftbar" > <div id="content" > HTML Source DOM Combined <blog:blogentries count="10"> <blog:recententries count="10"> Rendered HTML HTML DOM Renderer

Document to View (Supporting Non Renderable Page Items) 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 PHP ) 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. Considerations The pseudo DOM fragments should be marked for reverse mapping. Editor Styled Document fetch Controller Parse Source DOM HTML Combined Converter Pseudo HTML DOM fetch DOM HTML Designer

Non Renderable Page Items - Example Assume the same blog page and it would be something like <div id="container" > <div id="header" >  </div> <div id="leftbar" >   <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.. <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.. The Designer could allow design and style most of the HTML in the page except for the DOM nodes corresponding to the <?PHP> tag. In order to have a reasonable HTML design, the DOM nodes (<?PHP> tag) need to be converted in to some pseudo elements. The pseudo HTML elements are combined with the rest of the HTML to create the final HTML DOM. <div id="container" > <div id="header" /> <div id="leftbar" > <div id="content" > <p> <table> <tr> <td/> </tr> </table> </p> </div> HTML Source DOM <?php entries = getentries()?> <?php for ($num=1; $num <= 10; $num++ ) {?> <?php $entries- >getentrytext()?> <?php }? Converter Pseudo HTML PHP Combined HTML DOM

Non Renderable Page Items Example Continued.. What 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 may be difficult to handle this case. Some kind of interpreter may be required. For initial phase, we could support only the case of pure embedded script based pages.

Designer for Visual Editing Consider Designer as a dual layer component Editing layer: All the user actions are restricted to this layer. Users mouse clicks are mapped to the elements in the view layer. View 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. User Actions HTML DOM Designer Interaction API Editor Viewer HTML Designer Editing Layer View Layer

View to Document 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. User Actions Editor Styled Document Controller Source DOM Reverse Mapper HTML DOM Designer Interaction API Editor Renderer/ Converter Viewer HTML Designer

HTML DOM to Source DOM explained 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 element found via Reverse Mapper. (Find Page Item) (Find Principal Element) User Action (Table Resize) Source DOM Reverse Mapper Table HTML DOM Editor Designer Interaction API Table View HTML Designer (Set CSS style width)

Page 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 Continued In case of script embedded page, drag and drop "Blog Entries" page item would end up creating complete code  <p> <?php entries = getentries()?> <table> <?php for ($num=1; $num <= 10; $num++ ){?> <tr> <td> <?php $entries->getentrytext()?> </td> </tr> <?php }?> </table> </p>  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 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: blogentries count = 10 > public class blogentries { int count = 10; public int getcount(){ return count; } }

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.  <p> <?php entries = getentries()?> <table> <?php for ($num=1; $num <= entries.count(); $num++ ){?> <tr> <td> <?php $entries->getentrytext()?> </td> </tr> <?php }?> </table> </p>  public class blogentries { int count = 10; public int getcount(){ return count; } }

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. Visual Web Models BlogPost (.php data object) bean1: blogentries bean2: recententries BlogPost (.jsp data object) bean1: blogentries bean2: recententries Bean Representation public class blogentries { int count = 10; public int getcount(){ return count; } } public class recententries { int count = 5; public int getcount(){ return count; } } BlogPost.php  <p> <?php entries = getblogentries()?>... </p>   <p> <?php entries = getrecententries()?>... </p>  BlogPost.jsp <blog:blogentriesblogentries count="10"> <blog:recententries count="5"> Unfortunately, this is still not generic enough, because models need to know about beans type.

Introducing Design-time API Design-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 designed DesignBean 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 BeanInfo.icon DesignInfo.canLink() / link() DesignInfo.propertyChange() - Property Sheet - Navigation Node Icon - dynamic binding (if supported) - call back property change in the model

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. Visual Web Models BlogPost (.php data object) desigbbean1: blogentriesdb desigbean2: recententriesdb BlogPost (.jsp data object) desigbbean1: blogentriesdb desigbean2: recententriesdb Design Bean Representation public class BlogEntriesDB implements DesignBean { private BlogEntries blogentries; DesignProperty[] dproperties; public DesignProperty[] getdesignproperties(){ return dproperties; } private initializedesignproperties(){.. } private static Class DesignPropertyImpl implements DesignProperty {... } } Bean Representation public class BlogEntries { int count = 10; public int getcount(){ return count; } }

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. Document to Model Editor Styled Document fetch Controller Parse Source DOM DOM to Design Beans Convert PDL specific Design-time Support 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. Visual Web Model How to support imported pages. Not well known yet.

Model 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. Editor Styled Document write Controller Source DOM Design Beans to Source DOM Convert PDL specific Design-time Support Visual Web Model

Model to View 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. Visual Web Model Design Beans to HTML DOM HTML DOM Convert fetch DOM HTML Designer Framework specific Design-time Support

View to Model 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. Write to Document Visual Web Model HTML DOM to Design Bean Design Bean to HTML DOM HTML DOM PDL specific Design-time Support Designer Interaction API User Actions Editor Viewer HTML Designer

Model to Navigation View 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. Visual Web Model Convert Design Beans to Openide Node PDL specific Design-time Support Designer TopComponent Data Object Navigation View

Navigation View to Model 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. Write to Document Visual Web Model Openide Node to Design Bean Refresh View User Modification Openide Node Navigation View

Navigation View to Property Sheet Set as Activated Node Navigation View Openide Node User Select Create Property 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. Openide Node to Design Bean

Property Sheet to Model 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. Write to Document Visual Web Model Openide Node to Design Bean Refresh View Property Change Property Editor Openide Node Navigation View

Formatting Toolbar 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. Write to Document Visual Web Model HTML DOM to Design Bean HTML DOM Designer Interaction API Design Bean to HTML DOM Button Click Editor Viewer Formatting Toolbar HTML Designer

CSS Customization View CSS customization View provides similar functionality to Formatting toolbar except it has no restriction to predefined 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. CSS property Change CSS customization View Write to Document Visual Web Model HTML DOM to Design Bean Design Bean to HTML DOM HTML DOM Designer Interaction API User Selection Editor Viewer HTML Designer

Page Layout Design Support Designer Editing Layer could provide support for designing Page Layouts via guidelines for defining regions like Header Navigation Bar Horizontal Menu Footer Side 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.

Creating Page templates: - Ability to specify templated region. - Ability to specify content region. Page Template Support 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 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 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

Visual Web Next Design Concepts. Winston Prakash Feb 12, 2008