8:37 a.m.
>>>> On Tue, 26 Oct 2010 18:04:39 -0400, Andy Schwartz
<andy.schwartz(a)oracle.com> said:
EB> Ok, here's what we'll do for JSF XML syntax.
EB> <f:view xmlns="http://www.w3.org/1999/xhtml"
EB> xmlns:f="http://java.sun.com/jsf/core"
EB> xmlns:h="http://java.sun.com/jsf/html">
EB> <html>
EB> <h:head><h:title>Title</h:title></h:head>
EB> <h:body>
EB> <h2>HTML elements ok</h2>
EB>
EB> </h:body>
EB> </html>
EB> </f:view>
EB>
AS> While this is fine for cases where the page author wants to manually
AS> insert an <f:view> tag, I still think that the fact that Facelets does
AS> not require this is a nice perk. We shouldn't take this shortcut away
AS> from folks who happen to want to use the new XML-style syntax.
AS> Is there some reason why it wouldn't be sufficient to hang XML namespace
AS> declarations off of the <html> element, eg:
AS> <html xmlns="http://www.w3.org/1999/xhtml"
AS> xmlns:f="http://java.sun.com/jsf/core"
AS> xmlns:h="http://java.sun.com/jsf/html">
AS> <h:head><h:title>Title</h:title></h:head>
AS> <h:body>
AS> <h2>HTML elements ok</h2>
AS> </h:body>
AS> </html>
AS> As such I don't believe that we need to add yet another element.
This is fine and valid too. However, I feel that if your root element
is <html> then you should be calling your page XHTML, not XML. In any
case, what you have written above is certainly valid for a .view.xml
file or .xhtml file.
EB> Ok, agreed. It's <f:view> If you want to do Facelets XHTML, then you
EB> just put your stuff on the root <html> element.
AS> Why force folks to add an <f:view> in XML processing mode if we don't
AS> have to? Seems like a step backwards to me. (Am I missing some
AS> requirement that is driving this?)
You don't have to add it.
AS> BTW, one thing that I am not totally clear on... What value does
AS> <h:html> add over plain old <html>?
EB>
EB> It's a resource target, in addition to rendering the <html> element.
EB>
AS> Did we add a new resource target type? Our head/body/form targets were
AS> already covered by the <h:head>, <h:body> and <h:form>
components.
The "resource target type" you refer to was always just a loose and
arbitrary string that is equivalent to the QNAME of the element. In
that sense, we did add a new resource target type. See the renderkit
docs for javax.faces.Output javax.faces.Html
EB> Yes, I read Dan's initial comments but decided to go with the minimal
EB> set you have seen in the design thus far. So, I'll not be introducing
EB> <f:doctype> in this revision.
AS> Does this mean that we will not render any doctype for XML-style views?
The initial requirements for what passes through and what does not,
which went into Appendix A table 1-1, didn't say anything about DOCTYPE.
XML-wise, DOCTYPE is not a processing instruction, CDATA, or comment.
Therefore, it passes through unchanged. Do you think we need to
explicitly address doctype in Appendix A table 1-1?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 11 work days until German Oracle User's Group Conference
12:52 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
On 10/27/10 9:37 AM, Ed Burns wrote:
>>>>> On Tue, 26 Oct 2010 18:04:39 -0400, Andy Schwartz
<andy.schwartz(a)oracle.com> said:
AS> As such I don't believe that we need to add yet another element.
This is fine and valid too. However, I feel that if your root element
is <html> then you should be calling your page XHTML, not XML. In any
case, what you have written above is certainly valid for a .view.xml
file or .xhtml file.
Great. Not sure what the right terminology is, but as long as users of
the Facelets XML-processing mode can continue to use plain old <html>
elements instead of <h:html>, I am happy. :-)
AS> BTW, one thing that I am not totally clear on... What value
does
AS> <h:html> add over plain old <html>?
EB>
EB> It's a resource target, in addition to rendering the <html> element.
EB>
AS> Did we add a new resource target type? Our head/body/form targets were
AS> already covered by the <h:head>, <h:body> and <h:form>
components.
The "resource target type" you refer to was always just a loose and
arbitrary string that is equivalent to the QNAME of the element. In
that sense, we did add a new resource target type. See the renderkit
docs for javax.faces.Output javax.faces.Html
I see. Unfortunately this approach is flawed. The <html> element may
only contain <head> and <body> elements. As such, "html" is not a
valid
target for resource relocation. We need to remove this new requirement
from the 2.1 specification.
If <h:html> cannot serve as a resource target and if <html> is a valid
element in XML processing mode, I am still unclear on the value of
<h:html> and wonder whether this should be included in the 2.1
specification.
On a related note, what's up with <h:title>? :-) Can we kill this off?
Or is there some reason why folks would need to use this instead of <title>?
EB> Yes, I read Dan's initial comments but decided to go with
the minimal
EB> set you have seen in the design thus far. So, I'll not be introducing
EB> <f:doctype> in this revision.
AS> Does this mean that we will not render any doctype for XML-style views?
The initial requirements for what passes through and what does not,
which went into Appendix A table 1-1, didn't say anything about DOCTYPE.
Oh, woops. Dan called this out in his initial "Facelets is XML" email:
3) All markup declarations should be produced by the component tree
(e.g., XML declaration, doctype, namespaces, CDATA, XML comments, etc)
However, I must have glossed over this in our recent exchanges.
XML-wise, DOCTYPE is not a processing instruction, CDATA, or
comment.
Therefore, it passes through unchanged. Do you think we need to
explicitly address doctype in Appendix A table 1-1?
Yes. The problem, which Cay described yesterday, is that the doctype
that is specified inside of the Facelets page is currently serving
double duty. In our legacy xhtml-mode, the doctype is applied both the
generated content, as well as for the Facelets document. The latter is
undesirable, since it leads to validation/tooling problems. We need a
way to specify the doctype for the generated content without misleading
tools into thinking that our Facelets document should comply with the
xhtml document type.
Unfortunately, this gets us back to the need for an f/h:doctype component.
Andy
12:59 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
On 10/27/10 9:37 AM, Ed Burns wrote:
>
>
> AS> Does this mean that we will not render any doctype for XML-style
> views?
>
> The initial requirements for what passes through and what does not,
> which went into Appendix A table 1-1, didn't say anything about DOCTYPE.
>
Oh, btw, I meant to mention... The initial patch that Max provided to
demonstrate this functionality handled all constructs that Facelets
considers to be "instructions" generically in
CompilationManager.writeInstruction():
public void writeInstruction(String value) {
if (this.compiler.isTrimmingXMLInstructions())
return;
This approach covers the doctype case as well. I notice that Mojarra
ended up going with a different approach that selectively handles
specific types of instructions. Perhaps the generic approach might be a
better way to go.
Andy
5656
days inactive
5656
days old
jsr-314-open-mirror@lists.jboss.org
2 comments
2 participants
participants (2)
-
Andy Schwartz -
Ed Burns