Article: A first look at JavaServer Faces Part 1 and 2

Discussions

News: Article: A first look at JavaServer Faces Part 1 and 2

  1. Javaworld has published two articles on the much discussed JavaServer Faces. The first article discussed the fundamentals, including the JSF lifecycle.
    The second goes into detail on the components themselves, such as validators, model objects, custom components, rendering, and event handling.

    Read Part One: JavaServer Faces Fundamentals and Lifecycle

    Read Part Two: JavaServer Faces Components

    Threaded Messages (18)

  2. The article is very nice gives a good intro on JSF. Just wanted to make a comment not related to article is JSF is
    a copy of .Net Webforms. Looks like microsoft is one step ahead. If they really buy macromedia as the rumor suggests .Net UI will be much more rich compared to J2EE.
  3. Dude. There are a trillion frameworks for the Web. Just because Microsoft made another doesn't mean jack. There are things very similar to JSF already in the Java world. The point of JSF is that it's a standard. Thank you please drive through.
    Steve
  4. *** Just because Microsoft made another doesn't mean jack.
    *** The point of JSF is that it's a standard.

    And since when has lack of standards held Microsoft back from eventually dominating any market the choose? If MS buys Macromedia, they'll take the extremely promising FlashMX and turn it into Flash.NET, giving .NET apps a rich, interactive client frontend. JSF would have a hard time keeping up with that.
  5. I really believe that Flash ui's will make their way into many web-apps.Flash is almost vb-like it its ease of use to create web-app front ends. Has anyone gotten a change to look at droplets, almost a server side flash if you will. JSF almost seems to be more of a rehashing of html forms than of .NET forms.
  6. JSF is capable of rendering more than just HTML, but for now, HTML is all you get.

    Has Macromedia removed the restriction that FlashMX must use JRun? As long as they have that restriction, noone's going to use it, which would be a damn shame.
  7. Kenny,
    I'm guessing that your refering to remoting, Macromedia offers a J2EE version, a .NET version.
    They might as well have keep it locked to JRun b/c of the outrageous pricing of $999. After the pricing was released I know that alot of the beta-testers began looking into sending&recieving soap messages as a opposed to using flash remoting
    The pricing, thats a damn shame.
    Good luck to JSF, but I'll be waiting before I give it anymore thought.
  8. A thousand bucks? Holy crap, that's outrageous.

    How extensible is FlashMX? In a SOAP implementation can be plugged in, then the GUI could talk direct to a web service, which would be rather neat - complete and total decoupling of client and server. Amen.
  9. Actionscript (FlashMX's scripting language), is essentially a JavaScript variant, so its slightly OO, which allows you to extend everything as far as scripting goes. The swf format is open sourced as well
    http://www.macromedia.com/software/flash/open/licensing/fileformat/faq.html

    As far as SOAP, Flash is limited to loading data from only within its domain. Basically there's always going to be a proxy page (asp,php,jsp,cfm,cgi/perl) that does the heavy lifting. Also, flash can only pull data from the server, the server can't push data to the flash player without recieving a request first.

    So pretty much you choose the SOAP implementation you like, build a proxy page and have flash communicate with that.

    here's a link to get you started
    http://www.flash-db.com/Translate/TranslateClient.php?page=1

    By the way, I'm in no way affiliated with Macromedia. Flash as a GUI has a great future, that is until Microsoft buys Macromedia.
  10. <quote>
    Also, flash can only pull data from the server, the server can't push data to the flash player without recieving a request first
    </quote>

    as i recall flash does have xml sockets, so it prolly wont be pretty but its possible
  11. <Steve>
    The point of JSF is that it's a standard.
    </Steve>
    I don't think that this is the point. The point is that the ASP .NET Forms are extremely well suited for rapid application development and provides a quite rich component set. There is nothing in the J2EE world that comes close as far as I know - although there are very good frameworks available, of course. J2EE has fallen way behind in this respect and JSF is sort of the last hope to catch up with it.

    And now some promotion for one of these frameworks http://www.iternum.com/i3test is about the way I think that web development with J2EE should be like :-).

    Regards, Karl
  12. " <Steve>
    The point of JSF is that it's a standard.
    </Steve>
    I don't think that this is the point."

    Actually, this is a very important point. What we will ultimately end up with is a number of frameworks that will incorporate the JSF Web component standard.

    Could you please explain how ASP.NET Web Forms are better suited for RAD? I don't see anything technically in the framework that makes this so. You must be referring to the prepackaged components that ship with it, so for now you may have a tenuous point. That's a very VB-like attitude.

    Later this year, I think this will change quickly. We will still have a number of web application frameworks (choice is nice), but now we will have a standard Web GUI component framework that the majority of Java developers will be working with. It won't take long for libraries of rich open source and commercial components to show up.

    This is why I think your "last hope to catch up" statement is a bit odd. Not only will we have a rich collection of web application frameworks, but we will now have a rich set of reusable web GUI components. That sounds great to me!

    By the way, why mention your own framework when JSF is our last hope?
  13. , but we will now have a rich set of reusable web GUI >components. That sounds great to me!


    check out www.servletsuite.com/jsp.htm for example.
  14. <Snip>
    Could you please explain how ASP.NET Web Forms are better suited for RAD?
    </Snip>
    There are a number of reasons. For, me the most important is, that it is easy to assemble and test a page together with application logic seemingly "in situ" using a standardized approach (standard as in "MS standard" of course). I am not aware of any application framework in the JSP/Servlet world that is able to do this in a thorough way. The components are important as well, of course.

    Also, I think it is not the components whats most important - it's the overall application framework that should among other things

    - be extensible
    - be easy to learn
    - support RAD
    - have clean aggregation models for components

    As of now, there isn't even a standard specification for JSF. Which is good, because the spec. still has some major problems. While it is getting finshed (hopefully!) time passes. Also, the fact that it is standard will not automatically make a host of components appear.

    In my opinion, it is far more likely that various vendors will integrate "enhanced" JSF into their products. As with EJBs this is nice concerning training and development, but doesn't necessarily mean that "your components run in my server".

    <Snip>
    By the way, why mention your own framework when JSF is our last hope?
    </Snip>

    As Yoda said, "no there is another one" - no really,
    probably, because I'm vain :-). But also, because this is the one JSP based framework I know about that actually does and supports quite a bit of what *I* find most important about web guis.
  15. You should look at SOFIA (formerly know as The JADE Open Framework). http://sourceforge.net/projects/salmon Does everything that you think a framework like this should do:

    <snip>
    - be extensible
    - be easy to learn
    - support RAD
    - have clean aggregation models for components
    </snip>

    It doesn't only support RAD it already integrates with RAD tools. Java vendors have proven time and time again that they just don't know how to do this (as demonstrated by the popularity of applets, AWT apps and Swing apps). At this rate, they will be fussing with this spec for another two years before anybody can really use it for a production project, it it probably still won't work right when it's done.
  16. "There are a number of reasons. For, me the most important is, that it is easy to assemble and test a page together with application logic seemingly "in situ" using a standardized approach (standard as in "MS standard" of course). I am not aware of any application framework in the JSP/Servlet world that is able to do this in a thorough way. The components are important as well, of course."

    This is not an explanation of how one framework is superior to the other. You are merely describing tool integration here. This can easily be done with any one of the numerous Java Web frameworks out there, including the forthcoming JSF.

    "Also, I think it is not the components whats most important - it's the overall application framework that should among other things"

    I would tend to agree. The Java community gives us a rich variety of frameworks to choose from, most of which are open source. JSF is an attempt to provide a standard Web GUI component framework and will not replace the majority of these frameworks but will hopefully allow use to use a common UI component set and lifecycle between them.

    "As of now, there isn't even a standard specification for JSF. Which is good, because the spec. still has some major problems. While it is getting finshed (hopefully!) time passes. Also, the fact that it is standard will not automatically make a host of components appear."

    You are commenting on an early draft - please give it a chance! I am constantly surprised by the pessimism many Java developers exhibit given the wealth of great software we have already. Work is now progressing rapidly on JSF. You are correct - The existence of JSF will not *make* a host of standard components magically appear, but if properly designed, it will remove barriers and *allow* this to happen quickly.

    Once JSF is out, we should see better tool support. Speaking for my company, we will now find it much easier to automate the creation of Web GUIs in our tools once JSF matures. At the moment, we have to pick and choose which existing framework to support. This creates a barrier to creating good tool support. So I guess the wealth of Java frameworks is both a blessing and a curse :-)

    I assume you have already posted comments for the JSF expert group to consider? I would encourage you to do so if you haven't already. They can't implement every idea, but they will at the very least give your well-reasoned arguments and design ideas due consideration.
  17. "This is not an explanation of how one framework is superior to the other. You are merely describing tool integration here. This can easily be done with any one of the numerous Java Web frameworks out there, including the forthcoming JSF."

    No. RAD is *not* tool integration. Granted, that proper tool integration make RAD a lot easier. However, for me RAD does also imply things that are not only accomplished by tools but that must be considered in the framework or container. For example, a framework that requires repositories requires provision *in the framework* to reread these repositories and reconfigure itself at runtime. Likewise, a container based framework (like EJB, JSP etc.) - in my opionion - must provide for "hot deployment" of classes and libraries, ideally maintaining overall application context. Otherwise, it is just not "rapid". Consider a system (available on the market and very expensive) that has visual modelling tools for web pages state modelling and flow but does not allow for the classes to be referenced therein to be updated without app server to restart, taking about 2 minutes on a fast and 10 minutes on a typical development machine. Tool integration: Yes!, Rapid: Nope!

    Otherwise I absolutely agree with your comments.
  18. *** a container based framework (like EJB, JSP etc.) - in my
    *** opionion - must provide for "hot deployment" of classes
    *** and libraries, ideally maintaining overall application
    *** context

    Servlet/JSP containers do provide this. You just recompile the classes, and the container picks up the changes. However, they generally also restart the application in the process, which is less good.

    EJB is the monster. The code-compile-deploy-test cycle is absurdly time-consuming. But the same does not hold for Servlet/JSP containers.
  19. The article is nice to read.But JSF is an early access (EA) release, and, as a result, is somewhat immature. Have to wait for some more time so as to implement Web-based user interfaces using JSF.

    -@bhijit