Hahaha. That probably should have been bold face rather than uppercase. Didn't mean to sound like I was yelling, just didn't want that important point to be missed ;) -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

Hi guys, Right, but that's the leaky abstraction. We've more or less standardized (it I agree with the notion of having a .xml extension for Facelets pages, and also with not passing the meta-data to the output. I think the performance hit is minimal, and it definitely brings us one step up the abstraction ladder. However, I want this to be optional - you should be allowed to be both. While Jacob did say on his blog not to mix the two things, he still had this jsfc-feature in Facelets, cause some people don´t want/need to abstract away from XHTML. And I believe we should keep it like this for the small and simple project (cause if we face it, passing the metadata with a new set of components is additional complexity which we don´t need for the simple case). regards, Martin

<?xml version="1.0" encoding="UTF-8"?> <ui:composition xmlns:ui="jsf:facelets" xmlns:cc="jsf:cc"> <cc:interface> <cc:attribute name="name" required="true"/> </cc:interface> <cc:implementation> Hello, #{cc.attr.name} </cc:implementation> </ui:composition> The point being, no need for all the HTML wrapper garbage. I'd even like to get rid of the ui:composition there and perhaps have something like "cc:component" or "cc:tag" as the wrapper. We can also leverage the default namespace to cut out the unnecessary namespace prefixes: <?xml version="1.0" encoding="UTF-8"?> <component xmlns="jsf:cc"> <interface> <attribute name="name" required="true"/> </interface> <implementation> Hello, #{cc.attr.name} </implementation> </component> Notice that I'm not really changing all that much in JSF to get to this point. It's really just a shift in thinking (and recommending). -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

On Sun, Dec 13, 2009 at 11:28 AM, David Geary <clarity.training(a)gmail.com&gt;wrote: Yeah! One thing to keep in mind with the default namespace is that if you want to use HTML, you would have to prefix it in the case above (which might be strange to some people): <?xml version="1.0" encoding="UTF-8"?> <component xmlns="jsf:cc" xmlns:html="http://www.w3.org/1999/xhtml"> <interface> <attribute name="name" required="true"/> </interface> <implementation> Hello, <html:strong>#{cc.attr.name}</html:strong> </implementation> </component> -Dan p.s. Isn't it strange every time you see 1999/xhtml? ;) -- 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

On 12/13/09 11:16 AM, Dan Allen wrote: Hmm. Yuck. :) I don't mind using cc:foo. I already have to prefix any JSF components I use, so I don't mind using prefixes in general. I would, however, really hate life if I had to html:prefix html:every html:last html:html html:widget (you get the point :) in the component. I guess this being XML, you can choose the default namespace you want, but I'm not sure *I* see much in that to get excited about. :) -- Jason Lee, SCJP President, Oklahoma City Java Users Group Senior Java Developer, Sun Microsystems http://blogs.steeplesoft.com

I think he might have just been too lazy (or bored) to rip it out. The pass-through is a different argument from jsfc. I think jsfc is completely and utterly useless. I see no value in it. I do see the value in the pass-through for quick stuff. But even then, all that is being passed through is the xml and doctype declaration, and the CDATA, all which happen to be causing us issues with IE. (Remember, I'm not objecting to passing raw HTML tags straight through, that is why Facelets is so successful. I'm talking more about the document wrappers). -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

2009/12/13 Martin Marinschek <mmarinschek(a)apache.org&gt; Right. And it's not just sophisticated components. Once you start using templates, compositions, and decorators--which any non-trivial JSF 2 project should use for extensibility, flexibility, and maintainability--you leave graphic designers out in the cold, and jsfc becomes worthless. I've taught Facelets for years, and when I show the jsfc feature, people initially think it's really cool. But then, inevitably, the questions come about what to do if you want a data table, or if you want to use compositions. Then it becomes apparent that jsfc is only useful for simple demos. Okay, I buy the backward compatibility argument because we should be backward compatible with open-source Facelets, but I think in practice continuing to support jsfc (or getting rid of it) will have no meaningful consequences at all. btw, am I missing something, or is jsfc nowhere to be found in the spec or the javadocs? I just did a search in the spec and came up empty, and I don't recall any mention of it at all in the PDL docs. If it's nowhere to be found, either in the spec or PDL docs, IMO, it's not officially part of JSF 2 anyway, but I digress. david

Gang - I finally managed to read through this email thread. Thanks Dan for getting this discussion going (again)! As I mentioned in our original thread back in May, I am very interested in this problem as well. I am happy with where this thread ended up - ie. I very much want to see an XML-centric approach, but I agree with Martin that we should continue to support the XHTML-centric approach as well. Dan has already mentioned one way to accomplish this: This approach would be perfect for my use case. One of the reasons why I am interested in pushing this XML view of the world is because I am already using a technology that supports this: JSP documents - ie. XML-based JSP pages. (Funny, yes, there is something about JSP that I actually like more than Facelets!) In our case we have a tremendous amount of XML-based JSF content sitting around in .jspx files. (We also use the extension .jsff for "JSF fragments" - ie. files that specify component subtrees rather than complete pages.) For the most part we can simply run these files via the Facelets engine. (Yet another reason why I love Facelets.) In JSP document land, XML instructions (the XML declaration, CDATA sections) are treated as instructions to the JSP engine itself. This means that I can have the following .jspx file: <?xml version='1.0' encoding='utf-8'?> <f:view> <tr:document> <trh:script> <![CDATA[ if (0 < 1) alert("w00t!"); ]]> </trh:script> </tr:document> </f:view> And not have to worry about the XML declaration or CDATA section wrapper being sent to the browser. Instead, my render kit can decide to render an XML declaration or not (depending on whether we are generating XHTML or HTML), and the trh:script renderer can decide how to deal with its body. (The HTML <script> element is implicitly CDATA, so the script content can be passed directly through.) As we've been discussing, Facelets will pass this XML-specific content directly on to the browser, which is invalid in the case where we are rendering traditional HTML. We have had to take steps to address this internally - ie. we have a patched version of Facelets 1.x that allows XML instruction handling to be controlled via a context parameter, similar to "facelets.SKIP_COMMENTS". However, this is gross - we really need a solution that is sanctioned by the spec and provided by the JSF implementations. Thus, a solution where the XML processing behavior is triggered by the file extension (ie. .xhtml preserves old behavior, new behavior elsewhere) would be a huge step forward for us. The changes that we ended up making to Facelets 1.x to support this (well, something like this - a context parameter approach) were trivial. If we can reach consensus on this solution (or something like it), I would be happy to provide a patch that implements this behavior. FWIW, this issue is currently an obstacle to wider adoption of Facelets within Oracle, so I am very interested in seeing whether we can get some solution in place soon (ie. before 2.1). I would of course prefer a spec'ed solution, but could live with an implementation-specific solution if that is our only option in the short term. Regarding: In Trinidad/ADF Faces we've combined these into a single "document" tag and let the RenderKit pick the doctype so that our page authors don't need to worry about this. If we expose an f:cdata component, we'll need to understand what this means for HTML-based render kits. Andy Dan Allen wrote: > 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 <http://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 > (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&... > <http://archives.java.sun.com/cgi-bin/wa?A2=ind0905&L=jsr-314-open&... > > -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