Version 1


    There are 2 types of tags in VPE: (A) Visible tags and (B) Invisible tags.


    Invisible tags are the simplest to implement. Almost any components library has its own invisible tags: html, jstl, jsf, a4j, richfaces, myfaces, seam, spring. Most of them are parameters and adaptors.


    Then there is a big variety of implementations for visible tags. For the simplicity we can divide them into the 3 groups (depending on their complexity): easy, average and hard to implement tags. Let’s try to classify them.



    1) The EASY to implement tags:

    *Mostly it is tags that are shows as a single HTML tag with certain parameters.

    *To this group we can include all the templates for HTML tags, DocBook tags, and a few from JSF and Rich Faces.



    *Tags that require a well-designed template which is once being implemented do not change its representation in the future.

    * Also it could be tags from the different libraries that have similar representation and we can use 1 template for different tags.

    *To this group we include more than a half tags form the JSF and Rich Faces, JSTL and Facelets libraries.


    3) HARD to implement group:

    Let’s divide tags once again by the type of complexity:


    3A) Tags that should know their parents or children tags. Depending on this the tag could be rendered in a different way: rich:panelMenuGroup, rich:panelMenuItem, rich:tree, rich:treeNode, h:dataTable, h:column.

    *<f:selectItem> will have different representation depending on the parent element.


    3B) Tags that have different representation depending on the trigger (or toggle state).

    rich:collapsiblePanel, rich:collapsibleSubTable, rich:panelMenu, rich:panelMenuGroup.

    * To this subgroup we could also add the togglers, that change this state: rich:dataScroller, rich:collapsibleSubTableToggler.


    3C) Templates that change its view depending on the inserted text: rich:inplaceInput, rich:inplaceSelect.


    3D) Tags that could not live without a pair: rich:column without h:dataTable, rich:panelMenuGroup and rich:panelMenuItem without rich:panelMenu,  rich:treeNode without rich:tree.


    3E) Tables, particularly h:dataTable and rich:dataGrid with its columns and facets. They are hard tags on its own. It's hard to implement correct style, colgroulp, colspan, rowspan. Cell sizes and nested css styles.

    * Nested tables with its css styles.


    3F) <f:facet> -- is a really complex tag. It has a lot of variants because could be put more than once inside different tags. It should have the ability to be put in any place of the template, its children could be placed in 2 different places in the parent, it could not have its own visual node, it should know its children and be able to manipulate them. Different type of facets: header, footer, caption and others. Each tag could handle its facets in a unique way.


    3G) Tags with high html structure complexity or very complex css styles and functions, i.e. <rich:calendar>.


    3H) Tags that have different representation depending on the library version. RF3.3 and RF4 tags. They should know the version before being rendered.


    3I) Includes. Tags from many libraries (jsp, jsf, rf, facelets) that insert page(s) to the current document. There could be conditions of the insertion. Include should calculate dependencies as well.


    3J) Custom tags. Particularly JSF2 Composite -- similar to includes, but should have a certain structure, be placed in a certain location, certain naming conditions.

    * JSP custom tags.



    There are other important rules that should be followed (or at least these rules should be kept in mind while developing the templates):

    1) EL expressions. They should be parsed before rendering the page due to the fact that they could influence on the structure. Bean properties or parameters should be resolved.

    2) Linked Resources (such as css, js, images, html files) should be correctly inserted/tied to the current document.

    3) Templates for tags should be flexible in the changing their settings, css styles, working with children and parents.

    4) The place on the page to render the template should be configurable.

    5) Visual and Source elements should be connected with each other.