Design Time View Handlers

This document is provisional and subject to change

Note: this document is provisional and subject to change.

Overview

The JSF specification allows users to configure custom view handlers for their web applications. The custom view handler can change the following aspects of an application:

1) The construction and initialization of the view root. 2) The construction and initialization of the component tree. 3) Adaptation of the component tree to one or more view specification formats (i.e. JSP, XHTML, XML). 4) Rendering of the component tree to the target (i.e. typically rendering to HTML). 5) Store and retrieve view state between requests. 6) Calculate locale and character encoding information for the target. 7) Map viewId's to url's (action URL) that when invoked on a request, will restore the corresponding view. 8) A number of other issues that vary between the 1.1 and 1.2 specifications.

This wide range of capabilities means that assumptions made by the JSF design time can be seriously invalidated by the introduction of a custom view handler. This document covers the significant design time implications of custom view handlers and outlines the requirements for a Design Time View Handler extension mechanism to allow adopters to handle them.

Mechanism for accumulating design-time meta-data for alternative view handler tags when not using JSP wrapper (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=192393#c14). Primarily this arises from the fact that there is no mandatory TLD-like descriptor for some popular alternative view handler such as facelets. This means that we need to find alternative ways to know, for example, what tag and attributes are available.

Support for JSP-editor-like behaviour for tag lookup and EL region partitioniing in the HTML/XML source configuration. To support non-JSP JSF tags, we need to enhance and extend what the HTML SSE configuration provides for situations where we know an XHTML document will be consumed by an alternative view handler.

WPE support for templating. This is a broad issue that affects both JSP views (jsp:include) as well as popular alternative view handlers such as Facelet views (ui:composition). We need to determine the common visual editing tasks involving templates and how to implement them.

Identifying that an alternative view handler is in use. There are many facet-like activities here such as deciding how to update the web.xml file for servlet-mappings as well as whether an XHTML should be tooled for non-JSP view handlers or simply as a flat HTML file using the xml format. We may need to create an alternative view handler facet framework to support this. Retrieved from "http://wiki.eclipse.org/Facelet_Support"