Java Server Faces Public Review Draft 2 Available

Discussions

News: Java Server Faces Public Review Draft 2 Available

  1. The 2nd pulic draft of Java Server Faces has been published for review. JSF is a web application framework that reduces the amount of code needed to write a web front end. Developers need only write JSF components and corresponding event handling code, the framework then simplifies the tasks of validation, request parameter parsing, state management, multipe clients support, etc.

    Check out the review draft as well as the JSR 127: Java Server Faces.

    Sun also recently posted a JSF tutorial on java.sun.com:
    http://developer.java.sun.com/developer/technicalArticles/GUI/JavaServerFaces/

    Threaded Messages (52)

  2. Hi,

      I applaud Sun's effort to squeeze out more of classic HTML browsers (that were never intended for rich UIs (a.k.a classic desktop apps)).

      Using "standardized" XML tags for rich widgets on the server-side that magically dish out Javascript hairballs and other kludges you better don't look at is no long-term solution.

      Let's face it. The HTML browser is broken. What the world neeeds is a new markup for rich widget sets. Let's all welcome XUL (XML UI Language) and let's create a rich internet for everyone.

      Find out more at about XUL at the Open XUL Alliance site @ http://xul.sourceforge.net

      - Gerald
  3. Gerald,
    I think that both web application and thin clients, in general, are suitable solutions. The criteria of where we use one over the other is what requires some thought and formalization. In the last few years we have definitely seen more web applications. However, in many cases thin Swing Apps communicating to the server via webservices would be providing user interaction model that is more suitable. For the last app I wrote we made decision to go with thin swing client and I would say that every one including the users are very content with the choice. The app has rich user interaction model, so I guess the richness of the user interaction model is one of the criterias that play at choosing the architecture. There are many others criterias too, that allow to define suitability of a particular approach.

    Cheers!
    MVC: building new controller
    http://www.freeroller.net/page/alexkrut

    P.S. I would guess that you used browser to make your post.
  4. And browser side....[ Go to top ]

    JSF JCP appears klugy (but read the JCP doc on JSF for your opinion)

    XUL is also rummored to be a part of next version of IE and new Mozilla (used by AOL) browser is writen in XUL:
    www.mozilla.org/projects/firebird/release-notes.html

    I also monitor XHTML / XFORMS rendered on browser:
    www.nforms.net and www.novell.com/xforms

    Once XUL or XFORMS has more track record in production I will re-evaulate, but

    I recommened this to baseBeans.com clients now:
    http://blueprints.macromedia.com/PetMarket/flashstore.html
    I added XML output to JavaBeans(Struts formBeans), and now clients place field components on "stage", they have tree, calendar, grid components, even back button works great now and no cross browser issues for us, plus no run time fees, I have no idea what JSF run time fees are - for a kluge)
    You can see more of this aproach at Sean Neveilles presentation that he is giving for TheServerSide Conference coming up. (or I am giving an online via web at Struts best practices online seminar, register at... you know)


    .V
  5. XML-based UI languages != XUL[ Go to top ]

    XUL is also rummored to be a part of next version of IE and new Mozilla (used by AOL) browser is writen in XUL:

    > www.mozilla.org/projects/firebird/release-notes.html

    If it happens in MS products I doubt it will be XUL at all; rather I suspect Microsoft will invent their own XML-based UI language. XUL has it's own elements, namespace, etc. and is drafted at <http://www.mozilla.org/projects/xul/>; if it uses a different namespace then it simply ain't XUL.

    (I'm a trifle concerned that some people are trying to lump /all/ XML-based UI languages under the "XUL" heading. After all, it'd be pretty ludicrous to say all markup languages with hypertext support (e.g. DocBook) are HTML, now wouldn't it? ;o)
  6. XUL (XML UI Language)[ Go to top ]

    I'm a trifle concerned that some people are trying to lump /all/ XML-based UI

    > languages under the "XUL" heading. After all, it'd be pretty ludicrous to say
    > all markup languages with hypertext support (e.g. DocBook) are HTML, now
    > wouldn't it?

     Please, don't restart the XUL naming debate. If anyone is interesting in hairsplitting over an acronym, please check out the last flame war in the xul-talk mailinglist.

    > If it happens in MS products I doubt it will be XUL at all; rather I suspect
    > Microsoft will invent their own XML-based UI language.

      Call it XAML, X# or whatever. It's the same idea. For more about Microsoft XAML (XML Application Markup Language) upcoming in Longhorn Beta this fall check out the XUL News Wire story.
  7. XML-based UI languages != XUL[ Go to top ]

     Please, don't restart the XUL naming debate. If anyone is interesting in hairsplitting over an acronym, please check out the last flame war in the xul-talk mailinglist.


    I don't think I'm hairsplitting; I'm worried that people will be mislead into thinking something's XUL-based when it's nothing like XUL and probably incompatible. N.B. your mailing list hyperlink 404's.

    >   Call it XAML, X# or whatever. It's the same idea. For more about Microsoft XAML (XML Application Markup Language) upcoming in Longhorn Beta this fall check out the XUL News Wire story.

    For what it's worth, XAML is also the name of a markup language being developed for online transactions.
  8. XUL (XML UI Language)[ Go to top ]

     Please, don't restart the XUL naming debate. If anyone is interesting in hairsplitting over an acronym, please check out the last flame war in the xul-talk mailinglist.

     
    > N.B. your mailing list hyperlink 404's.

      That was just a temporarily sourceforge outage. It's up and running again.
  9. Man.. you can use JSF to generate XUL as well.

    I just wonder if you have ever written an app that is written in a XML UI markup language - and by that I mean, any of them and not XUL created by mozilla. All your posts seem to imply that by using XUL you don't need to write any javascript or CSS.
  10. Bauer and his silver bullet again...


    Please, no personal insults. It will backfire.

    > I just wonder if you have ever written an app that is written in a XML UI
    > markup language - and by that I mean, any of them and not XUL created by
    > mozilla.

      The XUL Alliance site lists many XUL motors including Luxor. Yes, I have. Check out Venus Application Publisher (Vamp).

    > All your posts seem to imply that by using XUL you don't need to write any
    > javascript or CSS.

      I guess you didn't get it. XUL needs CSS. However, XUL reduces the need for scripting because widgets are first-class citizens. You don't need to send Javascript hairballs or bitmaps or whatever over the wire. Just a simple <tree>, <datagrid>, <button>, <wizard> or whatever tag is enough.

      To catch up on the XUL discussion, why not reread The Server Side XUL discussion thread from last week

      - Gerald
  11. Remove the yellow color first as everyone gets dizzy when looking to that page. How can one put such a color on a site ?

    I totally agree on the browsers thing. I wonder how much time must pass until enough people realize that users want reach and consistent online experiences even on top of those fancy huge clustered super engineered J2EE applications. And how much even more will pass until the Internet tech community will do something about this.

    Cheers.
  12. Gold, Gold, Gold[ Go to top ]

    Remove the yellow color first as everyone gets dizzy when looking to that page.


    Thanks for your comment. I will look into the matter as you're the third person to complain now.

    > How can one put such a color on a site ?

      The gold (=yellow) goes with the rich client, rich browser, rich portal theme. I'm not sure if I use gray for say platinum it will have the same impact.

     - Gerald
  13. The new JSF draft is news, but it's not as big news today as the first publication of Undercover Reports - these reveal the results of EJB management tests on WebSphere, WebLogic, Oracle 9iaS, JBoss, and the RI. Check out:

    http://www.scottcrawford.com/undercover
  14. Has anybody compared JavaServer Faces to Microsoft's WebForms?
  15. Sean,

    There's a lot of similarities and differences between JSF and ASP.NET WebForms, but the overall goal is the same -- provide a framework for stateful user interface components whose events can be handled on the server-side. I'm more of an expert on JSF than WebForms -- I've only developed one ASP.NET application, and I've been writing Java web applications since the pre-servlet days, so take my comments with a grain of salt. I think the primary differences are: (a) the RenderKit concept -- JSF optionally supports separate classes that handle encoding and decoding, which can blur the line between renderers and components; as far as I know, there is no WebForms equivalent - the components always handle both encoding and decoding, and (b) JSF more strictly enforces MVC-style applications -- application logic classes don't have much to do with the view, although they can interact with it if they must; WebForms more closely resembles the VB or Delphi-style Forms-based approach -- each page is a separate class whose instance variables are the controls (Fowler calls this the Page Controller pattern).

    There are some other differences, as well, but I can't remember them off-hand :-).

    Personally, I think JSF has more depth to it under the hood, but WebForms is more accessable to client/server, or VB and Delphi-style programming.


    Kito D. Mann
    kmann at virtua dot com
    Author, JSF in Action for Manning Publications (currently in progress)
  16. Does anyone know if JSF will come with the breath of components that WebForms does? I'm sure that someone will create an equivalent of ColdTags (http://www.servletsuite.com/jsp.htm) for JSF, but if a comprehensive library of components isn't part of the main standard, JSF won't be anywhere near as successful or useful as it could be. When C++ originally added templates, they didn't add any template libraries to the standard. Several inhouse, 3rd party, and open source template libraries were created but C++ templates didn't become popular and capture the imagination of C++ programmers until the STL was added to the standard.
  17. Does anyone know if JSF will come with the breath of components that WebForms does?

    This question has been asked so many times :-(

    >I'm sure that someone will create an equivalent of
    >ColdTags (www.servletsuite.com/jsp.htm) for JSF,

    Sure, we at Coldbeans will do that

    But, it would be good to see that it (JSF) is alive and there is some demand for such things. It is not obvious. JSF is nothing without IDE. Who from IDE vendors and when will support it?

    Dmitry Namiot
    Coldbeans
  18. <!--Personally, I think JSF has more depth to it under the hood, but WebForms is more accessable to client/server, or VB and Delphi-style programming.-->

    I am no expert of JSF and may be you can give me some valid arguments about your assessment. But here is one big advantage of Webforms that is hard to beat, if JSF does so, please let me know.

    When you think it from development point of view, writing cryptic html/xml files is a nightmare from both development and maintenance point of view. WebForms (that are built on top of ASP.NET framework) separation of presentation tier and its implementation as a code behind file is unmatchable in JSF world. You can literally develop the whole website in any of .NET languages without writing a single line of html code.

    Isn't it exciting?

    I don't want to over emphasize this point since it may start a war here, but please don't hesitate to learn from ASP.NET becuase honestly it is a better and richer framework than Java presentation tier (JSP,Servlet, JSF). BTW you know why ASP.NET is better becuase they learned and get some good lesson from Java...
  19. <snip>

    > When you think it from development point of view, writing cryptic html/xml files is a nightmare from both development and maintenance point of view.
    >

    Ehhh, not if you're a html/xml guy? Btw - what's so cryptic about html? It's simple static text?

    > WebForms (that are built on top of ASP.NET framework) separation of presentation tier and its implementation as a code behind file is unmatchable in JSF world. You can literally develop the whole website in any of .NET languages without writing a single line of html code.
    >

    Ever heard of MVC? By the way - is it really true that you can't do mvc with .NET webforms? The closest I've seen is an obscure article which argues "the view and the controller are the same anyway" bull*

    With this I mean: let server guys do all model and controller aspects and have some funky "html architect" do the xhtml/xml whatever cool tech is available.

    All they need to know is that <input_text, tada, is a classic input text and they'll do just fine.

    > Isn't it exciting?

    No, actually not - been there, done that.
     
    > I don't want to over emphasize this point since it may start a war here, but please don't hesitate to learn from ASP.NET becuase honestly it is a better and richer framework than Java presentation tier (JSP,Servlet, JSF). BTW you know why ASP.NET is better becuase they learned and get some good lesson from Java...
    >

    Quite strange as I, and probably a lot others, consider WebForms to be a big step backwards? It sure looks nice on the surface (pws users will love it - but hey - they love VB also ;) - but I wouldn't want to actually *use* it in any major project...
  20. <!-- Ehhh, not if you're a html/xml guy? Btw - what's so cryptic about html? It's simple static text? -->

    May be not, so does writing the programs using machine language. I guess after all it's a matter of preference:-)

    <!--Ever heard of MVC?-->

    Over heard it:-) BTW there is a thing called Model, view, Controller, and then common sense. So juts stick with the view part for a minute and don't bring MC part into the discussion. You know why, again common sense, because we are comparing presentation tier in this thread. Besides that WebForms/ASP.NET doesn't stop you to adopt MVC pattern if you want.

    If you think writing cryptic html/xml is totally acceptable and productive at the presentation tier, I don't want to argue any more, like I said before, may be it's the matter of preference. As far as it comes to my personal opinion, I have to admit; again MS proved that they are much better than the rest of us when it comes to presentation tier.
  21. Rashid,

    I think you're missing a big point: JSF doesn't require you to write "cryptic html/xml" files any more than WebForms does. The IDE integration for JSF is quite like the IDE integration for WebForms -- you have a forms designer view (where you drag and drop components). What you do on that view manipulates a file (.aspx in WebForms and .jsp, .xul, or some other technology with JSF). That file may contain XML and HTML tags (which is absolutely true of WebForms).

    If you don't use the IDE, you have to edit the file manually without the pretty GUI tools (this is true of both WebForms and JSF). This code, however, related only to the presentation (with JSF and JSP, it's just custom tags in a JSP). Your code is complete separate. The default model in the WebForms world is to have a single class that handles postbacks for a each page, while JSF enforces a more MVC-style approach where separate classes handle the application logic (it's not tied to closely to the page itself).


    > <!--Personally, I think JSF has more depth to it under the hood, but WebForms is more accessable to client/server, or VB and Delphi-style programming.-->
    >
    > I am no expert of JSF and may be you can give me some valid arguments about your assessment. But here is one big advantage of Webforms that is hard to beat, if JSF does so, please let me know.
    >
    > When you think it from development point of view, writing cryptic html/xml files is a nightmare from both development and maintenance point of view. WebForms (that are built on top of ASP.NET framework) separation of presentation tier and its implementation as a code behind file is unmatchable in JSF world. You can literally develop the whole website in any of .NET languages without writing a single line of html code.
    .

    Kito D. Mann
    kmann at virtua dot com
    Author, JSF in Action (in progress)
  22. <!--I think you're missing a big point-->
     
    May be I did, or may be not. I totally understand your argument that both framework could be attached to an IDE that renders the design time view without the html coding, other wise you have to code your server side controls using plain html forms tag. May be JSF opt for custom tag libraries to access these controls programitically (let me correct otherwise) while in ASP.NET world they are accessible in the code behind files. I will come back to this point later.

    Before proceeding further, I would like to ask a question about the JSF controls and it's lifecycle. Does JSF controls is cachable and keep their state during the postbacks? Or you have to write your own framework to cache these controls.
  23. Rashid, AFAIK There is no concept of postback in JSF as it is in ASP.Net. You can define Navigation rules for the application in app config file and that will be loaded during the startup of the application. You do not have to do Server.Transfer or Response.redirect for navigating. But the advantage of JSF is your navigation rules can be changed dynamically without recompiling the code. But in JSF if there are any validation errors then original page is rendered with error messages.
    I do not understand what Kito says when he writes "The default model in the WebForms world is to have a single class that handles postbacks for a each page, while JSF enforces a more MVC-style approach where separate classes handle the application logic (it's not tied to closely to the page itself).
    "
    In ASP.Net you certainly can delegate application logic to different classes if you want, the only thing that is tied to page class is the events that are raised by the controls on that page(For example button_click) and it is NOT one class for all the pages, it is different page class for different page. It certainly is windows style programming where controls are children of that form and so are controls in webforms which are children of that page.
  24. Balaji,

    Just to clarify, I was basically just saying that a page in ASP.NET posts back to itself (i.e. postback). So there's one class per page. That's all.

    I know you _can_ delegate to application logic in a separate class (or set of classes), and I've done that myself. You would do the same in JSF -- putting business logic in Action classes or ActionListeners would be a bad idea. It's just that JSF doesn't have a single class per page -- that's all.

    > Rashid, AFAIK There is no concept of postback in JSF as it is in ASP.Net. You can define Navigation rules for the application in app config file and that will be loaded during the startup of the application. You do not have to do Server.Transfer or Response.redirect for navigating. But the advantage of JSF is your navigation rules can be changed dynamically without recompiling the code. But in JSF if there are any validation errors then original page is rendered with error messages.
    > I do not understand what Kito says when he writes "The default model in the WebForms world is to have a single class that handles postbacks for a each page, while JSF enforces a more MVC-style approach where separate classes handle the application logic (it's not tied to closely to the page itself).
    > "
    > In ASP.Net you certainly can delegate application logic to different classes if you want, the only thing that is tied to page class is the events that are raised by the controls on that page(For example button_click) and it is NOT one class for all the pages, it is different page class for different page. It certainly is windows style programming where controls are children of that form and so are controls in webforms which are children of that page.

    Kito D. Mann
    Author, JSF in Action (in progress)
    JSF FAQ: http://www.jsfcentral.com
  25. Microsoft WebForms[ Go to top ]

    Microsoft .NET web forms (WebForms)
    http://msdn.microsoft.com/msdnmag/issues/01/05/WebForms/default.aspx

    Microsoft writes:

    "[...] programming model built around server-side controls - a model in
    which controls render their own UIs by generating HTML to return to clients
    and firing events that are handled by server-side scripts. Since all the
    action takes place on the Web server, virtually any browser can run a Web
    Forms app"

    For Java-based web apps, Java Server Faces

    http://jcp.org/en/jsr/detail?id=127

    http://java.sun.com/j2ee/javaserverfaces/index.html

    Sun writes:

    "JavaServer Faces technology simplifies building user interfaces for
    JavaServer applications. With the well-defined programming model that
    JavaServer Faces provides, developers of various skill levels can quickly
    and easily build web applications by: assembling reusable UI components in a
    page, connecting these components to an application data source, and wiring
    client-generated events to server-side event handlers. With the power of
    JavaServer Faces technology, these web applications handle all of the
    complexity of managing the user interface on the server, allowing the
    application developer to focus on application code."
  26. 1. JSF is still in draft and Microsoft WebForm is already available :)
    2. JSF still need more time to get implemented by all the vendors by that time Microsoft Web form will be matured( Dream On...)
    3. JSF has an ugly event model. There is a huge IF statement to catch event originators. So it still sucks compared to Microsoft Webforms.
    Check http://sourceforge.net/projects/salmon/ if you want a better comparison on what is available on Java end compared to .Net
  27. JSF has an ugly event model. There is a huge IF statement to catch event originators. So it still sucks compared to Microsoft Webforms.

    This is not true. You are talking about the old, clunky appplication handler idea, right? The event model in JSF is now very similar to that of Swing (JavaBeans event model).

    JSF is very well suited to great tool support (for neophytes), but it is flexible enough underneath for power users. It's not perfect (what is?), but I think it will compete very well with whatever Microsoft has to offer. One of the things that JSF does is take us from page-centric to component-centric. Very nice...
  28. <bill willis>This is not true. You are talking about the old, clunky appplication handler idea, right? The event model in JSF is now very similar to that of Swing (JavaBeans event model).

    JSF is very well suited to great tool support (for neophytes), but it is flexible enough underneath for power users. It's not perfect (what is?), but I think it will compete very well with whatever Microsoft has to offer. One of the things that JSF does is take us from page-centric to component-centric. Very nice...
    </bill willis>

    This is what I am talking about. Here is the code from online tutorial

    The user selects a package by clicking on one of the buttons representing a package. When the user clicks one of the buttons, an ActionEvent is generated, and the processAction(ActionEvent) method of the CarActionListener listener implementation is invoked. Here is a piece of the processAction(ActionEvent) method from CarActionListener:

    public void processAction(ActionEvent event) {
      String actionCommand = event.getActionCommand();
      ResourceBundle rb =
        ResourceBundle.getBundle("cardemo/Resources",
        (FacesContext.getCurrentInstance().getLocale()));
      if (actionCommand.equals("custom")) {
        processCustom(event, rb);
      } else if (actionCommand.equals("standard")) {
        processStandard(event, rb);
      ...
      } else if (actionCommand.equals("recalculate")) {
        FacesContext context = FacesContext.getCurrentInstance();
        String currentPackage =
          (String)context.getModelValue(
          CurrentOptionServer.currentPackage");
        if (currentPackage.equals("custom")) {
          processCustom(event, rb);
        } else if (currentPackage.equals("standard")) {
          processStandard(event, rb);
        }
        ...
      }else if (actionCommand.equals("buy")) {
        FacesContext context = FacesContext.getCurrentInstance();
        context.setModelValue("CurrentOptionServer.packagePrice",
        context.getModelValue(
          "CurrentOptionServer.carCurrentPrice"));
      }
    }
  29. This is what I am talking about. Here is the code from online tutorial

    Yes, that is an unfortunate example (probably thrown together quickly). But I hope it is clear that you don't have to do it this way?
  30. Echo is much more like WebForms than JSF. (I've used WebForms)
  31. A comparison between JSF and WebForms has been done, but it's in French. If you know French or use a translator you should be abel to read it.

    Translator
    http://www.av.com

    My JSF Page
    http://www.jamesholmes.com/JavaServerFaces/

    -James
  32. It's worth noting that the comparison is quite out-dated -- it's from September. JSF has come quite a long way, especially with EA4.

    Kito D. Mann
    kmann at virtua dot com
    Author, JSF in Action (Manning)
  33. Going to have a look on this new draft and provide to you an updated version of
    this French article which was supposed to be published on TSS (by Floyd) after
    being translated in US ...

    Sami
    DotNetGuru.org
  34. http://www.dotnetguru.org/articles/Comparatifs/JavaServerFacesvsWebForms/JSF
  35. Re: JSF and ASP.NET Comparison URL[ Go to top ]

    By the way, this article is pretty out of date -- it's based on a version of JSF from fall of last year, which wasn't nearly as good :-).

    > http://www.dotnetguru.org/articles/Comparatifs/JavaServerFacesvsWebForms/JSF

    Kito D. Mann
    Author, JSF in Action (in progress)
    JSF FAQ: http://www.jsfcentral.com
  36. Tapestry vs. JSF[ Go to top ]

    Hi,

    question to the developers from the tranches: I would like to know, what would you use? Tapestry or JSF? How do they compare one to another?
    Sure, JSF is currently an early access. Still, did someone play with it?

    thanx,
    Stefan
  37. Tapestry vs. JSF[ Go to top ]

    I use Tapestry and have played with JSF's EA release. JSF and Tapestry use two very different models to develop the UI. JSF lets you handle UI events on the server side. For example, the click on an HTML button can be handled on the server side as a Button_click event on the button component. The lead for developing JSF is McClanahan, the original author of Struts. Its a nice improvement over Struts and JSP. However, In order for this to succeed, you will need a excellent IDE with lots of standard widgets (like a Calendar widget, tree widget etc) and I don't see that happening soon.

    Tapestry is completely different from JSP or Struts. It allows you to encapsulate HTML/JavaScript/CSS code as components that are manipulated as regular Java components. IMHO, Tapestry is a vastly superior model to JSP or ASP or WebForms. The level of reuse in Tapestry is amazing. IMHO, Sun did a big mistake in coming up with a framework like JSP in a hurry to compete with Microsoft's ASP. Download Tapestry and check it out. Your eyes will open to a new,revolutionary and stunningly easy way to develop web applications.
  38. Venkatesh,

    I agree with your opinion that Tapestry is a very good framework. However, I'd bet that Tapestry is innaccessible to anyone that doesn't have a *lot* of patience as Tapestry's documentation seems not to be new, revolutionary or stunningly easy. In my opinion, the documentation seems to be similar to the MS Office documentation that is mostly just a collection of facts that informs but doesn't explain. Tapestry is a good framework, and it's frustrating for me to think that maybe Tapestry's adoption might be limited by the weakness of Tapestry's documentation.

    What documentation did you use to learn Tapestry? Are you aware of any documentation other than the documentation that is bundled with the code?

    Thanks.

    Doug
  39. Design mode[ Go to top ]

    Does anybody know whether there is a separate design mode for the components?

    This is useful for instance to render component differently while presenting it in an IDE.

    Artem
  40. RE: Design Mode[ Go to top ]

    There is no mention of a design mode. This is actually a very good idea considering that the rendering of most of the components that are more complex than a say a single input box will probably be heavily dynamic. To be able to represent the component in design mode in a tool could be useful and make development much faster.

    It does seem like the spec is being developed with tool support in mind, not as central to the spec or clearly defined in the spec as I would like to see it, the spec authors may disagree with that.

    The general concept of tool support at the component level seems to be that all attributes associated with a component are accessible via general get/setAttribute methods with another method getAttributeNames. This way tools can display a list of properties that can be associated a particular component.

    For each renderer associated with each component type through a render kit a tool would generate a tag on the fly to support this component in a jsp page. The tool could acquire information about the component by introspecting the renderer through AttributeDescriptors that are registered with the renderer. The AttributeDescriptor provides meta data about the component.

    I think that the spec is very light on tool details with the intention of allowing tool vendors a lot of flexibility. As long as the tools can support JSF apps written in different tool portably then this should be fine.

    I know somone mentioned the spec is long 500+ pages ... a lot of that is component level spec stuff that is for reference. The spec is actually very well written and accessible ... maybe a quiet evening of reading or at most a weekend.
  41. More tool integration[ Go to top ]

    Thank you for the reply Mark!

    So there is basically no custom property and component designers then?
    Why could not they replicate at least JavaBean level tool support?

    Artem
  42. Artem,

    One of the things that's not particularly clear about JSF is that the component model is completely built on top of JavaBeans. As such, it inherits the JavaBeans' features, including customizers. This implies a full-fledged design-time mode like Swing, or more specifically something similar to VS.NET's WebForms designer.

    Also, as far as vendor support goes, take a look a the Expert Group list for the JSR. It includes Sun, Borland, IBM, BEA, Macromedia, and others -- most of the major J2EE and Java IDE vendors.

    So, even if it's not the most mature thing out there right now, it certainly has a lot of industry backing, it's quite functional right now, and it is still drastically improving.

    Kito D. Mann
    kmann at virtua dot com
    Author, JSF in Action (Manning, in progress)
  43. Documentation for Tapestry[ Go to top ]

    Tapestry has been going under extremely rapid evolution during 2003

    - Change in license from LGPL to ASL
    - Incubation at Jakarta and now promotion to Jakarta project
    - Massive overhaul of the internals, retaining all the power of Tapestry while de-emphasising the use of long XML specifications
    - Creation of the "Tapestry in Action" book for Manning

    It is true that the Tapestry distibution is very much lagging in terms of documentation; the documentation was good and accurate when it was written (in the 2.0 - 2.2 timeframe) but is now vastly out of date; with the exception of the component documentation (which is more recent and highly useful).

    My top priority is to complete the book. This is well underway but I can't say when the publish date will be (sometime in the fall most likely), or if Manning will consent to preview chapters online (though its not unlikely). I'm writing the book and working a full time job!

    Once the book is completed, I can focus on the free reference documentation provided with the framework. In fact, the focus of the beta period is primarily about documentation, since the code itself appears to be very stable.

    Meanwhile, Neil Clayton is working on the revised Tutorial.
  44. Howard,

    Thanks for the update on the status of the documentation.

    I'm *very* glad to hear that you're writing a book. I'll definitely be a buyer.

    By the way, I agree that the component documentation is highly useful. However, in my opinion, the component documentation would be even more useful if it included some basic usage notes. For example, a little blurb that explains the usage of "@" in jwcid would be helpful.

    Speaking of usage notes, I would recommend that you include some notes on how to place code in the component/page lifecycle methods. For example, "the pageBeginRender should be used to ...". In general, I believe that a *much* more thorough explanation of the component/page lifecycle is needed.

    Thanks to Neil for working on the tutorial. The tutorial is desperately needed.

    Doug
  45. Tapestry vs. JSF[ Go to top ]

    Tapestry is completely different from JSP or Struts. It allows you to encapsulate HTML/JavaScript/CSS code as components that are manipulated as regular Java components. IMHO, Tapestry is a vastly superior model to JSP or ASP or WebForms. The level of reuse in Tapestry is amazing.


    Can you tell me what is reusable in Tapestry ? I know nothing about Tapestry, but I was seeing tapestry page, and looks it needs to much files for a hello world.

    > IMHO, Sun did a big mistake in coming up with a framework like JSP in a hurry to compete with Microsoft's ASP.

    I liked JSF. Seems very natural to me, like visual components, events and so.
  46. Tapestry "Hello World".

    Simple app to display the current time, with a link to refresh the page.

    It consists of two files: Home.html and a web deployment descriptor.


    Home.html:
    <html>
    <head>
    <title>Hello</title>
    </head>
    <body>
    <h1>Hello World</h1>

    The current time is:
    <span jwcid="@Insert" value="ognl:new java.util.Date()">Jan 1 2001 12:00:01</span>.

    <br>

    <aa href="#" jwcid="@PageLink" page="Home">Click here</aa> to refresh this page.

    </body>
    </html>


    WEB-INF/web.xml:
    <?xml version="1.0"?>
    <!DOCTYPE web-app
        PUBLIC
        "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
        "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

    <web-app>

    <servlet>
    <servlet-name>hello</servlet-name>
    <servlet-class>org.apache.tapestry.ApplicationServlet</servlet-class>

    <servlet-mapping>
    <servlet-name>hello</servlet-name>
    <url-pattern>/hello</url-pattern>
    </servlet-mapping>

    </web-app>



    Notice that the Home.html would preview correctly in a WYSIWYG editor (had to change "a" to "aa" to satisfy ServerSide). We've included a sample value for preview purposes ... it is excised by Tapestry.

    Insert is a component for inserting text into a rendered page.

    PageLink is a component for creating a navigation link to a page within the application; in this case, back to the Home page.

    We've taken some shortcuts using OGNL (http://www.ognl.org) here ... having the new java.util.Date() inside the page template is bad form, but acceptible for prototyping. That isn't Java code ... thats an OGNL expression (which happens to look a lot like Java code). Generally, any OGNL expression more complex than a property name belongs in a specification ... but Tapestry lets you decide.

    Tapestry does not have any concept of "compiling" a page to Java; there is no way to include Java code in a Tapestry template and absolutely no need to do so, ever.
     
    Anyway, that's it. Package this stuff up as a WAR with the Tapestry libraries and dependencies and you are done.

    Obviously, this is a Hello World, not a real application. Adding more complex logic means you might have to write a couple of lines of Java or Jython, and may need to start using an XML page specification (to move non-presentation logic out of the HTML template).
  47. Re Tapestry[ Go to top ]

    I have heard a lot about Tapestry recently and in fact looked into at about the same time that the first JSF spec was released trying to decide which framework to work with. Previously I had worked extensively with Struts and it is a decent framework but it's concept of components, well there really is not any. This is what attracted me to Tapestry.

    Anyway, at the same point JSF spec came out. I got as far in tapestry as seeing that there is a concept of a component and there is a way to package these components in jars so that they can be reused easily, tapestry allows you to operate on objects rather than the request, tapestry takes care of dealing with url construction etc... This is not even an attempt to describe tapestry, I have only the most superficial knowlege of it. The point is that the very attractive concept in Tapestry is the ability to package a component including the objects, the rendering, the client side scripts, etc into a neat componentized package. If my perception here is wrong let me know. JSF does not have this concept at all and I for one think it is unfortunate.

    I have used JSF extensively for the past 8 months. I have written a lot of complex components from tables, calendars, xform render, tab set, ... Some of the components have extensive client side functionality with javascript. The JSF spec currently does not have a very clean way to deal with this. It can be done through custom renderers that inline javascript or 'KNOW' about a javascript library which the user has to one way or another be linked to the rendered page. I believe that JSF spec team is expecting that different containers will provide JSF implementations and in doing so provide a component package with varying level of client support on different devices. This is fine, but regardless of the number of components provided by any of these implementations there will still be a great need to develop custom components or composite components. With regard to these components the spec does not provide any guidance or defined way to wire in javascript other than through the custom renderers. I think that these problems will be quickly solved through usage patterns. I have not come up with a great solution to this, if someone else does have a good idea then send feedback to the spec team.

    I decided to go with JSF because it will be a standard, it is not perfect, but it is much better than struts and it truly does provide a tremendous amount of flexibility. I have been able to build an extremely rich html application with a good balance of client side functionality. With some minor tweaks to the JSF implementation we have also been able to get excellent performance.

    All in all I have to say that JSF is a big step in the right direction. Read the spec, get the download, and start playing.
  48. Re Tapestry[ Go to top ]

    Hi Mark,

    After your comments I'm sure JSF is the way.

    Do you think that JSF is stable enough to start working with ?
  49. JSF : Ready for prime time[ Go to top ]

    To explore and learn absolutely, for more serious production code only if you are comfortable on the cutting edge ...

    1. You must be willing to accept the fact that you will have to refactor portions of your implementation as the spec evolves. However, it seems that with the latest release that there are only a few areas that will be significantly changed - namely application event handling and also options for state management between requests. Take this lightly, I have zero information other than what is in the spec about future directions.

    2. You must be able and willing to work around small issues by possible rewriting a few of the component classes and even some of the core classes in the com.sun.faces package

    3. We are using an complete set of custom components from UIComponentBase down. I do not think this is necessary anymore with the latest release that incorporates support for facets.

    4. The licensing is an open issue. Sun has not made it clear how this spec will be licensed and who will be able to provide 'official' implementations or who will be able to simply utilize the interfaces and provide unoffical implementations (Could someone comment on this ?)

    Technically, I have put together an application not just a little better than any struts application I worked on previously, but leaps and bounds better. Also, the JSF app that I have worked on plugs seamlessly into struts at the action level so that it can take advantage of all the customizations we have made to our struts servlet for things like security, history tracking, single signon, exception handling, etc.....

    If you want to jump ahead of the curve I strongly suggest that you dig in now because based on what I have been able to accomplish with JSF there is no question in my mind that it will become, if not the defacto standard, then at least as popular as something like struts is today.

    With all that said, it is in no way perfect, but it is a big step in the right direction for the poor souls (like me) who have to write blasted html based applications.
  50. Re Tapestry and JavaScript[ Go to top ]

    This is the chapter I'm working on for the book right now.

    Tapestry has an entire subsystem devoted to generating client-side JavaScript from specialized templates called "script specifications".

    Templating is necessary to adjust to the individual component; the example is the Palette component, which provides a complex UI for performing multiple selection from a list. It renders out as two <select> elements plus buttons for moving items between the "selected" and "available" columns and, optionally, for ordering the items in the "selected" column.

    Lots of client-side JavaScript. However, using a Palette component is no different from any other component:

      <span jwcid="myPalette"/>

    And put a little bit of configuration into the page's specification (i.e., tell the Palette where to get the list of items and where to put the list of selections, etc.)

    At runtime, the JavaScript automatically adjusts to the name of the form and the assigned name for the Palette. You can have ten Palettes in one form, or ten Palettes in ten forms ... doesn't matter, the JavaScript is adjusted so that there are no naming conflicts. It all just works.

    To me, that's a component; you drop it in and it works, no questions asked.

    Meanwhile, to your point, I feel that JSF is a step in the wrong direction. Any solution that mandates tool support to be viable ultimately isn't. You end up with a write-once system that can't be editted because of the massive amounts of machine-generated source code.

    JSF is not the standard, it may become a standard. Sun has a pretty spotty history of enforcing standards along these lines; everytime they push a solution as the only solution (for instance entity EJBs and CMP) the developer community has a tendency to dive in, suffer the concequences, and create a backlash. Sun's been trying to get JSPs right for over five years, been trying to get EJBs, especially entity EJBs, right for nearly as long ... and after all this time, the "tool support" from vendors is still pretty darn weak (outside of very high end packages like WSAD ... which has its own issues).
  51. Large spec![ Go to top ]

    JavaServer(TM) Faces Specification 1.0 Public Review Draft 2
    jsf-1_0-prd2-spec.pdf

    532 pages
  52. Note about JSF tag names[ Go to top ]

    BTW, what do you think about tag names in JSF taglibs? I was very impressed when I saw <input_text> tag first time. Guys, it's old good K&R C! Why don't use more consistent naming style, <inputText> for example? What is your opinion?

    Igor
  53. Why not applets?[ Go to top ]

    JSF is all about Java components rendered with help of HTML/WML etc.

    There is one thing which I don't understand.
    We have applets for years and they are technologically superior comparing to anything
    which might be produced by JSF spec/implementation.

    Applets are components. They are Fast, Extendible. They provide rich user interface.

    Applets can use HTTP or even soap to speak to servers
    Applets are not affected by stateless nature of HTTP protocol as ordinary web pages (less tricks is needed)

    For those who like XUL - applets can support XUL (see what Thinlets can do).

    Note that both applets and JSF should be used by web developer as black boxes. He just should
    Use some HTML tags to embed them inside a webpage. In case of applets it is even simpler for ordinary web developer to do so.

    Why not to use them?
    Why to downgrade to JSF?

    I still think that JSF is needed...but there are other (better) alternatives
    here for years.

    If we just had jre1.4 in every MS IE web browser..
    But if users can download Flash plugin...why cannot they download java plugin?


    Michal