[jsr-314-open] Execute phase of lifecycle in spec
by David Geary
In the spec, we have this:
Although the diagram in Section 13.4 “Partial View Traversal” depicts the
“execute” portion as encompassing everything
except the “Render Response Phase”, it really is the “Apply Request Values
Phase”, “Update Model Values Phase” and
“Process Validations Phase”.
I don't understand this at all. If that's the case (which means that the
execute portion of the excludes the Invoke Application phase), then why
hasn't someone updated the diagram to be correct?
Why would we show a diagram that we know is wrong? I'd also like to know if
Invoke Application is part of the execute portion of the lifecycle.
Thanks,
david
15 years, 5 months
Re: [jsr-314-open] begin success complete and rendered?
by Dan Allen
On Mon, May 25, 2009 at 3:58 AM, Ganesh <ganesh(a)j4fry.org> wrote:
> Hi,
>
> Success occurs after complete. See table 14-3:
> 'complete' occurs immediately before javax.faces.response is called.
> 'success' occurs immediately after jsf.ajax.response has completed.
> After success there is nothing more happening.
Thanks for clarifying.
More can still happen, though. An image can be drawn by the browser for
instance. But of course, the Ajax request itself is done.
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
15 years, 5 months
[jsr-314-open] begin success complete and rendered?
by David Geary
I have an Ajax request that pulls an image from a web service. I'm using
f:ajax's onevent attribute to display a progress bar when the Ajax call
begins, and make it disappear when the call is complete, but complete does
not coincide with the end of rendering, so there's sometimes a considerable
lag between when the progress bar disappears, and when the image is fully
drawn.
Is there a way to send a notification when rendering is complete, so I can
avoid the lag time?
Thanks,
david
15 years, 5 months
[jsr-314-open] Someone needs to spellcheck the spec
by David Geary
If you search for "woould" and "D eclaration" in the 05/06/09 version of the
spec, you'll find both. Someone should spell check the document--it's pretty
embarrassing to have misspelled stoff in the spec.
Also, I've mentioned this before, but all occurrences of "insure" in the
spec should be "ensure". We are not in the insurance business. :)
I realize that specs are expected to be obtuse, but our spec should be
reviewed by a competent technical writer--there's still a lot of cruft in
there.
david
15 years, 5 months
[jsr-314-open] No pdldocs for f:ajax?
by David Geary
Am I missing something, or is the documentation for <f:ajax> missing from
the pdldocs in from the latest spec folder (03/04/09)?
Thanks,
david
15 years, 5 months
[jsr-314-open] Facelets: XHTML vs. XML
by Andy Schwartz
Gang -
I have been think about the Dan's blog entry on Facelets pages as valid
XML documents:
http://blog.hibernate.org/10752.lace
Actually, I have been struggling with related issues. Wanted to ping
the EG to see whether we can start some discussion on this topic.
In Dan's case, XML (plus XSD) provides a way to improve the page
authoring experience. In my case, I am interested in XML as a way to
support content-type independence for contents rendered by Faces
components. That is, it should be possible to use Facelets as an XML
document that describes how to build the component tree and leave the
decision of whether to render XHTML content or HTML content (or some
other type of content) up to the render kit. While Facelets is fairly
close to meeting this requirement, there are a couple of minor
assumptions built into the Facelets implementations (both Facelets 1.x
and JSF 2.0) that complicate matters.
The complications arise from how Facelets treats XML-specific constructs
such as:
- The XML declaration
- XML processing instructions
- CDATA sections
Currently these constructs are doing double-duty:
1. They are consumed by the Facelets XML parser.
2. They are passed through to the browser.
I suppose that #2 makes sense if you view the Facelets page as an XHTML
document to which some pre-processing is applied before handing off to
the client. However, this subverts the ability to support non-XML/XHTML
content generation, such as HTML content generation.
A simple example that demonstrates where we run into trouble... In ADF
Faces applications, the root component (under the view root) is
typically an af:document component. af:document takes care of rendering
the document "chrome", including the doctype and the html/head/body
elements. A minimal ADF Faces page might look something like this:
<?xml version='1.0' encoding='utf-8'?>
<f:view xmlns:f="http://java.sun.com/jsf/core"
xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
<af:document/>
</f:view>
This creates a trivial component tree: a UIViewRoot containing an ADF
Faces RichDocument component. It should be possible to render this
component tree as either an XHTML or an HTML document. The Renderer for
the RichDocument component could easily handle both of these cases.
However, there is a stumbling block... With Facelets, the XML
declaration ends up being passed through to the browser, regardless of
what type of content the RenderKit happens to generate. The end result:
when rendering the document to HTML, we end up with a bogus XML
declaration in our generated HTML content.
In the above example, the purpose of including the XML declaration in
the Facelets page is to ensure that the Facelets page is a valid XML
document (#1 above), not for the purpose of including this in the
generated content (#2 above), yet we end up with both.
We run into similar problems with CDATA sections. For example, the
following code uses the Trinidad trh:script component to insert a script
into the page:
<trh:script>
<![CDATA[
if (0 < 1) alert("Woohoo! Zero *is* less than one!");
]]>
</trh:script>
As with the previous example, the XML-specific construct (a CDATA
section in this example) is meant to apply to the Facelets page itself -
not to the generated content. That is, the CDATA section provides a way
to tell the Facelets parser not to parse the specified character data.
This is not intended to be used as an instruction to the browser (just
to Facelets XML parser). However, Facelets passes the CDATA through to
the browser. As a result, in the case where we render HTML content, we
end up with bogus CDATA sections inside of our generated HTML document,
which causes the browsers to get confused.
In order to support content independence (or, more particularly, to
support HTML rendering), the render kit needs to be able to make
decisions such as whether script contents need to be wrapped in CDATA
sections (when generating XHTML content yes, HTML content no) or whether
an XML declaration is necessary in the generated content (same deal).
Note that this sort of content-type independence is already possible
using JSP documents (ie. XML-based JSP pages), since JSP engines
interpret the XML constructs as instructions for the JSP's XML parser.
There is no assumption that the generated output will be XML/XHTML. We
would like to see Facelets support similar behavior.
Of course, every Facelets page that currently exists relies on the
current XHTML-centric behavior, so there is no chance that we can change
this default behavior. However, I would like to see some mechanism for
opting in to a more XML-centric processing model. I suppose that this
could be left up to the JSF implementations to provide, though it seems
like this might be a reasonable candidate for a spec-level solution.
Thoughts?
Andy
15 years, 5 months
[jsr-314-open] h:outputScript doesn't work inside composite components
by David Geary
I have a login composite component that looks like this:
<composite:interface>...</composite:interface>
..
<composite:implementation>
<script type="text/javascript">
function checkForm(form) {
var name = form['#{cc.clientId}:name'].value;
var pwd = form['#{cc.clientId}:password'].value;
if (name == "" || pwd == "") {
alert("Please enter name and password.");
return false;
}
return true;
}
</script>
...
</composite:implementation>
I have components with "name" and "password" component ids in a form in the
.. part of the implementation. That works fine.
However, if I pull the JS out into its own file, and do this:
<composite:interface>...</composite:interface>
..
<composite:implementation>
<h:outputScript library="components/login" name="login.js"/>
...
</composite:implementation>
h:outputScript puts the JS in the page, but the JS no longer works because
the expression cc.clientId evaluates to an empty string.
That's a bug, is it not?
david
15 years, 5 months
[jsr-314-open] access to ViewMetadata facet
by Dan Allen
As a refresher, we have introduced a special facet in JSF 2 called the
metadata facet. This facet is built during an initial request, prior to when
the remainder of the view is created and built. So far the only officially
recognized child components are UIViewParameters, which map HTTP request
parameters onto model values and export these values back to bookmarkable
and redirect URLs.
My expectation is that frameworks creators are going to want to make use of
the metadata facet to host other components oriented towards the initial
request. For instance, in Seam we want to prototype view actions for JSF 2.1
and also define security restrictions on the page. Currently, however, the
ViewMetadata only offers a single method for access the contents of the
metadata facet:
Collection<UIViewParameter> ViewMetadata#getViewParameters(UIViewRoot)
This method simply advances to the metadata facet and iterates its children
looking for UIViewParameter components.
I'm concerned that the ViewMetadata does not offer a convenience method for
accessing general contents of the metadata facet. I have two proposed
methods, one of which I think we definitely need to provide.
Collection<UIComponent> ViewMetadata#getChildComponents(UIViewRoot)
Collection<UIComponent> ViewMetadata#getChildComponents(UIViewRoot, Class<?
extends UIComponent>[]);
Feel free to suggest alternate signatures. As it is now, I can see everyone
wanting to extend this feature as needing to provide a utility method to
extract the contents.
I also think the term "view parameter" should be removed from the JavaDoc
"ViewMetadata is reponsible for extracting and providing view
parametermetadata from VDL views" to make it clear that any metadata
can be
supported. Perhaps just cite that the only recognized metadata are view
parameters.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
15 years, 6 months
[jsr-314-open] JSF fu, Part II, Reviewers wanted
by David Geary
I'm finishing the 2nd article in my series at devworks covering JSF2. This
article covers Facelets templating and composite components.
If anyone from the EG would like to review the article before I hand it over
for publication (I'll need comments by May 18), I'd be happy to send you the
article, as long as you promise to keep it under wraps. Please respond to me
directly if you're interested.
Thanks,
david
15 years, 6 months
