-
Notifications
You must be signed in to change notification settings - Fork 874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Added support for Faces 4 changed xmlns namespaces #6096
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,6 +28,7 @@ | |
import org.netbeans.modules.parsing.api.Snapshot; | ||
import org.netbeans.modules.parsing.spi.ParseException; | ||
import org.netbeans.modules.parsing.spi.Parser.Result; | ||
import org.netbeans.modules.web.jsfapi.api.JsfVersion; | ||
import org.netbeans.modules.web.jsfapi.api.LibraryInfo; | ||
|
||
/** | ||
|
@@ -99,12 +100,9 @@ public static Result getEmbeddedParserResult(ResultIterator resultIterator, Stri | |
return null; | ||
} | ||
|
||
public static Node getRoot(HtmlParserResult parserResult, LibraryInfo library) { | ||
Node rootNode = parserResult.root(library.getNamespace()); | ||
if ((rootNode == null || rootNode.children().isEmpty()) && library.getLegacyNamespace() != null) { | ||
rootNode = parserResult.root(library.getLegacyNamespace()); | ||
} | ||
return rootNode; | ||
public static Node getRoot(HtmlParserResult parserResult, LibraryInfo library, JsfVersion jsfVersion) { | ||
String namespace = jsfVersion.getNamespaceUri(library.getDefaultPrefix()); | ||
return parserResult.root(namespace); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this changes the semantic. The way this is written allows using both namespaces, while the new code only allows the "right" one. I would assume, that JSF implementations will recognize also old namespaces and I think the old behavior was sane. You then can also keep the signature to its original form. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From my understanding the old behavior only supported one namespace at a time as well. e.g. when you create a new maven web application, add a new jsf site and add an tag which namespace is not yet present and you hit auto import you only can choose between the namespace of the used jsf version. From my understanding if we want to provide all compatible namespaces for a jsf implementation this would be an feature which is currently not present. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I entered this into a facelets file: <f:view
xmlns="http://www.w3.org/1999/xhtml"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:p="http://primefaces.org/ui"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:head>
</h:head>
<h:body>
<ui:define name="|" />
</h:body>
</f:view> I called completion at position marked with "|". At that point So sorry, but your change introduces a bug, you need to scan all possible namespaces for the libraries. |
||
} | ||
|
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason for the two version implementations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not happy about that mapping as well.
Basically
JSFVersion
is not part of the api module but of implementation moduleweb.jsf
. So reusingJSFVersion
would have meant either to:web.jsfapi
or
web.jsf
as dependencyFrom my perspective it makes more sense to have it as part of the api, at least the feature set which is currently implemented. On the other hand I did not want to merge both classes as it would have created an even huger patchset than already.
So basically the idea would be to eliminate
JSFVersion
and integrate it toJsfVersion
or somewhere else.