Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Helios System Requirements and Architecture"

Line 22: Line 22:
 
#Design time support for the JSF resource loading concept.
 
#Design time support for the JSF resource loading concept.
  
== Flexibility of Adoption ==
+
== Flexibility of Adoption ==
 +
 
 +
Based on lessons learned over almost five years of experience with the JSF project as both committers and adopters, we have come to some conclusions about the limitations of our current bundling architecture with respect to adoption.&nbsp; These are based on the following premises:<br>
 +
 
 +
<br>
 +
 
 +
#The most common, and therefore premier, adoption scenario is to create an update site that is installed directly on top of some subset of WTP and its dependencies.<br>
 +
#Adopters may support other scenarios such as productizing, but they will they will still need to support option 1.<br>
 +
#There is no clean mechanism by which to configure a framework feature except through an extension.<br>
 +
#The WTP API policy and Eclipse annual release cycle combine to make it ip<br>
 +
 
 +
<br>
 +
 
 +
This leads us to the following observations about adoption of the JSF Tools Project:<br>
 +
 
 +
<br>
 +
 
 +
#End-user visible features that appear by default are bad.&nbsp; Examples include the appearance of the WPE action on the Open With action in the project explorer and the validation framework.&nbsp; Once these features are contributed an adopter is stuck with them.&nbsp; Short of doing hacky things like calling non-API methods or worse, calling setAccessible to get private data.&nbsp; This is bad due to premise 1: adopters get stuck exposing things to their users that they may not like or conflict with a similar feature that they want to implement <br>
 +
#The extension mechanism should on<br>
 +
 
 +
<br>
  
 
= Bundling and Deployment Architecture  =
 
= Bundling and Deployment Architecture  =

Revision as of 19:06, 17 February 2010

This document is tentative and subject to change without notice.

Themes

JSF 2.0 Support

The Helios release will introduce system level support for JSF 2.0.  This includes updates to:

  1. Facet and library framework support for JSF 2.0 projects.
  2. The XML catalog (after requisite IP review) for new XML schemas.
  3. The application configuration EMF model (facesconfig) for new XML elements introduced in the release.
  4. Supported web.xml configuration concepts.
  5. The JSF Tag Registry, which will become the authoratative source of information about JSF tags (both JSP and Facelet).
  6. Component tree rendering for the addition of the rendering target concept and an API to retrieve component ids that are in use.


New JSF 2.0 concepts to be supported by the system are:

  1. Annotation-based configuration of JSF artifacts.
  2. Implicit navigation rules formulated from supported action source tags.
  3. Design time support for the JSF resource loading concept.

Flexibility of Adoption

Based on lessons learned over almost five years of experience with the JSF project as both committers and adopters, we have come to some conclusions about the limitations of our current bundling architecture with respect to adoption.  These are based on the following premises:


  1. The most common, and therefore premier, adoption scenario is to create an update site that is installed directly on top of some subset of WTP and its dependencies.
  2. Adopters may support other scenarios such as productizing, but they will they will still need to support option 1.
  3. There is no clean mechanism by which to configure a framework feature except through an extension.
  4. The WTP API policy and Eclipse annual release cycle combine to make it ip


This leads us to the following observations about adoption of the JSF Tools Project:


  1. End-user visible features that appear by default are bad.  Examples include the appearance of the WPE action on the Open With action in the project explorer and the validation framework.  Once these features are contributed an adopter is stuck with them.  Short of doing hacky things like calling non-API methods or worse, calling setAccessible to get private data.  This is bad due to premise 1: adopters get stuck exposing things to their users that they may not like or conflict with a similar feature that they want to implement
  2. The extension mechanism should on


Bundling and Deployment Architecture

System Requirements

Locator Framework

Application Configuration Manager

New Locators

Back to the top