4:10 p.m.
>>>> On Tue, 26 Oct 2010 13:15:18 -0400, Andy Schwartz
<andy.schwartz(a)oracle.com> said:
AS> BTW, regarding Ed's earlier comment:
EB> the most important manifestation of that, in my opinion, is the
EB> requirement to have *all* elements prefixed. For example, a
EB> proper JSF
EB> XML Syntax View would look like this.
EB>
EB> <?xml version="1.0" encoding="UTF-8"?>
EB> <weNeedSomeRootElement
EB> xmlns:html="http://www.w3.org/1999/xhtml"
EB> xmlns:h="http://java.sun.com/jsf/html">
AS> We already have several potential elements/tags that can serve as the
AS> root level element, including eg:
AS> - <html>
AS> - <h:html>
AS> - <f:view>
Ok, here's what we'll do for JSF XML syntax.
<f:view xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<html>
<h:head><h:title>Title</h:title></h:head>
<h:body>
<h2>HTML elements ok</h2>
</h:body>
</html>
</f:view>
AS> As such I don't believe that we need to add yet another element.
Ok, agreed. It's <f:view> If you want to do Facelets XHTML, then you
just put your stuff on the root <html> element.
AS> This got me to thinking though... I believe that we have a fairly big
AS> gap in our XML strategy: I don't see any straightforward way to specify
AS> a doctypte that will be passed through to the browser. Earlier Dan had
AS> suggested adding new elements for this purpose:
> 3) All markup declarations should be produced by the component
tree
> (e.g., XML declaration, doctype, namespaces, CDATA, XML comments, etc)
> This means we need the following tags:
> f:document
> f:doctype
> f:comment (why not, it is just xml)
> f:cdata
> (The prefix is debatable, I'm just throwing it out there)
AS> We have added an h:html component in 2.1 - but as far as I can see we
AS> haven't addressed the other items. I think that we minimally need some
AS> way to specify the doctype - eg. an h:doctype element since without this
AS> the documents rendered in our XML processing mode will be doctype-less.
AS> BTW, one thing that I am not totally clear on... What value does
AS> <h:html> add over plain old <html>?
It's a resource target, in addition to rendering the <html> element.
Yes, I read Dan's initial comments but decided to go with the minimal
set you have seen in the design thus far. So, I'll not be introducing
<f:doctype> in this revision.
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
4:34 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
Ed,
I think its a little weird for <f:view> to start rendering stuff,
especially if its only in XML mode. Further, such a change is not
backwards compatible with components that are already outputting the
DOCTYPE.
I think that the most obvious short term solution is h:doctype. However
I think that for the next version we should really look at making things
simple for people who just want to bang in HTML. I think that rather
than going down the whole h: taglib route we really should be looking at
adding taghandler magic such that page authors can bang out elements in
the HTML namespace as they see fit and we handle making some of the
tags, like say <html:head> and <html:body> components if we need to.
If we do that, there are only four cases where we need extra support for
sending XML constructs for interpretation by the browser:
DOCTYPE
comments
processing instructions
CDATA
Of these, the last three don't come up very often and I can live with
page authors needing to place these in CDATA blocks for now. However,
the first of these appears in every page, so I don't see the CDATA
workaround as suitable. So, while I suspect that we didn't need an
<h:html>, I think an <h:doctype> is the best solution to the problem.
-- Blake Sullivan
On 10/26/10 2:10 PM, Ed Burns wrote:
>>>>> On Tue, 26 Oct 2010 13:15:18 -0400, Andy
Schwartz<andy.schwartz(a)oracle.com> said:
AS> BTW, regarding Ed's earlier comment:
EB> the most important manifestation of that, in my opinion, is the
EB> requirement to have *all* elements prefixed. For example, a
EB> proper JSF
EB> XML Syntax View would look like this.
EB>
EB> <?xml version="1.0" encoding="UTF-8"?>
EB> <weNeedSomeRootElement
EB> xmlns:html="http://www.w3.org/1999/xhtml"
EB> xmlns:h="http://java.sun.com/jsf/html">
AS> We already have several potential elements/tags that can serve as the
AS> root level element, including eg:
AS> -<html>
AS> -<h:html>
AS> -<f:view>
Ok, here's what we'll do for JSF XML syntax.
<f:view xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<html>
<h:head><h:title>Title</h:title></h:head>
<h:body>
<h2>HTML elements ok</h2>
</h:body>
</html>
</f:view>
AS> As such I don't believe that we need to add yet another element.
Ok, agreed. It's<f:view> If you want to do Facelets XHTML, then you
just put your stuff on the root<html> element.
AS> This got me to thinking though... I believe that we have a fairly big
AS> gap in our XML strategy: I don't see any straightforward way to specify
AS> a doctypte that will be passed through to the browser. Earlier Dan had
AS> suggested adding new elements for this purpose:
>> 3) All markup declarations should be produced by the component tree
>> (e.g., XML declaration, doctype, namespaces, CDATA, XML comments, etc)
>> This means we need the following tags:
>> f:document
>> f:doctype
>> f:comment (why not, it is just xml)
>> f:cdata
>> (The prefix is debatable, I'm just throwing it out there)
AS> We have added an h:html component in 2.1 - but as far as I can see we
AS> haven't addressed the other items. I think that we minimally need some
AS> way to specify the doctype - eg. an h:doctype element since without this
AS> the documents rendered in our XML processing mode will be doctype-less.
AS> BTW, one thing that I am not totally clear on... What value does
AS> <h:html> add over plain old<html>?
It's a resource target, in addition to rendering the<html> element.
Yes, I read Dan's initial comments but decided to go with the minimal
set you have seen in the design thus far. So, I'll not be introducing
<f:doctype> in this revision.
Ed
5:04 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
On 10/26/10 5:10 PM, Ed Burns wrote:
Ok, here's what we'll do for JSF XML syntax.
<f:view xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<html>
<h:head><h:title>Title</h:title></h:head>
<h:body>
<h2>HTML elements ok</h2>
</h:body>
</html>
</f:view>
While this is fine for cases where the page author wants to manually
insert an <f:view> tag, I still think that the fact that Facelets does
not require this is a nice perk. We shouldn't take this shortcut away
from folks who happen to want to use the new XML-style syntax.
Is there some reason why it wouldn't be sufficient to hang XML namespace
declarations off of the <html> element, eg:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:head><h:title>Title</h:title></h:head>
<h:body>
<h2>HTML elements ok</h2>
</h:body>
</html>
AS> As such I don't believe that we need to add yet another
element.
Ok, agreed. It's <f:view> If you want to do Facelets XHTML, then you
just put your stuff on the root <html> element.
Why force folks to add an <f:view> in XML processing mode if we don't
have to? Seems like a step backwards to me. (Am I missing some
requirement that is driving this?)
AS> BTW, one thing that I am not totally clear on... What value
does
AS> <h:html> add over plain old <html>?
It's a resource target, in addition to rendering the <html> element.
Did we add a new resource target type? Our head/body/form targets were
already covered by the <h:head>, <h:body> and <h:form> components.
Yes, I read Dan's initial comments but decided to go with the
minimal
set you have seen in the design thus far. So, I'll not be introducing
<f:doctype> in this revision.
Does this mean that we will not render any doctype for XML-style views?
Andy
7:13 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
Well, as far as XML is concerned, you can hang namespace definitions off
of any element, so <html> is sufficient.
-- Blake Sullivan
On 10/26/10 3:04 PM, Andy Schwartz wrote:
On 10/26/10 5:10 PM, Ed Burns wrote:
> Ok, here's what we'll do for JSF XML syntax.
>
> <f:view xmlns="http://www.w3.org/1999/xhtml"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html">
> <html>
> <h:head><h:title>Title</h:title></h:head>
> <h:body>
>
> <h2>HTML elements ok</h2>
>
> </h:body>
> </html>
> </f:view>
While this is fine for cases where the page author wants to manually
insert an <f:view> tag, I still think that the fact that Facelets does
not require this is a nice perk. We shouldn't take this shortcut away
from folks who happen to want to use the new XML-style syntax.
Is there some reason why it wouldn't be sufficient to hang XML
namespace declarations off of the <html> element, eg:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:head><h:title>Title</h:title></h:head>
<h:body>
<h2>HTML elements ok</h2>
</h:body>
</html>
> AS> As such I don't believe that we need to add yet another element.
>
> Ok, agreed. It's <f:view> If you want to do Facelets XHTML, then you
> just put your stuff on the root <html> element.
Why force folks to add an <f:view> in XML processing mode if we don't
have to? Seems like a step backwards to me. (Am I missing some
requirement that is driving this?)
> AS> BTW, one thing that I am not totally clear on... What value does
> AS> <h:html> add over plain old <html>?
>
> It's a resource target, in addition to rendering the <html> element.
Did we add a new resource target type? Our head/body/form targets
were already covered by the <h:head>, <h:body> and <h:form>
components.
> Yes, I read Dan's initial comments but decided to go with the minimal
> set you have seen in the design thus far. So, I'll not be introducing
> <f:doctype> in this revision.
Does this mean that we will not render any doctype for XML-style views?
Andy
9:02 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
Just from the point of view of namespaces, you can certainly use html
as the root. The difficulty is the doctype. An XML processing tool has
every reason to expect that a document starting with
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
is a conforming document.
However, a JSF page is not--it aims to produce such a document (at
least when rendered to XHTML).
That's why today you get wiggly underlines in editors, exceptions in
XSLT scripts, and so on, when you try to process JSF pages.
So, the DOCTYPE needs to be output, not included. That could be done
with attributes of a top level element or with a child element.
That means the top element should not be html, but it could be h:html,
or, of course, f:view.
Cheers,
Cay
NB. Not having an option for rendering a DOCTYPE would be bad--we want
users to be able to produce proper XHTML. For one thing, if you omit
the DOCTYPE, you can trigger quirks mode in commonly used browsers.
9:19 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
I agree. Every single generated HTML document needs a doc-type.
I was proposing something like this:
<f:view xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:doctype>html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1- transitional.dtd"</h:doctype>
<html>
<h:head><h:title>Title</h:title></h:head>
<h:body>
<h2>HTML elements ok</h2>
</h:body>
</html>
</f:view>
There a re a bunch of different ways that a docType tag could be
implemented, but I thought this might be the easiest for customers who
are really just copying and pasting and don't want to know what the
different parts of the DOCTYPE mean.
-- Blake Sullivan
On 10/26/10 7:02 PM, Cay Horstmann wrote:
Just from the point of view of namespaces, you can certainly use
html
as the root. The difficulty is the doctype. An XML processing tool has
every reason to expect that a document starting with
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
is a conforming document.
However, a JSF page is not--it aims to produce such a document (at
least when rendered to XHTML).
That's why today you get wiggly underlines in editors, exceptions in
XSLT scripts, and so on, when you try to process JSF pages.
So, the DOCTYPE needs to be output, not included. That could be done
with attributes of a top level element or with a child element.
That means the top element should not be html, but it could be h:html,
or, of course, f:view.
Cheers,
Cay
NB. Not having an option for rendering a DOCTYPE would be bad--we want
users to be able to produce proper XHTML. For one thing, if you omit
the DOCTYPE, you can trigger quirks mode in commonly used browsers.
11:29 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
Sure, that's great. Except, it should probably be f:doctype since it
is not HTML specific.
Or, if we cared about consistency with JSP, we could use the same
attributes as jsp:output:
<f:doctype omit-xml-declaration="no"
doctype-root-element="html"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional...
On Wed, Oct 27, 2010 at 9:19 AM, Blake Sullivan
<blake.sullivan(a)oracle.com> wrote:
I agree. Every single generated HTML document needs a doc-type.
I was proposing something like this:
<f:view xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<h:doctype>html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1- transitional.dtd"</h:doctype>
<html>
<h:head><h:title>Title</h:title></h:head>
<h:body>
<h2>HTML elements ok</h2>
</h:body>
</html>
</f:view>
There a re a bunch of different ways that a docType tag could be
implemented, but I thought this might be the easiest for customers who are
really just copying and pasting and don't want to know what the different
parts of the DOCTYPE mean.
-- Blake Sullivan
On 10/26/10 7:02 PM, Cay Horstmann wrote:
>
> Just from the point of view of namespaces, you can certainly use html
> as the root. The difficulty is the doctype. An XML processing tool has
> every reason to expect that a document starting with
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>
> is a conforming document.
>
> However, a JSF page is not--it aims to produce such a document (at
> least when rendered to XHTML).
>
> That's why today you get wiggly underlines in editors, exceptions in
> XSLT scripts, and so on, when you try to process JSF pages.
>
> So, the DOCTYPE needs to be output, not included. That could be done
> with attributes of a top level element or with a child element.
>
> That means the top element should not be html, but it could be h:html,
> or, of course, f:view.
>
> Cheers,
>
> Cay
>
> NB. Not having an option for rendering a DOCTYPE would be bad--we want
> users to be able to produce proper XHTML. For one thing, if you omit
> the DOCTYPE, you can trigger quirks mode in commonly used browsers.
4:33 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
Hi guys,
I agree that we definitely need an h(?):doctype.
@Ed: please revisit your decision!
best regards,
Martin
On 10/27/10, Cay Horstmann <cay.horstmann(a)gmail.com> wrote:
Sure, that's great. Except, it should probably be f:doctype since
it
is not HTML specific.
Or, if we cared about consistency with JSP, we could use the same
attributes as jsp:output:
<f:doctype omit-xml-declaration="no"
doctype-root-element="html"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional...
On Wed, Oct 27, 2010 at 9:19 AM, Blake Sullivan
<blake.sullivan(a)oracle.com> wrote:
> I agree. Every single generated HTML document needs a doc-type.
>
> I was proposing something like this:
>
> <f:view xmlns="http://www.w3.org/1999/xhtml"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html">
> <h:doctype>html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd"</h:doctype>
> <html>
> <h:head><h:title>Title</h:title></h:head>
> <h:body>
> <h2>HTML elements ok</h2>
> </h:body>
> </html>
> </f:view>
>
> There a re a bunch of different ways that a docType tag could be
> implemented, but I thought this might be the easiest for customers who are
> really just copying and pasting and don't want to know what the different
> parts of the DOCTYPE mean.
>
> -- Blake Sullivan
>
> On 10/26/10 7:02 PM, Cay Horstmann wrote:
>>
>> Just from the point of view of namespaces, you can certainly use html
>> as the root. The difficulty is the doctype. An XML processing tool has
>> every reason to expect that a document starting with
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>>
>> is a conforming document.
>>
>> However, a JSF page is not--it aims to produce such a document (at
>> least when rendered to XHTML).
>>
>> That's why today you get wiggly underlines in editors, exceptions in
>> XSLT scripts, and so on, when you try to process JSF pages.
>>
>> So, the DOCTYPE needs to be output, not included. That could be done
>> with attributes of a top level element or with a child element.
>>
>> That means the top element should not be html, but it could be h:html,
>> or, of course, f:view.
>>
>> Cheers,
>>
>> Cay
>>
>> NB. Not having an option for rendering a DOCTYPE would be bad--we want
>> users to be able to produce proper XHTML. For one thing, if you omit
>> the DOCTYPE, you can trigger quirks mode in commonly used browsers.
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
4:09 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
On 10/27/10 12:29 AM, Cay Horstmann wrote:
Sure, that's great. Except, it should probably be f:doctype since
it
is not HTML specific.
I think f:doctype works. Though we do seem to be blurring the lines a
bit between the h: and f: tag libraries. The old JSP taglib doc for h:
says:
This tag library contains JavaServer Faces component tags for all
UIComponent + HTML RenderKit Renderer combinations defined in the
JavaServer Faces Specification.
And doc for the f: taglib:
The core JavaServer Faces custom actions that are independent of any
particular RenderKit.
These descriptions seem to be accurate for 1.2. As of 2.0 we have
started adding tags into the f: taglib that actually do have
corresponding Renderers (or ClientBehaviorRenderers) in the HTML_BASIC
standard render kit. (I am thinking of f:viewParam and f:ajax.)
Would f:doctype be similar to f:viewParam in that we would introduce a
new component + Renderer in the HTML_BASIC render kit?
Or, if we cared about consistency with JSP, we could use the same
attributes as jsp:output:
<f:doctype omit-xml-declaration="no"
doctype-root-element="html"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional...
Ah, good old jsp:output. The highlight of my day was reviewing this
reference doc:
http://java.sun.com/products/jsp/syntax/2.0/syntaxref2022.html
My favorite part:
The JSP container will not include the XML declaration in the output
when either of the following is true:
You set the omit-xml-declaration attribute of the jsp:output element
to either true or yes.
You have a jsp:root element in your JSP document, and you do not
specify omit-xml-declaration="false" in jsp:output.
The JSP container will include the XML declaration in the output when
either of the following is true:
You set the omit-xml-declaration attribute of the jsp:output element
to either false or no.
You do not have a jsp:root action in your JSP document, and you do not
specify the omit-xml-declaration attribute in jsp:output.
I had the same reaction to this that Bart Simpson had to "Don't do what
Donnie Don't Does": They could have made this clearer. [1] :-)
If we do follow a jsp:output-like solution, I think that we would want to:
- Separate out the XML declaration part. This doesn't seem to make
sense on an f:doctype tag.
- Massage the attribute names to be more in line with JSF naming
conventions, eg. "rootElement", "public", "system"
The XML declaration part is interesting on its own. When running in the
new XML/JSPX processing modes, we do not want to pass this through by
default - ie. the XML declaration pertains to the Facelets document
itself, not to the generated content. However, when rendering
text/xhtml content, we do want to render an XML declaration so that our
rendered document will be valid XML. Rather than requiring the page
author to provide a hint to control this behavior (like jsp:output's
omit-xml-declaration attribute), I would prefer that the
RenderKit/ResponseWriter detect this case and handle it in a transparent
manner. Does this sound reasonable/doable?
Andy
[1] http://www.snpp.com/episodes/1F06.html
6:18 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
On 10/27/10 2:09 PM, Andy Schwartz wrote:
On 10/27/10 12:29 AM, Cay Horstmann wrote:
> Sure, that's great. Except, it should probably be f:doctype since it
> is not HTML specific.
I think that the idea is that it shouldn't be in h: because it applies
to all SGML-derived languages.
-- Blake
I think f:doctype works. Though we do seem to be blurring the lines
a
bit between the h: and f: tag libraries. The old JSP taglib doc for
h: says:
> This tag library contains JavaServer Faces component tags for all
> UIComponent + HTML RenderKit Renderer combinations defined in the
> JavaServer Faces Specification.
And doc for the f: taglib:
> The core JavaServer Faces custom actions that are independent of any
> particular RenderKit.
These descriptions seem to be accurate for 1.2. As of 2.0 we have
started adding tags into the f: taglib that actually do have
corresponding Renderers (or ClientBehaviorRenderers) in the HTML_BASIC
standard render kit. (I am thinking of f:viewParam and f:ajax.)
Would f:doctype be similar to f:viewParam in that we would introduce a
new component + Renderer in the HTML_BASIC render kit?
> Or, if we cared about consistency with JSP, we could use the same
> attributes as jsp:output:
>
> <f:doctype omit-xml-declaration="no"
> doctype-root-element="html"
> doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
>
>
doctype-system="http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional...
>
Ah, good old jsp:output. The highlight of my day was reviewing this
reference doc:
http://java.sun.com/products/jsp/syntax/2.0/syntaxref2022.html
My favorite part:
> The JSP container will not include the XML declaration in the output
> when either of the following is true:
>
> You set the omit-xml-declaration attribute of the jsp:output element
> to either true or yes.
> You have a jsp:root element in your JSP document, and you do not
> specify omit-xml-declaration="false" in jsp:output.
>
> The JSP container will include the XML declaration in the output when
> either of the following is true:
>
> You set the omit-xml-declaration attribute of the jsp:output element
> to either false or no.
> You do not have a jsp:root action in your JSP document, and you do
> not specify the omit-xml-declaration attribute in jsp:output.
I had the same reaction to this that Bart Simpson had to "Don't do
what Donnie Don't Does": They could have made this clearer. [1] :-)
If we do follow a jsp:output-like solution, I think that we would want
to:
- Separate out the XML declaration part. This doesn't seem to make
sense on an f:doctype tag.
- Massage the attribute names to be more in line with JSF naming
conventions, eg. "rootElement", "public", "system"
The XML declaration part is interesting on its own. When running in
the new XML/JSPX processing modes, we do not want to pass this through
by default - ie. the XML declaration pertains to the Facelets document
itself, not to the generated content. However, when rendering
text/xhtml content, we do want to render an XML declaration so that
our rendered document will be valid XML. Rather than requiring the
page author to provide a hint to control this behavior (like
jsp:output's omit-xml-declaration attribute), I would prefer that the
RenderKit/ResponseWriter detect this case and handle it in a
transparent manner. Does this sound reasonable/doable?
Andy
[1] http://www.snpp.com/episodes/1F06.html
10:54 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Namespace handling [Was: Chapter 11: The JSF XML View Syntax]
(Tweaking the subject in case folks are tuning out of our very long
prior discussion...)
On 10/26/10 6:04 PM, Andy Schwartz wrote:
On 10/26/10 5:10 PM, Ed Burns wrote:
> Ok, here's what we'll do for JSF XML syntax.
>
> <f:view xmlns="http://www.w3.org/1999/xhtml"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html">
> <html>
> <h:head><h:title>Title</h:title></h:head>
> <h:body>
>
> <h2>HTML elements ok</h2>
>
> </h:body>
> </html>
> </f:view>
>
While this is fine for cases where the page author wants to manually
insert an <f:view> tag, I still think that the fact that Facelets does
not require this is a nice perk.
I somewhat randomly stumbled across another problem with the above
approach: it doesn't work. :-(
The problem: when the default xhtml namespace is specified on <f:view>,
this namespace does not get passed down to the browser. As a result,
the xhtml elements that the browser sees are not properly namespaced and
the browser fails to handle these as xhtml elements.
This is yet another case where there is ambiguity regarding the role of
an XML construct - ie. a namespace specified in a Facelets document
clearly applies to the document itself but could (and in this
particular case should) also apply to the rendered content.
Of course, the following approach works just fine:
In this case Facelets passes the default namespace through to the
browser along with the <html> element.
While this is a fine workaround, I am concerned that such dramatically
different behavior in response to such a small/subtle difference in the
view definition is bad for our end users.
I don't know that this is a spec issue (other than making sure that the
spec does not contain references to the above broken form), but thought
this was worth raising here as this likely affects all JSF/Facelets
implementations. I don't know the Faclets compiler code especially
well, but I am wondering whether it could do some bookkeeping to
detect/work around cases like this where default namespaces should in
fact be propagated down to the browser. Or, alternatively, perhaps a
solution could be implemented at the ResponseWriter level, though it
might be better to catch/correct this sort of thing earlier (Facelets
compilation time) rather than later (render response).
Thoughts? Do folks think that I should log implementation bugs and/or a
spec issue for this?
Andy
11:08 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Namespace handling [Was: Chapter 11: The JSF XML View Syntax]
I was thinking that this was an XHTML ResponseWriter thing. It's not
like the ResponseWriter doesn't know that nobody has output a prefix
mapping for XHTML yet (ignoring the case where it was sent out through
unescaped text and even then creating a new mapping isn't the end of the
world as long as it doesn't conflict).
We will eventually have a bigger problem that the ResponseWriter
interface allows no way to specify a namespace. This is lame and I'm
not a big fan of the workaround of abusing the default namespace or
passing the prefixes in with the element names.
-- Blake Sullivan
On 10/28/10 8:54 AM, Andy Schwartz wrote:
(Tweaking the subject in case folks are tuning out of our very long
prior discussion...)
On 10/26/10 6:04 PM, Andy Schwartz wrote:
> On 10/26/10 5:10 PM, Ed Burns wrote:
>> Ok, here's what we'll do for JSF XML syntax.
>>
>> <f:view xmlns="http://www.w3.org/1999/xhtml"
>> xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:h="http://java.sun.com/jsf/html">
>> <html>
>> <h:head><h:title>Title</h:title></h:head>
>> <h:body>
>>
>> <h2>HTML elements ok</h2>
>>
>> </h:body>
>> </html>
>> </f:view>
>
>
> While this is fine for cases where the page author wants to manually
> insert an <f:view> tag, I still think that the fact that Facelets
> does not require this is a nice perk.
I somewhat randomly stumbled across another problem with the above
approach: it doesn't work. :-(
The problem: when the default xhtml namespace is specified on
<f:view>, this namespace does not get passed down to the browser. As
a result, the xhtml elements that the browser sees are not properly
namespaced and the browser fails to handle these as xhtml elements.
This is yet another case where there is ambiguity regarding the role
of an XML construct - ie. a namespace specified in a Facelets document
clearly applies to the document itself but could (and in this
particular case should) also apply to the rendered content.
Of course, the following approach works just fine:
> <f:view xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html">
> <html xmlns="http://www.w3.org/1999/xhtml">
In this case Facelets passes the default namespace through to the
browser along with the <html> element.
While this is a fine workaround, I am concerned that such dramatically
different behavior in response to such a small/subtle difference in
the view definition is bad for our end users.
I don't know that this is a spec issue (other than making sure that
the spec does not contain references to the above broken form), but
thought this was worth raising here as this likely affects all
JSF/Facelets implementations. I don't know the Faclets compiler code
especially well, but I am wondering whether it could do some
bookkeeping to detect/work around cases like this where default
namespaces should in fact be propagated down to the browser. Or,
alternatively, perhaps a solution could be implemented at the
ResponseWriter level, though it might be better to catch/correct this
sort of thing earlier (Facelets compilation time) rather than later
(render response).
Thoughts? Do folks think that I should log implementation bugs and/or
a spec issue for this?
Andy
11:57 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Namespace handling [Was: Chapter 11: The JSF XML View Syntax]
On 10/28/10 12:08 PM, Blake Sullivan wrote:
I was thinking that this was an XHTML ResponseWriter thing. It's
not
like the ResponseWriter doesn't know that nobody has output a prefix
mapping for XHTML yet (ignoring the case where it was sent out through
unescaped text and even then creating a new mapping isn't the end of
the world as long as it doesn't conflict).
Right. I think this would work well for simple use cases - such as
ensuring that the root <html> element ends up with the proper xhtml
namespace.
Should we consider more complex use cases, eg:
<f:view xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns="http://www.w3.org/1999/xhtml">
<html>
<h:head></h:head>
<h:body xmlns="http://www.w3.org/2000/svg">
<svg version="1.1" ...>
<circle .../>
</svg>
</h:body>
</h:head>
</html>
</f:view>
In this case, the Facelets compiler has some chance of figuring out that
the SVG namespace needs to be pushed down to the <svg> element. By the
time we get to the ResponseWriter, we have less information available to
us, and thus harder to correct arbitrary missing namespaces.
I don't know how much we care about solving this more generic case. The
xhtml namespace issue is clearly more pressing.
We will eventually have a bigger problem that the ResponseWriter
interface allows no way to specify a namespace. This is lame and I'm
not a big fan of the workaround of abusing the default namespace or
passing the prefixes in with the element names.
Agreed.
Andy
-- Blake Sullivan
12:32 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Namespace handling [Was: Chapter 11: The JSF XML View Syntax]
On 10/28/10 9:57 AM, Andy Schwartz wrote:
On 10/28/10 12:08 PM, Blake Sullivan wrote:
> I was thinking that this was an XHTML ResponseWriter thing. It's not
> like the ResponseWriter doesn't know that nobody has output a prefix
> mapping for XHTML yet (ignoring the case where it was sent out
> through unescaped text and even then creating a new mapping isn't the
> end of the world as long as it doesn't conflict).
Right. I think this would work well for simple use cases - such as
ensuring that the root <html> element ends up with the proper xhtml
namespace.
Should we consider more complex use cases, eg:
> <f:view xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns="http://www.w3.org/1999/xhtml">
> <html>
> <h:head></h:head>
> <h:body xmlns="http://www.w3.org/2000/svg">
> <svg version="1.1" ...>
> <circle .../>
> </svg>
> </h:body>
> </h:head>
> </html>
> </f:view>
In this case, the Facelets compiler has some chance of figuring out
that the SVG namespace needs to be pushed down to the <svg> element.
By the time we get to the ResponseWriter, we have less information
available to us, and thus harder to correct arbitrary missing namespaces.
This is
where the ResponseWriter is being hosed by the lack of apis for
the namespace. In theory, the default Facelets tag handler should
always be passing a namespace to startElement. If that were the case,
the ResponseWriter would be called with:
startElement("svg", "http://www.w3.org/2000/svg") and the XML
ResponseWriter would realize that this isn't the current default
namespace and wait until the start element needs to be closed (in case a
default attribute was written manually) to add a default namespace:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
With this scheme, we would always use the default namespace in the
ResponseWriter, so if we later had to output some HTML, the
ResponseWriter would write out the appropriate default namespace again:
<input xmlns="whatever the html namespace is">
If the output was constantly switching between namespaces, this would be
less efficient than having them all at the top, but it has the nice
advantage of not requiring foreknowledge. The only real tricky thing is
what to do if the page author wants to set the default namespace
themselves because they are about to blast out a bunch of raw content.
If it wasn't for that case, the ResponseWriter could essentially own the
default namespace itself.
However, these kinds of cases only show up when the output allows
multiple namespaces, which isn't pressing for the HTML use cases yet.
-- Blake
I don't know how much we care about solving this more generic case.
The xhtml namespace issue is clearly more pressing.
> We will eventually have a bigger problem that the ResponseWriter
> interface allows no way to specify a namespace. This is lame and I'm
> not a big fan of the workaround of abusing the default namespace or
> passing the prefixes in with the element names.
Agreed.
Andy
>
> -- Blake Sullivan
>
5657
days inactive
5659
days old
jsr-314-open-mirror@lists.jboss.org
13 comments
5 participants
participants (5)
-
Andy Schwartz -
Blake Sullivan -
Cay Horstmann -
Ed Burns -
Martin Marinschek