Difference between revisions of "JSF Tools Helios Requirements"
|Line 75:||Line 75:|
=== Resource Loading ===
=== Resource Loading ===
=== New Schema Elements ===
=== New Schema Elements ===
Revision as of 22:14, 18 January 2010
This page is tentative and subject to change without notice
- 1 JSF 2.0 Requirements
JSF 2.0 Requirements
JSF 2.0 adds support for multiple "View Declaration Languages (VDL)" (section 7.6). A VDL is a format by which a JSF view (page) is declared. In JSF 1.X, the only choice supported in the spec was JSP, although through the pluggable view handler facility, others could be added. Facelets are included in JSF 2.0 as the new default VDL for JSF. Per section 10.1, "New features introduced in version 2 and later are only exposed to page authors using Facelets." Facelets uses XHTML instead of JSP as the default XML format for describing views. It also supports two richer view-building formats: templates and composites.
A template, as the name suggests, allows many pages to be defined by having one or more base template files in which individual view instances override some sections but keep others. For example, the template may define a header, left and right menu bars and a footer for all pages; each instance of the template might simply override the middle section with custom content.
A composite is a JSF component that is defined using similar XHTML markup to those used for views. A JSFDeveloper creates a new composite by "composing" one or more other components into a new component. JSF 2.0 introduces a new schema for defining composites through XML composite files.
XHTML source editing
The JSFDeveloper shall be able to do source-level development of Facelet XHTML view files with similar capabilities as are found in the current JSF/JSP source level editor. These capabilities will include:
- Validation and content assist for referenced library namespaces. Namespaces can be defined either explicitly through the Facelet taglib facility or implicitly through the detection of composites through the resource loading facility.
- Validation and content assist for tags declared for use in a Facelet view by use of namespace inclusion. Certain limitations may exist compared to the comparable JSP editing feature because Facelets has lower minimum requirements for tag meta-data. The framework will provide an extensible mechanism by which additional metadata may be added to fill gaps in required metadata. All sources of tag metadata defined in the spec shall also be supported.
- Validation and content assist for tag attributes. Same as section on tags.
- Validation and content-assist for tag attribute values.
- Validation and content assist for EL expressions inside tag attribute values.
- Hyperlink and hover help for namespaces, tags, attributes and EL expressions.
In addition, the following source editing capabilities shall be supported that are not necessarily guaranteed for JSP:
- Validation, content assist, hyperlink and hover help support for EL expressions used in XML text nodes.
- Tag support for the basic Facelet (http://java.sun.com/jsf/facelets), new core (http://java.sun.com/jsf/core), new html (http://java.sun.com/jsf/html), composite component and (??) JSTL subset tags and tag libraries.
- Support for namespaces declared through the composite component mechanism as discovered through the resource loading facility.
Composite Component Development
JSFDeveloper shall be able to do regular schema-based development of composite components. This includes but may not be limited to the inclusion of the requisite schemas in the XML catalog. The framework will provide a tag library interface to all components defined using the composite mechanism.
JSFDeveloper shall be able to create new Composite Component files in a directed way (i.e. wizard).
JSFDeveloper shall be able to access all libraries defined in his project according to the JSF 2.0 specification through:
- Declaration in the web.xml file per Section 11.1.3 of the spec.
- Implicit discovery of all files with the name pattern "META-INF/*.taglib.xml" on the class path.
JSFDeveloper will be able to create new taglib file and at a minimum have schema-based source editing of the files.
JSF 2.0 introduces two major new themes in application configuration: XML file reduction and Resource Loading. Two new schema elements are also added.
The XML file reduction theme consists of a combination of features intended to simplify the amount of application data that is needed in the faces-config file. Two main new features are added to support this: Annotation-based Artifact Declaration and Simplified Navigation.
The Resource Loading features adds a new facility that allows automatic discover of application artifacts through an implicit lookup mechansim. This feature is both implicitly by the system to find composites and is explicitly exposed to the JSFDeveloper for use in finding application resources such as string bundles and images.
Annotation-based Artifact Declaration
JSF 2.0 adds several annotations that my be added to artifact classes. The artifacts supported by the specification per section 11.5.1 are:
-FacesComponent: same as <component> tag; class must extend UIComponent. -FacesConverter: same as <converter> tag; class must extend Converter. -FacesRenderer: same as <renderer> tag; class must extended Renderer. -FacesValidator: same as <validator> tag; class must extend Validator.
In addition, the spec supports a set of annotations for declaring managed beans. This specification is separate from the main spec in anticipation of a more common JavaEE annotation spec for declaring such beans.
ToolsDeveloper shall be provided API to discover all of the above artifacts as though they had been declared in a faces-config file. ToolsDeveloper shall be able determine where the artifact was declared.
JSF 2.0 adds two new navigation concepts to help simplify the control of applications. "Implicit Navigation" is a mechanism by which an automatic navigation rule is created from view X to view Y when the literal value of an action executed in view X is the name of view Y. "Conditional Navigation" allows JSFDeveloper to specify a new "if" element inside <navigation-rule> configurations to use EL expressions to control view transitions.
JSFDeveloper shall have access to implicit navigations in all features that currently support explicit navigation rules. Conditional navigations shall be visually decorated where possible to indicate that they are condition. This decoration shall include the EL expression in use.
ToolsDeveloper shall have access programmatically to the known implicit navigations in an application as though they are explicit navigations. The API shall also provide information about where the implicit navigation is defined. ToolsDeveloper shall have access to information about the conditionality of all explicit navigations.
The resource loading facility (section 2.6) defined by JSF 2.0 allows both the system and the application developer to discover application artifacts at runtime. Per section 2.6.1, resources can be discovered in two ways: by searching the sub-directories of a directory called "resources" in the web application root and by searching the META-INF/resources directory of each jar on the classpath. Resources in these locations are organized by "library name" according to the name of the sub-directory of the "resources" folder where they reside.
ToolsDeveloper shall be provided API that returns all of the discoverable resource libraries in a source project. Included in the information about each such resource library will be a reference back to where it was defined.
The JSF runtime uses the resource loading facility to find composite components.
ToolsDeveloper shall be provided API that can narrow the search for resource libraries to those containing composite components. JSFDeveloper shall have access to all tag libraries defined through this mechanism in all of the ways JSP TLD-defined tag libraries are exposed (caveat: outages may occur where insufficient meta-data is required by the Facelet spec compared to the TLD-spec).
Section 188.8.131.52 of the spec describes a resource locator format for referencing resources. ToolsDeveloper shall be provided an API that constructs and parsers this resource locator format. The API for finding discoverable resources libraries shall allow query using the parsed data structure for the locator reference format.