JCP Releases JavaServer Faces 1.0

Discussions

News: JCP Releases JavaServer Faces 1.0

Bookmark and Share Get thread feed

  1. JCP Releases JavaServer Faces 1.0 (56 messages)

    • Posted by: Kito Mann
    • Posted on: March 03 2004 15:36 EST
    The long-anticipated final version of the JavaServer Faces (JSF) specification 1.0 has been released. As Sun said on its ballot notes "This has been a long road. I'm glad to see this important JSR coming in for final approval!"

    The approval ballot is available, and shows that everyone voted "Yes" (apart from Apple who didn't vote).

    Sun's official description of JSF is:

    "JavaServer[TM] Faces technology simplifies building user interfaces for JavaServer applications. With the well-defined programming model that JavaServer Faces provides, developers of varying 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."

    Download JSF 1.0 final draft and RI

    I've also written a short editorial about why JSF is significant, and what we can expect to see in the future: JavaServer Faces 1.0 has been released, but why does it matter?
    Reply to this

    Threaded Messages (56)

  2. Granularity of Components[ Go to top ]

    It should be interesting seeing what the granularity of the JSF components ends up being. Menu's, Calendars and Tree controls will be fun to start but what I'd really like to see are Forum's, Webmail, Photo Albums, Blogs etc. so that Java can finally start competing zope or php as a web frontend framework.
    Reply to this Reply to original

  3. JSF vs Nukes[ Go to top ]

    It sounds like what you need is Nukes more than JSF. check it out: http://jboss.org/developers/projects/nukes/index
    Reply to this Reply to original

  4. JSF Forum[ Go to top ]

    It looks like this thread becomes a good place for advertising.
    This is my two cents:
    JavaServer Faces Technology Developer Forum.
    Reply to this Reply to original

  5. JSF vs Nukes[ Go to top ]

    and check out JSOS as well:
    http://www.servletsuite.com/servlets.htm
    Reply to this Reply to original

  6. There is mvnForum, opensource Jsp/Servlet forum[ Go to top ]

    Hello Random Fetch and members of TSS,

    If you are looking for a good, rich feature Java/Jsp/Servlet forum, then try mvnForum at http://www.mvnForum.com . This project is mature and very stable although it is still in RC development phrase. I hope to release the final mvnForum 1.0 GA soon and considering porting mvnForum to JSF in the near future.

    For the current feature please visit http://www.mvnforum.com/mvnforumweb/feature.jsp

    To download mvnForum now, please visit http://www.mvnforum.com/mvnforumweb/download.jsp

    Thanks and I hope you will enjoy mvnForum ;)

    Minh Nguyen

    mvnForum Developer
    http://www.mvnforum.com

    MyVietnam Group
    http://www.MyVietnam.net
    Reply to this Reply to original

  7. JSF Components[ Go to top ]

    It should be interesting seeing what the granularity of the JSF components ends up being.>


    I think developers won't wait so long for sophisticated JSF Java Web Components.
    You can try that for a beginning : http://www.javawebcomponents.com

    John Webber.
    Reply to this Reply to original

  8. WebGalileo Faces 1.0 Java web components are available[ Go to top ]

    WebGalileo Faces 1.0(Java Web Components with full support of Sun
    Java Server Faces specification) sales were launched.

    Thanks.
    http://www.javawebcomponents.com
    Reply to this Reply to original

  9. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    At the end, yes folks, we reach the top of the complexity => HTML, XML,
    (xxx)ML programming language, congrats to JSF!

    Check out this JSF tutorials:
    http://www.exadel.com/tutorial/jsf/jsftutorial-kickstart.html

    For a "Hello World" JSF application, you need:
    - *one* Java file (Great, only one!)
    - *tons* of (xxx)ML files. Cool, I really love XML files. I'm the new
    generation of the most-up-to-date XML programmers: Everything: process,
    functions, datas, objects are XML, yes!

    Anyway, who can read such a JSP file below (this should be a HTML file?)

    <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
    <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
    <f:loadBundle basename="bundle.Messages" var="Message"/>

    <HTML>
     <HEAD> <title>Input Name Page</title> </HEAD>
     <body>
      <f:view>
        <h1><h:outputText value="#{Message.inputname_header}"/></h1>
        <h:messages style="color: blue"/>
          <h:form id="helloForm">
    <h:outputText value="#{Message.prompt}"/>
    <h:inputText id="userName" value="#{PersonBean.userName}" required="true">
    <f:validateLength minimum="2" maximum="10"/>
    </h:inputText>
          <h:commandButton id="submit" action="sayhello" value="Say Hello" />
         </h:form>
     </f:view>
    </HTML>

    Nobody can read such a file (and creating them by hand, o gosh...). My
    conclusion on JSF:
    - JSF is (xxx)ML friendly. Cool!
    - JSF is tool vendors friendly. Without a tool, you can forget it. So
    why not directly designed JSF as a "meta model" which fits into MOF
    (Meta Object Facility) repository? Here we don't need to read those
    (xxx)ML files, because they are used from "maschine" to "maschine". In
    this case we can use MOF Management tool, which should be available
    somewhere to do our:
    - Modelling with UML
    - Modelling for the datamodel
    - and modelling for JSF (OK, this is going too far ;-))

    Yep, one tool for all!

    Until we can have the JSF within the MOF, I stay KISS: use Enhydra XMLC
    with EAF or Barracuda. Check out Barracuda for sophisticated MVC
    framework (long running events, localization, components, etc.):
    http://barracudamvc.org/Barracuda/index.html

    Cheers,
    Lofi.
    http://www.openuss.org

    BTW 1, this would be a good new project for AndroMDA team. Creating
    those (xxx)ML, JSPs automatically from the UML diagram just like
    BPM4Struts ;-)
    BTW 2, a good reason for Compuware with its OptimaJ to make a new study,
    especially using JSF as the presentation layer. Maybe we can get 100%
    productivity?
    Reply to this Reply to original

  10. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    Lofi,

    I beg to differ: JSF is not by any means another (xxx)ML language as you are stating. The XML files cited on exadel's tutorial are just configuration files you will see on any servelet server out there. The only exception is the JSF configuration file itself, and even that file doesn't have any "code" in it, just configuration parameters. It is not a new language. So of these "tons" of XML files you have to edit, there's just one new one, so for a simple application, tons equals 2 (web.xml and jsf-config.xml). ;) And for big applications, these XML config files would still be few.

    Regards,
    Henrique Steckelberg
    Reply to this Reply to original

  11. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    Henrique,

    yes, you are correct. Maybe I just hope too much from the JSF team ;-) I thought JSF would be something new, where we can say, allright folks, here we have a simple good way to write our web presentation layer! Something innovative. But JSF is just a mix from the technologies we already had (JSP, Servlet, XML configs, Taglibs).

    What disturb me is that the "tool orientation" of JSF. I feel that if you need some sophisticated tools for your work, it seems that the design was not good enough. Except that you plan this in the front. But as I said, this would be a good thing for MDA ;-)

    Cheers,
    Lofi.
    Reply to this Reply to original

  12. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    Henrique,

    >
    > yes, you are correct. Maybe I just hope too much from the JSF team ;-) I thought JSF would be something new, where we can say, allright folks, here we have a simple good way to write our web presentation layer! Something innovative. But JSF is just a mix from the technologies we already had (JSP, Servlet, XML configs, Taglibs).

    Yes, but as I said before, JSF is not tied to JSP, you can create your web pages in JSF using XLST for example, and other solutions will appear too. If you use Smile for example, an Open Source implementation of JSF, you can code your pages in Java, just like when you code Swing UI.

    OTOH, to expect that a totally new technology would be created out of nothing would be crazy, I guess. Imagine just throwing away all the knowledge and experience regarding Servlet servers, APIs and everything else. JSF is very flexible in this regard, you can adapt it to work on different technologies, not just JSP.

    >
    > What disturb me is that the "tool orientation" of JSF. I feel that if you need some sophisticated tools for your work, it seems that the design was not good enough. Except that you plan this in the front. But as I said, this would be a good thing for MDA ;-)

    Well, I expect that the tools you will need will be very similar to today's Swing or VB-like drag-and-drop editors, which need not be too sophisticated IHMO, nothing different from ASP.Net, for example, and very common in UI developement. And AFAIK, JSF was planned from the beggining to be suported by tools in this manner, being it based on JavaBean UI components.

    I just can't see how you would use an MDA tool to create UI code and config, though. Is it about automatic forms and navigation code creation, or am I missing something here?

    Regards,
    Henrique Steckelberg

    >
    > Cheers,
    > Lofi.
    Reply to this Reply to original

  13. MDA and JSF[ Go to top ]

    <quote>
    I just can't see how you would use an MDA tool to create UI code and config, though. Is it about automatic forms and navigation code creation, or am I missing something here?
    </quote>

    You don't implement the presentation layer UI directly in such a MDA tool. But at least you can generate all the "skeletons":
    - Design the whole workflow of your application in combination of use case, activity and class diagrams. Mark them with <- Generate the skeletons of your JSPs or HTMLs or WMLs, Servlets, XML configs, your base framework from the diagrams, etc. Everything what you need to begin.
    - Implement the rest (like refine the JSPs or HTMLs, etc.).
    - Back to the top in iterative way.

    Check out the great work from Wouter Zoons at AndroMDA with his BPM4Struts (Business Process Modelling for Struts with AndroMDA):
    http://team.andromda.org/tiki/tiki-index.php?page=Bpm4StrutsHowTo&PHPSESSID=e4b9e6e46dd3b54e321960d9f5a08a4e

    And Dmitry is right by saying "And if we will talk about MDA the underlying technology we are using in our code generation is not so important at all". Yep, build a new cartridge and port your code ;-)

    Regards,
    Lofi.
    Reply to this Reply to original

  14. MDA and JSF[ Go to top ]

    Lofi,

    Based on your explanation, I can't see why JSF couldn't fit on a MDA tool, then. My guess is that it could even create some skeleton code for data entry forms, not just navigation code, but that is just me shooting in the dark.

    Here we can see another advantage of JSF specification: you won't have to create 100s of plugins, one for structs, other for tapestry, other for Echo, W4E, etc., in the future. As long as you use an JSF compliant web framework, only one JSF plugin for your MDA tool will do.

    Regards,
    Henrique Steckelberg
    Reply to this Reply to original

  15. MDA and JSF[ Go to top ]

    <quote>
    Based on your explanation, I can't see why JSF couldn't fit on a MDA tool, then. My guess is that it could even create some skeleton code for data entry forms, not just navigation code, but that is just me shooting in the dark.
    </quote>

    Sorry if I was not clear enough ;-) Surely JSF fits 100% to MDA tools. Therefore my comment about 100% more productivity for TSS case study with Compuware if they would use JSF ;-) And yes, using tag values in UML, you can generate validation code, navigation code, config files, etc.

    The big question for me is that what kind of UI components (presentation layer) you think you will get from JSF? If we take HTML as example, I cannot see that you need "more" components. At the end HTML limits us to do this (I'm not talking about JavaScript and Java Applet or other Dynamic HTML from MSIE, just plain HTML). Remember that this is not a Swing UI presentation layer, where you can have rich UI...

    Using JSF as component is different than creating a JSF component, right?

    Regards,
    Lofi.
    Reply to this Reply to original

  16. MDA and JSF[ Go to top ]

    <quote>

    > Based on your explanation, I can't see why JSF couldn't fit on a MDA tool, then. My guess is that it could even create some skeleton code for data entry forms, not just navigation code, but that is just me shooting in the dark.
    > </quote>
    >
    > Sorry if I was not clear enough ;-) Surely JSF fits 100% to MDA tools. Therefore my comment about 100% more productivity for TSS case study with Compuware if they would use JSF ;-) And yes, using tag values in UML, you can generate validation code, navigation code, config files, etc.
    >
    Fine! I will surely take a look at that, looks promising!

    > The big question for me is that what kind of UI components (presentation layer) you think you will get from JSF? If we take HTML as example, I cannot see that you need "more" components. At the end HTML limits us to do this (I'm not talking about JavaScript and Java Applet or other Dynamic HTML from MSIE, just plain HTML). Remember that this is not a Swing UI presentation layer, where you can have rich UI...
    >

    It is not about "more" components, it is about having a different paradigm for web development, where you don't think about HTML tags, but about UI components just like in Swing or VB. You drop a component on a page during design, set some properties for it, add some coding behind it, and its done. At no time you will have to worry about URLs, getting variables from post requests, etc. That will be taken care for you automatically.

    Another thing is that JSF allows for a pluggable renderer, so you could take the same JSF code and generate HTML, WAP, XML, or maybe even Swing UIs automatically, just by changing the rendering engine! Wouldn't it be nice? ;)
    The nice thing about having UI components is reuse: if you create a calendar component for example, you could just drop it in multiple places, or even donate it for my project ;) so I wouldn't need to code it myself, I would just drop it where I needed it... :)

    > Using JSF as component is different than creating a JSF component, right?
    I think I don't get what you mean exaclty, but yes, these are completely different things. You could use JSF as a "interface component" of your system, but that wouldn't mean you would have to create JSF components, you could use the existing ones in the chosen implementation or the ones created by others.

    There's already an Open Source Project for free JSF UI components:
    http://www.ourvision.de/ourfaces/index.html

    Regards,
    Henrique Steckelberg
    Reply to this Reply to original

  17. MDA and JSF[ Go to top ]

    <quote>
    It is not about "more" components, it is about having a different paradigm for web development, where you don't think about HTML tags, but about UI components just like in Swing or VB. You drop a component on a page during design, set some properties for it, add some coding behind it, and its done. At no time you will have to worry about URLs, getting variables from post requests, etc. That will be taken care for you automatically.
    </quote>

    Allright, of course it would be nice to make drag&drop (but be sure to understand the underlying technology and technique first, because in case that your drag&drop environment does not work well, you need to dig into the sourcecode...) ;-) And surely it is nice to see how WSAD plays with JSF in this article:
    http://www-106.ibm.com/developerworks/websphere/techjournal/0402_barcia/0402_barcia.html

    Regards,
    Lofi.
    Reply to this Reply to original

  18. JSF code generation from UML[ Go to top ]

    Lofi,

    if you are interested by MDA solutions to generate JSF code from UML models, just have a look at http://www.mia-software.com/index.php?lang=en&theme=sol-boosters-j2ee-jsf">Mia-Software's JSF Generator</a>.

    It generates forms and actions from a very simple UML model (from any UML modeler) where you just have to describe navigation through actions and views and data hosted by these views.

    In addition, with the same model, you can also generate code for Struts with http://www.mia-software.com/index.php?lang=en&theme=sol-boosters-j2ee-struts">Mia-Software's Struts Generator</a>.

    If the generated code doesn't suit to you, you can change the templates to customize the generator to your own needs.

    Fred
    Reply to this Reply to original

  19. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    Yes, but as I said before, JSF is not tied to JSP, you can create your web pages in JSF using XLST for example, and other solutions will appear too. If you use Smile for example, an Open Source implementation of JSF, you can code your pages in Java, just like when you code Swing UI.

    >

    What license has the RI been released under? Can an opensource implementation borrow from the RI? Is it realistic for an opensource JSF implementation to implement the spec? Will it be able to get access to any test and compatibility kits?

    > OTOH, to expect that a totally new technology would be created out of nothing would be crazy, I guess. Imagine just throwing away all the knowledge and experience regarding Servlet servers, APIs and everything else. JSF is very flexible in this regard, you can adapt it to work on different technologies, not just JSP.
    >

    Not to throw out the KNOWLEDGE we've gained, just the technologies that knowledge have pointed out as overly complex and bloated, such as JSP. Of course, Sun isn't going to build a RI using a non "standard", such as Velocity, Freemarker, etc... A shame, really.

    >
    > Well, I expect that the tools you will need will be very similar to today's Swing or VB-like drag-and-drop editors, which need not be too sophisticated IHMO, nothing different from ASP.Net, for example, and very common in UI developement. And AFAIK, JSF was planned from the beggining to be suported by tools in this manner, being it based on JavaBean UI components.
    >

    I think it's telling that most people I've heard who do real application development (not just toy prototypes or quick one-screen apps) hand code their Swing code, rather than the GUI builders...

    Jason
    Reply to this Reply to original

  20. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    Yes, but as I said before, JSF is not tied to JSP, you can create your web pages in JSF using XLST for example, and other solutions will appear too. If you use Smile for example, an Open Source implementation of JSF, you can code your pages in Java, just like when you code Swing UI.

    > >
    >
    > What license has the RI been released under? Can an opensource implementation borrow from the RI? Is it realistic for an opensource JSF implementation to implement the spec? Will it be able to get access to any test and compatibility kits?
    >

    I don't know about licensing or compatilibity kit (if there is one) details, but about being JSF realistic for OS implementation, given that there's already 2 OS implementations out there even before 1.0 release, I take it as a yes, it is feasible.


    > > OTOH, to expect that a totally new technology would be created out of nothing would be crazy, I guess. Imagine just throwing away all the knowledge and experience regarding Servlet servers, APIs and everything else. JSF is very flexible in this regard, you can adapt it to work on different technologies, not just JSP.
    > >
    >
    > Not to throw out the KNOWLEDGE we've gained, just the technologies that knowledge have pointed out as overly complex and bloated, such as JSP. Of course, Sun isn't going to build a RI using a non "standard", such as Velocity, Freemarker, etc... A shame, really.
    >

    I imagine that even tapestry (or any other component-oriented web framework) may be made JSF compliant, but thats a guess. And again: you don't have to use JSP in JSF, if you don't like it. One more thing: don't expect too much of a RI too, wait for OS or companies to implement more robust and comprehensive _implementations_ of JSF specification.

    > >
    > > Well, I expect that the tools you will need will be very similar to today's Swing or VB-like drag-and-drop editors, which need not be too sophisticated IHMO, nothing different from ASP.Net, for example, and very common in UI developement. And AFAIK, JSF was planned from the beggining to be suported by tools in this manner, being it based on JavaBean UI components.
    > >
    >
    > I think it's telling that most people I've heard who do real application development (not just toy prototypes or quick one-screen apps) hand code their Swing code, rather than the GUI builders...
    >

    Well, you could do that in JSF too if you like (create your UI in code only), using Smile OS JSF, for example. My expectation is that I would be able to use a tool to create a basic UI, and then fine tune it in code, but that is my opinion only.

    Some Links:
    http://www.jsfcentral.com/ (Lots of Resources)
    http://sourceforge.net/projects/myfaces/ (Open Source Implementation of JSF)
    http://smile.sourceforge.net/index.html (Open Source Implementation of JSF)
    http://jakarta.apache.org/struts/proposals/struts-faces.html (Struts-Faces discussion by Struts creator himself)
    http://www.jamesholmes.com/JavaServerFaces/ (More Resources)

    Regards,
    Henrique Steckelberg





    Henrique Steckelberg
    Reply to this Reply to original

  21. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    Well, you could do that in JSF too if you like (create your UI in code only),

    >>using Smile OS JSF, for example. My expectation is that I would be able to
    >>use a tool to create a basic UI, and then fine tune it in code, but that is my opinion only.


    Have you looked at Dynamator ( http://dynamator.sourceforge.net/ )? It may work well for many types of technologies. It looks similar to XMLC/Tapestry in terms of additional markup in the plain html documents, but does transformation in a separate development time step, so the result is as performant as underlying technology ( JSP, JSF, Velocity, PHP, ASP ). In the same time it allows leveraging existing HTML authoring tools like Dreamweaver.
    Reply to this Reply to original

  22. Welcome to the most complex (xxx)ML programming language![ Go to top ]


    > I don't know about licensing or compatilibity kit (if there is one) details, but about being JSF realistic for OS implementation, given that there's already 2 OS implementations out there even before 1.0 release, I take it as a yes, it is feasible.
    >

    Right... and JBoss is an OpenSource J2EE implementation... oh, wait, it's not, legally.
    Reply to this Reply to original

  23. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    Anyway, who can read such a JSP file below (this should be a HTML file?)

    >
    > <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
    > <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
    > <f:loadBundle basename="bundle.Messages" var="Message"/>
    >
    > <HTML>
    >  <HEAD> <title>Input Name Page</title> </HEAD>
    >  <body>
    >   <f:view>
    >     <h1><h:outputText value="#{Message.inputname_header}"/></h1>
    >     <h:messages style="color: blue"/>
    >       <h:form id="helloForm">
    > <h:outputText value="#{Message.prompt}"/>
    > <h:inputText id="userName" value="#{PersonBean.userName}" required="true">
    > <f:validateLength minimum="2" maximum="10"/>
    > </h:inputText>
    >       <h:commandButton id="submit" action="sayhello" value="Say Hello" />
    >      </h:form>
    >  </f:view>
    > </HTML>
    >
    > Nobody can read such a file (and creating them by hand, o gosh...). My

    Really? Looks like a pretty normal jsp page using taglibraries to me.

    Br - J
    Reply to this Reply to original

  24. Exactly the same![ Go to top ]

    <quote>
    Really? Looks like a pretty normal jsp page using taglibraries to me.
    </quote>

    Yep and this is exactly what I want to say. Just the same as JSP with TagLibs ==> horrible ;-) I had a hope that JSF would be a better way than JSP with TagLibs...

    Cheers,
    Lofi.
    Reply to this Reply to original

  25. Is JSF replacement for Struts.[ Go to top ]

    Looking at the exadel's tutorial and I agree with other folks that it is JSP with taglibraries. So whats the real advantage of using JSF ? and for those who are already using struts (<html/>) tag library

    Also, why would one use JSF and struts in same project?
    Reply to this Reply to original

  26. Is JSF replacement for Struts.[ Go to top ]

    Looking at the exadel's tutorial and I agree with other folks that it is JSP with taglibraries. So whats the real advantage of using JSF ? and for those who are already using struts (<html/>) tag library


    JSF focus is on the UI itself, not the backing Java code behind the web pages. And Structs focus is on the backing code, OTOH, not the UI, so actually both technologies are complimentary. Both have some common functionalities, but you have to leverage on each one's strength.

    >
    > Also, why would one use JSF and struts in same project?

    This way, you will be able to leverage upon the tools and UI components for JSF that are expected to to appear on the market soon. These tools are expected to booster your performance for web UI development. If you already have a project using structs, it is easy to convert it to a JSF-structs one, by the way, using the JSF-Struct integration library.
    Reply to this Reply to original

  27. Is JSF replacement for Struts.[ Go to top ]

    This way, you will be able to leverage upon the tools and UI components for

    >JSF that are expected to to appear on the market soon.
    So what if we will add UI components for Struts. Do we still need JSF?
    Even from your words it looks like problem in components, not in the framework.

    Dmitry Namiot
    Coldbeans
    Reply to this Reply to original

  28. Is JSF replacement for Struts.[ Go to top ]

    This way, you will be able to leverage upon the tools and UI components for

    > >JSF that are expected to to appear on the market soon.
    > So what if we will add UI components for Struts. Do we still need JSF?
    > Even from your words it looks like problem in components, not in the framework.

    If you already use struts in an production project, no, you dont need JSF. I was just pointing to some benefits of using it with struts, like expected tool support and complex components (like calendar, date entry fields, data tables, etc.) that could make your development faster. This would be most beneficial for new projects. Existing projects which are mature and don't expect much maintenance wouldn't benefit much (if anything) from adding JSF to structs.

    Henrique Steckelberg
    Reply to this Reply to original

  29. Exactly the same![ Go to top ]

    <quote>

    > Really? Looks like a pretty normal jsp page using taglibraries to me.
    > </quote>
    >
    > Yep and this is exactly what I want to say. Just the same as JSP with TagLibs ==> horrible ;-) I had a hope that JSF would be a better way than JSP with TagLibs...
    >

    So had I, and I am still hoping. The main benefit of JSF is that it has the potential to become so adopted that we get great tool support for it. Lets face it, graphical user interfaces should be designed (and implemented) using visual tools, not text editors. So, what I hope for in JSF is not a easier-to-read source file - it is not to have to read the source file at all.
    Reply to this Reply to original

  30. Welcome to the most complex (xxx)ML programming language![ Go to top ]

    I think it looks like a normal JSP page with taglibs. Actually ASP.NET will be similar (maybe except this part: action="sayhello" &#8211; direct coding for actions). The complexity is in the deployment: web.xml and jsf-config

    But in general I agreed. In the current state JSF can not compete with ASP.NET
    Just adds the complexity without the real advantages

    Dmitry Namiot
    Coldbeans
    Reply to this Reply to original

  31. JCP Releases JavaServer Faces 1.0[ Go to top ]

    After all these years this is what they come up with!? A framework that makes Struts look like a miracle of simplicity.

    It's technologies like this that makes you wonder why not everyone leaves Java for .NET. (think ASP.NET, what JSF should have been like if they had not insisted on building it on top of JSP)

    I love Java. It's simple, elegant and still powerful. But why must so many J2EE technologies be the total anti-thesis of the underlying platform? Complicated, bloated, over-engineered.
    Reply to this Reply to original

  32. JCP Releases JavaServer Faces 1.0[ Go to top ]

    I guess some people round here are missing JSF's point, some clarifications:

    - yes, you will use a tool to draw your web interface in JSF, it was meant to be this way, but if you really want to, you can code it by hand. After some time I was able to deal with the specific JSP coding for the pages, if you have ever done some JSP then it will be a breeze.

    - yes, configure it using xml. How else would you configure it? in Java source code? It is configuration, not code, that is done in the XML files.

    - no, it is not a direct competitor to Structs, they can happly live toguether in the same project, only few areas are overlapping on both technologies, and there is already a library for integrating both.

    - yes, it is simple! Once you get used to its workings, of course, just like most new technology out there. Don't expect it to save world from hunger from night do day though. It will begin to really shine when tools based on the spec starts to appear.

    - no, it is not build on top of JSP. JSP is just one of the possible "interfaces" for JSF, the one used by the RI. You can use XLST if you prefer that. Or you can create you own rendering engine, based on a different technology, or use the ones that will surely be created by open-source or companies.

    Regards,
    Henrique Steckelberg
    Reply to this Reply to original

  33. JCP Releases JavaServer Faces 1.0[ Go to top ]

    I guess some people round here are missing JSF's point, some clarifications:


    As per me the main point I am missing is why do we need JSF?

    Why the rapid UI development could not be done without this? What is wrong in the existing tools? Yes, there are much less components comparing with ASP.NET, but JSF also does not help too much here. And if we will talk about MDA the underlying technology we are using in our code generation is not so important at all

    Maybe it is about plug-ins interoperability? But I this case it is not about end-users (developers)

    >It will begin to really shine when tools based on the spec starts to appear.
    So tools will be shine, not a JSF. It is not about sarcasm, I am really interested

    Dmitry Namiot
    Coldbeans
    Reply to this Reply to original

  34. JCP Releases JavaServer Faces 1.0[ Go to top ]

    I guess some people round here are missing JSF's point, some clarifications:

    >
    > As per me the main point I am missing is why do we need JSF?

    JSF is about the specification, not the RI. The RI is just a proof that the specification can work, it is not a comprehensive, production or market oriented product. But the specification was needed because of the miriad of web frameworks that appears almost daily, and to fight againts ASP.Net competition. JSF will help to lower the fragmentation of the market in this area, where you have 1000's of different solutions to the same problem. I don't expect all the other web frameworks to disappear, but having an "official" specification can surely help us go on a common direction and avoid so much dispersing.

    >
    > Why the rapid UI development could not be done without this? What is wrong in the existing tools? Yes, there are much less components comparing with ASP.NET, but JSF also does not help too much here. And if we will talk about MDA the underlying technology we are using in our code generation is not so important at all
    >

    The JSF RI has just a few components, but as I said before, it is not a product, it is just a proof of concept. Tools vendors and Open Source project will create new components that you will be able to use on any JSF compliant implementation, just like you can do with VB and Swing, for example. I can't see where MDA fits in this picture though, but maybe you are using MDA to autogenerate forms and navigation code.

    > Maybe it is about plug-ins interoperability? But I this case it is not about end-users (developers)
    >
    > >It will begin to really shine when tools based on the spec starts to appear.
    > So tools will be shine, not a JSF. It is not about sarcasm, I am really interested

    The tools are just that, they will help you create your UI much more easily than hand-coding JSP, for example. Having JSF specification behind these tools will enable us to use components downloaded from an Open Source project, or even create our own library of components that fit our specific needs. This will enable the growth of a UI components market too. Using JSF will help enforce the MVC pattern in projects... There are lots of benefits os having an specification like JSF in Java.

    Henrique Steckelberg
    Reply to this Reply to original

  35. JCP Releases JavaServer Faces 1.0[ Go to top ]


    > JSF is about the specification, not the RI. The RI is just a proof that the specification can work, it is not a comprehensive, production or market oriented product. But the specification was needed because of the miriad of web frameworks that appears almost daily, and to fight againts ASP.Net competition. JSF will help to lower the fragmentation of the market in this area, where you have 1000's of different solutions to the same problem. I don't expect all the other web frameworks to disappear, but having an "official" specification can surely help us go on a common direction and avoid so much dispersing.
    >

    So a bloated and over-engineered "Standard" is going to help this how? I don't understand this need Sun has of looking at a space with a lot of mature projects and decide to start from scratch and build something not as good as the currently available options. From what I've seen I'd choose WebWork, Tapesty, or even Struts over JSF.
    Reply to this Reply to original

  36. JCP Releases JavaServer Faces 1.0[ Go to top ]

    So a bloated and over-engineered "Standard" is going to help this how? I don't understand this need Sun has of looking at a space with a lot of mature projects and decide to start from scratch and build something not as good as the currently available options. From what I've seen I'd choose WebWork, Tapesty, or even Struts over JSF.


    Some things here:
    - JSF is a brand new specification, it doesn't have the same maturity as WebWork or Tapestry right now.
    - JSF is not build from scratch, it is based on existing technologies: UI components, Java Beans, Servlets, XML, XLST, etc.
    - I can't see what is so bloated or over-engineered about JSF, it is just as "bloated" and "over-engineered" as any other component-oriented web framework out there.

    Wether JSF is as good as other existing web frameworks, only time will tell. If it ends up not being as good, we will continue using whatever web framework we already use today. OTOH, if it end up proving itself and a community evolves around it, then we will surely see the benefits I have already mentioned before about having this specification instead of none. Right now, it is all speculation. But in my opinion, it will find its place in web development.

    Regards,
    Henrique Steckelberg
    Reply to this Reply to original

  37. overlap with struts?[ Go to top ]

    I've read a few times that JSF and Struts have only minory overlapping points. As does Henrique mention here.

    I fail to see that: Struts provides actions, a way to string them together with pages into a flow, internationalization and webcomponents (Tiles).
    JSF provides the same. (But better designed imo.)

    So what's complementary in Struts that's not offered by JSF?

    groetjes,
    Joost
    Reply to this Reply to original

  38. overlap with struts?[ Go to top ]

    A very nice discussion about Structs-JSF integration:
    http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsMoreAboutJSF

    Answers all the whys and hows of it... ;)

    Regards,
    Henrique Steckelberg
    Reply to this Reply to original

  39. Hurray, Model 2 again[ Go to top ]

    Some things just drive me mad. For example, why a *new* framework is still coming up with the model 2 "architecture" (The JSF Servlet), an architecture that is extremely useful if you want to give away concise urls, bookmarking and above all the J2EE / servlet security model. And all this comes with almost no usable components at all. Since I will probably not be able to mix and match implementations, I will be stuck with a single vendor! Wow, that is some real change! Well done, and back to school!
    Reply to this Reply to original

  40. Macromedia and JSF[ Go to top ]

    I noticed that Macromedia voted "Yes" on the JSF 1.0 specification.

    Is Macromedia planning to build any tools that support JSF 1.0?

    Macromedia has been pushing hard with Flash/Flex/MXML/Remoting/WebServices
    Reply to this Reply to original

  41. Macromedia and JSF[ Go to top ]

    Macromedia will be at my seminar talking on their "JSF".

    baseBeans.com to register ($99)

    .V
    PS:
    Also presenting is Ted Husted (Struts), Matt Raible (Menu and Display tag),
    Rod Johnson (EJB ... or not), Clinton Beign (iBatis), and me, on basicPortal.
    Reply to this Reply to original

  42. JCP Releases JavaServer Faces 1.0[ Go to top ]

    Honestly guys, do you really believe that the "page-oriented, server-compiled" document is the future of the presentation layer? I doubt it...

    Ovi
    Reply to this Reply to original

  43. JCP Releases JavaServer Faces 1.0[ Go to top ]

    do you really believe that the "page-oriented, server-compiled" document


    No!

    I actually just waiting when X-Window server will be standard on clients. I am serious.
    Reply to this Reply to original

  44. JCP Releases JavaServer Faces 1.0[ Go to top ]

    I actually just waiting when X-Window server will be standard on clients. I am serious.


    Here's the first step: http://www.jcraft.com/weirdx/
    Reply to this Reply to original

  45. JCP Releases JavaServer Faces 1.0[ Go to top ]

    Honestly guys, do you really believe that the "page-oriented, server-compiled" document is the future of the presentation layer? I doubt it...

    >

    server-compiled ? is someone still making the server compile their pages ? (*sarc*)

    I remember the time where one would click on each link to discover compilation errors (and not to mention waiting 5+ secs for the page to appear) ... and even think it was normal to do so

    for those people: it's 2004, come out of that hole in the ground and read this:
    http://www.mail-archive.com/andromda-user at lists dot sourceforge dot net/msg00364.html

    advantages:
    1. detect compiler problems during development build processes
    2. no need for the compiler on the server: more secure
    3. pages load instantly: ALWAYS

    to date I have never experienced problems with this approach

    Wouter.
    Reply to this Reply to original

  46. Or just use myeclipseide[ Go to top ]

    It syntax checks and compiles your jsp as you work. So you dont need to
    run it on the server or write an ant script to compile it before deployment.

    --B
    Reply to this Reply to original

  47. JCP Releases JavaServer Faces 1.0[ Go to top ]

    http://www.mail-archive.com/andromda-user at lists dot sourceforge dot net/msg00364.html


    Wouter,

    While your approach is interesting and results in a performance boost, it addresses only the "compiled" part of the "page-oriented, server-compiled" issue. My question is, again: do we really have to present the user one page at a time and fetch it every time (pre-compiled or not) from the server? Or should we start building _real_ GUIs, rich ones?
     
    Ovi
    Reply to this Reply to original

  48. JCP Releases JavaServer Faces 1.0[ Go to top ]

    Wouter,

    >
    > While your approach is interesting and results in a performance boost, it addresses only the "compiled" part of the "page-oriented, server-compiled" issue. My question is, again: do we really have to present the user one page at a time and fetch it every time (pre-compiled or not) from the server? Or should we start building _real_ GUIs, rich ones?
    >

    hi Ovi,

    oh I don't know ... both probably have their respective area in which they are best suited, I don't want to make any remarks on that; I was simply replying on the 'server-compiled' part of your message :-)

    sorry for the confusion

    b-bye
    Wouter.
    Reply to this Reply to original

  49. JSF vs. BarracudaMVC[ Go to top ]

    Check this mail to see the different between JSF and BarracudaMVC:
    http://mail-archive.objectweb.org/barracuda/2003-09/msg00006.html

    Copy&Paste comment from Christian Cryder (project chair Barracuda):
    "My general "gut reactions" to JSR-127 are that its too tied to JSP for my
    taste (I understand why Sun made this decision, but I think it will make it
    very difficult for them to succeed in the long run). In theory JSF is not
    bound to any specific rendering approach, but last time I checked the only
    implementation being supported was via JSPs, so I think I'd agree with
    Dudley's comments...to me, JSF looks like a souped up version of Struts. It
    seems like its taking an awful long time to deliver anything. Its not going
    to be open source when its finally released either (has this changed?). In
    short, I think most of the "problems" I see with Struts still apply to JSF,
    and I'm not at all sure why someone who is already using Struts would go to
    the effort of migrating to JSF (but I'm sure there are folks here who could
    comment on that). Consequently, I don't really see it as competing with
    Barracuda because I think that even though they are using similar verbiage,
    the architectures really are fundamentally different."

    To: Henrique, it seems that JSF is too tight to JSP ;-)

    Cheers,
    Lofi.
    Reply to this Reply to original

  50. JSF vs. BarracudaMVC[ Go to top ]

    Check this mail to see the different between JSF and BarracudaMVC:

    > http://mail-archive.objectweb.org/barracuda/2003-09/msg00006.html
    >
    > Copy&Paste comment from Christian Cryder (project chair Barracuda):
    > "My general "gut reactions" to JSR-127 are that its too tied to JSP for my
    > taste (I understand why Sun made this decision, but I think it will make it
    > very difficult for them to succeed in the long run). In theory JSF is not
    > bound to any specific rendering approach, but last time I checked the only
    > implementation being supported was via JSPs, so I think I'd agree with
    > Dudley's comments...to me, JSF looks like a souped up version of Struts. It
    > seems like its taking an awful long time to deliver anything. Its not going
    > to be open source when its finally released either (has this changed?). In
    > short, I think most of the "problems" I see with Struts still apply to JSF,
    > and I'm not at all sure why someone who is already using Struts would go to
    > the effort of migrating to JSF (but I'm sure there are folks here who could
    > comment on that). Consequently, I don't really see it as competing with
    > Barracuda because I think that even though they are using similar verbiage,
    > the architectures really are fundamentally different."
    >
    > To: Henrique, it seems that JSF is too tight to JSP ;-)
    >
    > Cheers,
    > Lofi.

    Lofi: this discussion seems dated to me:
    - JSF is "open source", I have already given 2 links to open source implementations.
    - the RI already comes with 2 rendering engines, one based on JSP and another based on XLST transformatinons, so this "JSP tie" is not true
    - This is just Cristians' opinion, and being him project leader of a competing technology, what would you expect? ;)

    JSF is not tied to JSP, the RI focused on JSP just because it would be an obvious choice for a proof of concept.

    Henrique Steckelberg
    Reply to this Reply to original

  51. JSF vs. BarracudaMVC[ Go to top ]

    Let me correct myself: the final 1.0 JSF RI doesn't come with a XLST renderer... it comes with a XUL renderer besides the JSP one! ;)

    Regards,
    Henrique Steckelberg
    Reply to this Reply to original

  52. Why I hate BarracudaMVC[ Go to top ]

    I've learned and used BarracudaMVC. Here are what I think about it.

    1. It generates too many objects on top of my application objects and this makes me question it's scaleability in big projects. For example, in BarracudaMVC you declare events in an events.xml file and implement handlers for them in your application gateway. Now, if you declare 200 events, in an ideal case you would want to implement one handler per event. In this case, you may end up with 400 extra objects on top of your application. What I find so annoying is why an object is generated for every event I declare in my events.xml. In fact, this is a framework that I think is over-engineerd.

    2. Learning curve is extremely high. Documents are scattered around the site. Even some links that are provided to working examples fail to work. You get instead exceptions in your browser. Barracuda's examples falls into 2 categories, in my opinion. The first category consits of a set of useless and too simple examples. The second category consists of examples too complex to understand, as a starter, what is really going on. In fact, you can hardly learn how to create real applications from these examples. In between these 2 categories, for the most technologies, you find examples as well. But Barracuda has nothing there. So you waste a lot of time reading bad Javadocs and source code to find out how to achieve what you want done.

    If you're unemployed and have abundance of time to play, then maybe the learning curve wouldn't be problem for you. But if you don't have much time, like most us employed developers, and want to do serious stuff then look somewhere else. You may want to look at Tapestry, well documented and a very well engineerd framework. I work with Struts and have taken a look at Tapestry. I'm now checking JSF too. With all these framworks there are enough well documented examples to get you up running quickly.
    I've dumped BarracudaMVC in my trash can, thus no more hassles:)

    Emmanuel
    Reply to this Reply to original

  53. Actually I think JSF is wonderful[ Go to top ]

    Going through the tutorial that was created for the EA version I found JSF far far better than Struts. Things were more logically organised than Struts and it removed a lot of the Struts junk that made Struts heavy. It was easier to understand page flow by looking at one XML file. It was also easier to create validations on components, setup the model values and define the messaging. One could look at a page and know exactly what it was doing and how. Using anonomous action classes or predefined flows made navigation a breeze. The is no need for Struts Actionforms, the translations between those and your Data Transfer Objects (DTO) are made redundant. Don't get me wrong, Struts was a great framework and save my ass on many a project but it has been superceeded by an even better framework.

    Yes it is more complex than Struts, but not much more and the results will be worth it. Forget about GUI builders for JSF pages, someone once called them Rabid Application Builders - and with good reason. There is no re-use or componentization of code from page to page. Therefore your maintainability and performance suffer immensly, the advantages of Java are just thrown out.

    JSF is the future, spend the time learning it and you will take off - just remember it's not even a thousandth of the complexity of EJB's, so there is nothing to worry about. Keep in mind that I am speaking as someone who will have to teach this framework to other Java developers.

    -Karim
    Reply to this Reply to original

  54. Actually I think JSF is wonderful[ Go to top ]

    There is no re-use or componentization of code from page to page. Therefore

    >your maintainability and performance suffer immensly, the advantages of Java
    >are just thrown out.
    Really? Or "no re-use" is an advantage?

    >Keep in mind that I am speaking as someone who will have to teach this
    >framework to other Java developers.
    I see ...

    Dmitry Namiot
    http://www.servletsuite.com
    Reply to this Reply to original

  55. Actually I think JSF is wonderful[ Go to top ]

    JSF is the future, spend the time learning it and you will take off - just remember it's not even a thousandth of the complexity of EJB's, so there is nothing to worry about. Keep in mind that I am speaking as someone who will have to teach this framework to other Java developers.

    >
    > -Karim

    Isn't the spec like 800 pages long?
    Reply to this Reply to original

  56. Actually I think JSF is wonderful[ Go to top ]

    JSF is the future, spend the time learning it and you will take off - just remember it's not even a thousandth of the complexity of EJB's, so there is nothing to worry about. Keep in mind that I am speaking as someone who will have to teach this framework to other Java developers.

    > >
    > > -Karim
    >
    > Isn't the spec like 800 pages long?

    Hey Jason, what is your problem?
    Reply to this Reply to original

  57. Actually I think JSF is wonderful[ Go to top ]

    The final release version of JSF looks much better than the EA4 release (they finally eliminated some of the warts and naming inconsistencies). Granted, it took me a day to rewrite all my code for v1.0...
    I've used both Struts and JSF and I've got to say that JSF is cleaner and better designed than Struts. I would have expected no less since Craig McClanahan designed both and obviously had the advantage of studying the flaws in Struts before co-designing JSF.
    Hand coding web apps in JSF will remain a tedious endeavor until tools come out to help automate the process. Let's hope they come out soon!
    -Jeff
    Reply to this Reply to original