search

jakartaee / faces

Jakarta Faces
Other
107 stars 55 forks source link

Within Resource Identifier, allow resourceName to have path separator #1366

Open eclipse-faces-bot opened 9 years ago

eclipse-faces-bot commented 9 years ago

The expert group discussion for #1141 concluded that resourceName should be allowed to contain path separators.

An insufficient response to this conclusion was the following change to ResourceHandler.createResource()

  • Added this text to createResource(string)

For historical reasons, this method operate correctly when the argument resourceName is of the form libraryName/resourceName, even when resourceName contains '/' characters.

The following additional spec actions must be taken.

1. Fix the wording of the text of createResource() to be:

For historical reasons, this method must operate correctly when the argument resourceName is of the form libraryName/resourceName, even when resourceName contains '/' characters.

2. In section 2.6.1.3 modify the sentence starting with "The set of characters..." to be:

The set of characters that are valid for use in the localePrefix, libraryName, libraryVerison, resourceName and resourceVersion segments of the resource identifier is specififed as XML NameChar excluding the path separator and ‘:’ characters, with the exception of resourceName, which may contain the path separator character.

Affected Versions

[2.2]

eclipse-faces-bot commented 5 years ago
eclipse-faces-bot commented 9 years ago

@glassfishrobot Commented Reported by @edburns

eclipse-faces-bot commented 9 years ago

@glassfishrobot Commented arendvr.com said: If resourceName may contain path separators, could that not create ambiguity with libraryVersion or resourceVersion?

For example the resourceIdentifier "libName/1_0/resName/2_0" might mean libraryName=libName, libraryVersion=1_0, resourceName=resName, resourceVersion=2_0 or libraryName=libName, libraryVersion=, resourceName=1_0/resName/2_0, resourceVersion=

libraryName is restricted to prevent ambiguity with libraryVersion (JSF 2.2 Spec, page 78). Maybe resourceName should have a similar restriction?

Or maybe this ambiguity is already dealt with elsewhere? For instance I didn't read through the whole algorithm in 2.6.1.4.

eclipse-faces-bot commented 9 years ago

@glassfishrobot Commented arendvr.com said: Other possible problems:

eclipse-faces-bot commented 8 years ago

@glassfishrobot Commented arendvr.com said: Not addressed by JSF 2.3 Early Draft Review.

eclipse-faces-bot commented 7 years ago

@glassfishrobot Commented arendvr.com said: See other discussions: https://community.oracle.com/thread/3682349 https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2017-01/message/117

Also in my opinion this is not about supporting "historical reasons" as stated in the Javadoc of ResourceHandler.createResource() . Multiple levels of path separators are useful when organizing many resources. They are used for example by Webjars and Primefaces:

eclipse-faces-bot commented 9 years ago

@glassfishrobot Commented Issue-Links: is related to JAVASERVERFACES_SPEC_PUBLIC-1141

eclipse-faces-bot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-1366

zenonwch commented 2 months ago

Hi, any chances to see the implementation of the conclusion? It's been over 9 years ;).

tandraschko commented 2 months ago

whats your exact problem?

IMO the spec is fine here as this is valid: <h:outputScript library="primefaces" name="jquery/jquery.js" />

this not: <h:outputScript library="primefaces/jquery" name="jquery.js" />

zenonwch commented 2 months ago

Sorry for the late answer. But this, unfortunately, is not valid:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
                xmlns:productForm="http://xmlns.jcp.org/jsf/composite/cforms/myproductsubfolder"
                xmlns:userForm="http://xmlns.jcp.org/jsf/composite/cforms/myusersubfolder"
                template="/WEB-INF/template.xhtml">