Re: [jsr-314-open] [jsf2.next] <h:head> vs. <head>
by Lincoln Baxter, III
I'd even like to see it add <head> if not provided. Would that be too
overreaching?
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Dec 15, 2009 1:02 PM, "David Geary" <clarity.training(a)gmail.com> wrote:
2009/12/15 Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
> > It would be nice if it "just worked", and jsf would automatically
add/detect he right place to l...
+1. I always pitch h:head and h:body as necessary to coordinate with
resource relocation from h:outputScript and h:outputStylesheet, but it would
be great if you could just use <head> and <body> instead, and have
everything work.
david
> > Lincoln Baxter III > http://ocpsoft.com > http://scrumshark.com > Keep
it simple. >> >> On Dec 1...
15 years
[jsr-314-open] [ADMIN] Sun Certified JSF Developer Exam Questions (was:Re: Where's Ed Burns this week?)
by Ed Burns
>>>>> On Tue, 15 Dec 2009 17:47:27 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> Ed,
DA> Thanks for the update and good luck!
DA> I encourage all of you on this list to submit at least one question, if you
DA> have time available. The rigorousness and accuracy of the JSF certification
DA> exam reflects on the quality of the JSF specification.
DA> Is there a cut off date, Ed? (I can't see from the post because java.net is
DA> currently down).
We're trying to have the bulk of the questions in this week but I'm
quite certain that the merging of the Oracle and Sun certification
organizations (should the merger happen) will delay things. In general,
however, it's best not to rely on such speculation.
Rather than waiting for java.net to come back, you can just followup to
this mail. Thanks for the exhortation Dan!
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years
[jsr-314-open] [JSF 2.1 NEW] behavior simplification
by David Geary
I think the behavior API is a great start, but my head hurt when Andy was
explaining it at JSF Summit (no reflection on you, Andy! :)). For 2.1, I
would like to see a simplification along the lines of the simplifications we
made to component development for JSF 2.0 with composite components.
Ideally, it would be great if we could just implement, for example, a JS
file (like we now just implement XHTML for composite components), and have
that transform into a behavior, complete with tag, that page authors can
attach to components, again, similar to the way we transform XHTML files
with composite component implementations into component tags.
Also, I noticed that Jim Driscoll's post about implementing custom behaviors
seems to have copied a good deal of code right out of the RI. Could we make
that code accessible to developers so they don't have to reinvent?
Thanks,
david
15 years
Re: [jsr-314-open] [jsf2.next] Proposal to support newsemantic HTML5tags
by Ed Burns
>>>>> On Mon, 14 Dec 2009 13:48:18 -0500, Simon Lessard <Simon_Lessard(a)dmr.ca> said:
SL> We might have agree to disagree, the "name of the tag created" does
SL> make the whole difference imho, it's not just about how it look.
Though I'm delighted to see all the traffic on this topic, I have to
weigh in and oppose adding many more tags. The design focus of JSF
views has always been to mix template text and components. In my
opinion, this is widely seen as a strength for server-side UI
technologies such as JSF.
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years
Re: [jsr-314-open] JSF2 bashing on TSS
by Ed Burns
>>>>> On Tue, 15 Dec 2009 17:42:30 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> You really have to put on your battle armor when you enter TSS, but this is
DA> where a lot of the FUD about JSF 2 and Java EE originates.
Funny, I just saw _Net Kelly_ last night.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years
[jsr-314-open] [jsf2next] might as well face it, Facelets is XML
by Dan Allen
On the panel at JSF Summit, when I said that my JSF hot button is view
metadata, I was wrong. The most important issue to me is seeing Facelets
reach maturity as an XML-based template language that produces components,
not XHTML.
What Jacob did for JSF by introducing Facelets was nothing short of
miraculous. I personally believe that he saved JSF so that it was able to
survive until JSF 2.0 ;) But he did fall slightly short of making Facelets
perfect. The main problem is that he sat in limbo between an XHTML-based
template document that could cloak itself as a component tree and an
XML-based template language that could produce a component tree and, in
turn, response markup. We need to shift this final puzzle piece into place.
I'm going to go out on a limb here and say that Jacob choose XHTML for two
reasons:
1) He could throw a SAX parser at it and produce a component tree (putting
an end to the debacle that was JSP markup)
2) It would put an end to the debacle that was the <f:verbatim> tag for
rendering plain HTML, which was 80% of the page 80% of time.
He saved us. (Too bad he wasn't there to receive the endless praise at JSF
Summit. That's what you get for going into management. People praise your
ghost.)
However, he did one major disservice for JSF (No, Dan! How could you
criticize the King?) That's right, I said it. Somebody had to say it. It had
to be said. He violated the objective of JSF to support multiple renderkits.
We are more linked to HTML today than we have ever been before. Why do I say
that? Our view templates end in .xhtml, that's why. Okay, but .xhtml is
extensible, right? Wrong. XHTML is not an extensible language (despite it's
name). It is based on a closed doctype, which we learned at Rich Web (the
sibling conference to JSF Summit) is now dead. So we are never going to see
that extensibility.
So we are using a document with an XHTML doctype, and XML declaration, XML
namespaces (which XHTML does not support), yet no XML schema to back it. We
are in serious limbo. Do you realize how strange it is to use .xhtml to
produce an ATOM feed? And we wonder why the tools are having trouble
supporting this (okay, NetBeans figured it out, but still).
But, wait! XHMTL is useful because we can preview the template in a browser,
right? That's what the jsfc attribute is all about. We can make an input
component look like an HTML input.
<input jsfc="h:input" id="name" value="#{user.name}"/>
Guess what? Jacob backed away from this almost as soon as he added it to
Facelets. It's a leaky abstraction and simply doesn't scale. It has no
practical application. In his words:
"It's just dumb to use 'jsfc' and 'jwcid'. Those two things would be great
> if the semantics were the same between html and components, but they aren't.
> And even if they do parallel, the next concern is that there should be dummy
> content
> for the designer to play with, you have to remove it. I say don't even
> bother with it in the first place and stop expressing concerns within the
> same document."
>
http://hookom.blogspot.com/2005/09/more-on-programmer-pages.html
As it turns out, I didn't even start this call to action. It was Jacob after
all!
So how to we move forward? We have to accept these truths (well, some are
recommendations):
1) A Facelets document is XML, plain and simple
2) The extension for a Facelets document becomes .view.xml (DOT view DOT
xml)
2) A Facelets document produces a component tree; verbatim content can still
be wrapped automatically as UIInstruction fragments, that does work
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)
The markup declarations in the template DO NOT PASS THROUGH!
4) We can now use XSD to describe component library tags!!!! XSD is so
unbelievably powerful, let's use it!
<?xml version="1.0" encoding="UTF-8"?>
<f:view xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/jsf/facelets facelets-ui-2.1.xsd
http://java.sun.com/jsf/core jsf-core-2.1.xsd">
</f:view>
Of course, you only need the XSD stuff if you are looking for tooling
support. It is optional!
Let's answer Jacob's call to action and stop expressiong concerns within the
same document.
Issues:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=697
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=489
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=490
Blog entry:
http://blog.hibernate.org/10752.lace
Previous thread:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0905&L=jsr-314-open&F=&S=&X...
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
15 years
