 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 276: Design-Time Metadata for JavaServerTM Faces Components
JCP version in use: 2.7 Java Specification Participation Agreement version in use: 2.0 Description: Defines a standard mechanism for associating design-time information with JavaServerTM Faces components. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Dormant the following information has been updates from the original proposal.
2010.04.09: 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.This JSR will leverage the collaborative tools provided by the java.net community. A project will be established on java.net that will contain a public issue tracker for tracking most issues. The community will be able to provide feedback and seek clarification via a monitored public discussion forum. The Early Draft feature of JCP 2.6 will be utilized to allow the public to see the specification in progress. The reference implementation will be developed entirely in the public project on java.net. The TCK will be developed privately by the specification lead. The public can read the names of the people on the Expert Group. No. The Expert Group business is regularly reported on a publicly readable alias. Not via e-mail, but all working materials are publicly available on our java.net project at https://jsf-metadata-spec-public.dev.java.net/. The schedule for the JSR is publicly available, it's current, and I update it regularly. The Update page is kept up to date with the current estimated schedule. The public can read/write to a wiki for my JSR. No. I read and respond to posts on the discussion board for my JSR on jcp.org. Yes. There is an issue-tracker for my JSR that the public can read. Yes, in our java.net project. I have spoken at conferences and events about my JSR recently. Not recently. I am using open-source processes for the development of the RI and/or TCK. Yes, utilizing our java.net project. The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR. Yes.
2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
License Info
2007.05.24
2.13 Please describe the anticipated schedule for the development of this specification.
Early Draft Review: July 2007
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Oracle Name of Contact Person: Jeffrey Stephenson E-Mail Address: jeffrey.stephenson Telephone Number: +1 650 607 3515 Fax Number: +1 650 607 3515 Specification Lead: Jeffrey Stephenson E-Mail Address: jeffrey.stephenson Telephone Number: +1 650 607 3515 Fax Number: +1 650 607 3515 Initial Expert Group Membership: Oracle Supporting this JSR: Oracle Section 2: Request
2.1 Please describe the proposed Specification:Design-time tools require both grammar and metadata information for Java Server Faces (JSF) components in order to provide a polished design-time experience. Grammar information, such as the set of available components and what properties exist on those components, is used by tools to guide the user towards valid editing operations. While grammar information can help the tool support the basic operations for creating and manipulating components, metadata can be used to enhance the design-time experience in a variety of ways. Design-time metadata is perfect for simple customizations like changing what name or icon a tool displays for a component, but it can also be used to arrange components or attributes into categories, or even provide information on common design patterns associated with a component. Although the faces-config.xml language allows a component author to express a great deal of information about their components and renderers, it only has standard syntax for expressing a very minimal set of design-time metadata. In order to provide a polished design-time experience, tool vendors need more information. In the absence of a standard, tool vendors have started to invent proprietary mechanisms for supplying additional design-time metadata for JSF components. Unfortunately, that makes the job of the component author very difficult, if they plan to integrate with multiple tools. In addition, developers that use JSF technology have expressed their frustration and concern with not being able to choose their JSF tool independently from the component library that best meets their needs. The hope is that through this JSR, the Java community can work together to define a standard solution to this problem. The Expert Group will consist of a representative set of tool vendors and component authors, and the feedback of the community will be actively solicited. The goal is to produce a specification that defines:
The resulting specification is intended to be compatible with both JSR 127 and JSR 252 without imposing any restrictions on JSF component authors. In order to ensure that the design-time metadata can be consumed by a wide variety of existing and future JSF tools, it is anticipated that this JSR will not require tool vendors to implement any specific APIs. However, the extension mechanism mentioned above could be utilized to define additional metadata items that are tied to a specific API. For example, additional metadata items could be defined for associating the rich contextual property editors and customizers that are being developed in the Design-Time API for JavaBeans (JSR 273) with JSF components. The extension mechanism gives tool vendors the ability to change and innovate while still benefiting from a shared set of common metadata items and a standard mechanism for providing metadata. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)JavaTM 2 Platform Enterprise Edition (J2EE) 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.This specification will primarily be of interest to component authors and tool vendors working with JavaServer Faces, which is part of the J2EE platform. Should this JSR be voted on by both Executive Committees?No. 2.5 What need of the Java community will be addressed by the proposed specification?Tool vendors have started to invent proprietary mechanisms for supplying design-time metadata for JavaServer Faces (JSF) components. The lack of a standard in this area has made it very difficult for a component author to integrate their components with the ever-growing set of tools that support JSF. Both tool vendors and component authors have acknowledged the need for a standard mechanism. Successful adoption of this standard will enable component authors to provide metadata in one format that will work in all compatible tools, and developers that choose JSF technology for their web applications will be in the ideal situation of being able to pick the tool they want to use independently from the component set that best meets their needs. 2.6 Why isn't this need met by existing specifications?The faces-config.xml language defined in JSR 127 (and later revised in JSR 252) only defines standard syntax for display-name, description, and icon metadata. In order to provide a desirable design-time experience, JSF tool vendors need more information. One could make the argument that this work could be included in a future JSR for the Java Server Faces specification (JSF 2.0). The rationale for proposing a separate JSR now is two-fold. First, this JSR can be accomplished without requiring any changes to the JSF specification, and is intended to be compatible with all existing versions of JSF. Secondly, the relatively small scope of this JSR will allow it to be completed much sooner than a major revision of the JSF specification. It is vital to define a standard now before the number of component sets and proprietary solutions explode. 2.7 Please give a short description of the underlying technology or technologies:This JSR will define a standard mechanism for associating design-time information with JavaServer Faces components. It is intended to be compatible with JavaServer Faces 1.0 (JSR 127) and JavaServer Faces 1.2 (JSR 252). 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Not at this time. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No. 2.10 Are there any security issues that cannot be addressed by the current security model?No. 2.11 Are there any internationalization or localization issues?The specification will provide the ability to vary the value of a metadata item based on locale information. For example, component authors might provide a category name for their component that is translated into multiple languages. The goal is to use existing mechanisms, such as ResourceBundle, to provide this support. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. However, the EG must ensure that this JSR is compatible with JavaServer Faces 1.0 (JSR 127) and JavaServer Faces 1.2 (JSR 252). In addition, although it is anticipated that the resulting specification will not require tool vendors to implement a particular design-time API or architecture, care must be taken to ensure that this JSR is compatible and consistent with other design-time JSRs, such as the Design-Time API for JavaBeans (JSR 273). 2.13 Please describe the anticipated schedule for the development of this specification.Given the relatively small scope of this JSR, the intent is to pursue an aggressive schedule:
2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.E-mail will be the primary mode of communication. Phone conferences and/or face-to-face meetings will be organized if required by the Expert Group. The java.net infrastructure will be leveraged (as described in 2.15). 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.This JSR will leverage the collaborative tools provided by the java.net community. A project will be established on java.net that will contain a public issue tracker for tracking most issues. The community will be able to provide feedback and seek clarification via a monitored public discussion forum. The Early Draft feature of JCP 2.6 will be utilized to allow the public to see the specification in progress. The reference implementation will be developed entirely in the public project on java.net. The TCK will be developed privately by the specification lead. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.The RI and TCK will be delivered stand-alone. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).Not applicable. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The Specification, Reference Implementation, and Technology Compatibility Kit will be made available on a Royalty-Free basis, with commonly-used disclaimers on warranties on the technologies. A reciprocal license will be required as per Section 5C of the JSPA. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Contributions from tool vendors:
3.2 Explanation of how these items might be used as a starting point for the work.The lack of a standard in this area has forced JSF tool vendors to develop proprietary solutions, some of which have been contributed to this JSR as proposed starting points. The contributions from tool vendors, along with input from component authors, and the java.net community will be highly valued by the Expert Group in the effort to define a standard design-time metadata mechanism that meets the needs of the Java community. |
||||||||||||||||||||||||||||||||||||||||
