Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-653
Type: Task Task
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: mojavelinux
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
javaserverfaces-spec-public

Use <faces-config> id attribute as alternative for faces-config.xml naming

Created: 21/Oct/09 02:15 PM   Updated: 08/Nov/13 09:15 PM
Component/s: Configuration/Bootstrapping
Affects Version/s: 2.0
Fix Version/s: 2.2

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All


Issuezilla Id: 653
Status Whiteboard:

cat2 schema size_medium importance_medum

Tags:
Participants: Ed Burns, mojavelinux and rogerk


 Description  « Hide

We should reconsider why the new <name> element was selected in favor of
leveraging the id attribute on <faces-config> for faces-config.xml names. The
motivation is to allow JSF 2 applications to order faces-config.xml files using
the JSF 1.2 XML schema (perhaps in a bundled JAR file).

Somewhere along the way, an assumption was made that using the id attribute
would create a conflict. Here's what Bill Shannon wrote:

"Our deployment descriptors define "id" attributes of type "xsd:ID" on most
elements. Our specs currently make no use of these id attributes. The intent of
these id attributes was to allow tools to identify certain elements in the
standard descriptors so that they could reference those elements from elements
in vendor-specific deployment descriptors. Other similar uses are possible.

...

I bring this up here because there's some risk that this new use of id
attributes would conflict with the current use by vendor-specific tools. Is
anyone aware of any actual use of id attributes in existing tools?"

Based on the premise, a new element was introduced that would avoid any
conflicts. However, I don't see how identifying a faces-config.xml file to link
to vendor-specific descriptors is any different than identifying one
faces-config.xml file from another.

I don't think a valid defense was ever made that there is actually a risk of
conflict. Regardless, Ed stated that the platform EG, including Bill, now has
hardened their position on not using the id attribute. Thus, the <name>
attribute was forged.

I would like to call this decision into question and at least allow the id
attribute to be used as a fallback name.



Ed Burns added a comment - 24/Nov/09 07:40 AM

Prepare to delete api subcomponent


mojavelinux added a comment - 18/Dec/09 01:24 PM

Update target milestone to 2.0 rev a

This is an important issue to solve as soon as possible because it is relevant
to allow 1.2 libraries to participate in ordering


mojavelinux added a comment - 18/Dec/09 01:28 PM

Update subcomponent to bootstrapping (should be Configuration, but no such
component is available)


Ed Burns added a comment - 04/Mar/10 12:08 PM

cat2


Ed Burns added a comment - 22/Mar/10 11:24 AM

schema


Ed Burns added a comment - 15/May/10 07:54 AM

These are targeted at 2.1.


rogerk added a comment - 27/Oct/10 01:10 PM

triage


rogerk added a comment - 27/Oct/10 02:51 PM

triage