Home

News: JSF-Spring integration library released

  1. JSF-Spring integration library released (13 messages)

    JSF-Spring provides glue code for comprehensive integration of JSF (JavaServer Faces) and the Spring framework. This is done in a implementation independent way so that it can be used with any JSF implementation.

    Features
    From version 1.1 on, Spring features basic JSF support as well. Here are the differences between both approaches.

    Spring: link between JSF and Spring

    Spring includes a JSF VariableResolver implementation that is aware of Spring-managed beans and thus gives access to those beans by referring to their bean name in JSF expressions. So what it basically does is providing JSF with a link to Spring beans. This solution will be sufficient in many cases.

    JSF-Spring: integration of both frameworks

    JSF-Spring provides Spring with a WebApplicationContext containing JSF's managed-beans and integrates it into Spring's context hierarchy. Thus it makes Spring beans available to JSF beans and integrates JSF beans into Spring, providing a more comprehensive (bidirectional) integration, including the ability to use Spring's features within JSF beans. Furthermore, you are able to scope Spring beans in the same way you can scope JSF beans, giving you the additional session and request scopes.


    Visit the home page of JSF-Spring

    Threaded Messages (13)

  2. What people are saying about jsf[ Go to top ]

    If you have used Tapestry, it is painful to look at JavaServer Faces applications.
    http://www.almaer.com/blog/archives/000414.html

    Do not let it thrive or prosper. We don't want it improved or tweaked, we want it to die the horrible painful death it so richly deserves.
    http://www.jroller.com/page/fate

    Whatever you do, don't use JSF
    http://raibledesigns.com/page/rd?anchor=my_jsf_experience
  3. Wasted negative energy[ Go to top ]

    Such negativity over JSF is interesting. If JSF is really as bad as people believe and will never amount to a useful framework then it will eventually die on it's own. If it turns out that JSF is not completely useless then that would mean it holds some value. There is no need to destroy every daisy you see just because you personally like Roses more. Use and improve what you like and leave those who believe differenly alone unless you wish to provide constructive input.

    Mike
  4. I would like to report my own personal experience with JSF. I work within a large multinational and we are planning to use JSF for production level products.
    Frankly speaking, I strongly disagree with the fact that it deserves such a painful death. We developed a rich component set, we implemented a à-la-Tapestry tiling model, I got Swing developers to work with JSF in a snap.

    Being so flaming does not help. Let it be developed, let it be tweaked. We simple want to choose. You have made your already, or so it seems. If we will find JSF useful we will use it.
  5. Frankly speaking, I strongly disagree with the fact that it deserves such a painful death. We developed a rich component set, we implemented a à-la-Tapestry tiling model, I got Swing developers to work with JSF in a snap.
    i'm surprised of all these negative comments on JSF, too. i'm using it succesfully in current project. it helped in creating set of reusable components and it makes our gui completely html-free and easy managable. i think the only serious drawback of jsf is poor performance, as yet.
  6. What people are saying about jsf[ Go to top ]

    it makes our gui completely html-free and easy managable.
    Thats really funny :)...
    Ur GUI is free of HTML and ur Java code contains HTML...
    Is that what u shud be happy about....
    Ur GUI must be HTML, only then can a web designer have total freedom to easily tweak it.
  7. What people are saying about jsf[ Go to top ]

    it makes our gui completely html-free and easy managable.
    Thats really funny :)...Ur GUI is free of HTML and ur Java code contains HTML...Is that what u shud be happy about....Ur GUI must be HTML, only then can a web designer have total freedom to easily tweak it.
    In many (most?) business web applications there's no real need for web designer. no need for html, too.
  8. What people are saying about jsf[ Go to top ]

    In many (most?) business web applications there's no real need for web designer. no need for html, too.
    I have indeed seen projects where java developers take care of the UI and I know how well it turns out :)) U know, there is a big differece in getting a job done and getting a job done right. Turns out that JSF will get the job done, but I think it will be a recipe for not getting it done right.
    BTW what are these many(most) business web applications with no html.
    Also BTW many/most JSF components spit out HTML.
  9. What people are saying about jsf[ Go to top ]

    In many (most?) business web applications there's no real need for web designer. no need for html, too.
    I have indeed seen projects where java developers take care of the UI and I know how well it turns out :)) U know, there is a big differece in getting a job done and getting a job done right. Turns out that JSF will get the job done, but I think it will be a recipe for not getting it done right. BTW what are these many(most) business web applications with no html.Also BTW many/most JSF components spit out HTML.
    I meant no html in application code. Of course in library (JSF) it's present. And i still don't see here any need for web designer in application development.
  10. What people are saying about jsf[ Go to top ]

    I meant no html in application code. Of course in library (JSF) it's present.
    And yes, I am talking abt the html in the JSF component. Lets say u r building a JSF component. You would end up writing HTML for the JSF component in a custom tag class which is java code. Couple of days later, you decide to change some layout stuff for this component, u go and modify java code to do that. Esentially, u r controlling presentation related stuff thru java. And I wud want presentation to be controlled by a web designer. And here, he lacks total freedom. He would have to take the help of a java guy to modify the tag class. As opposed to Tapestry, where a component is an HTML template and not a java class.
  11. What people are saying about jsf[ Go to top ]

    I meant no html in application code. Of course in library (JSF) it's present.
    And yes, I am talking abt the html in the JSF component. Lets say u r building a JSF component. You would end up writing HTML for the JSF component in a custom tag class which is java code. Couple of days later, you decide to change some layout stuff for this component, u go and modify java code to do that. Esentially, u r controlling presentation related stuff thru java. And I wud want presentation to be controlled by a web designer. And here, he lacks total freedom. He would have to take the help of a java guy to modify the tag class. As opposed to Tapestry, where a component is an HTML template and not a java class.
    I'd like to point out that with JSF (just like custom JSP tags) you can hard code your look and feel into your components if you were sloppy enough to do so, but realistically you would want to make your component's visual appearance easily changeable outside of writing Java code through CSS or other means. (such as adding a parm bgcolor=""..)

    Take Visual Studio as an example, I can drop a Gridview/Datagrid control onto a page and without touching a single line of code I can alter the appearance of the control to match my overall Web app design..

    This is what I see as the goal for JSF to be and I can see some initial progress in that direction. For example Oracle's upcoming JSF component library based on it's original UIX Web presentation framework follows a somewhat similar usage in that you can drop one of it's Table components onto your canvas and then change it's look and feel with stylesheets without having to get into the Java code of the component itself..

    -Chris
  12. Two very different styles of page authoring are being described here.

    The classic style is HTML-centric: a web designer builds up HTML pages, then hands those pages to application developers. Depending on the framework, the developer either sprinkles logic into the HTML page (bad), or relies on framework features to put the logic in a separate file (better). Tapestry does a fine job with this style.

    An alternate style is component-centric: reusable components generate HTML, and are assembled by application developers into pages. JSF enables this style - though as yet, imperfectly (more on that below).

    Assertions that one style is "right" and the other style is "wrong" are ridiculous and narrow-minded. They're both applicable in different (and overlapping) circumstances, and I find the fierce proclamations of some partisans that their style is the one-and-only way rather puerile.

    HTML-centric development is ideal for many web applications today; it's a well understood model, it offers complete flexibility of HTML output, it's easy to hire web designers, etc.

    But, in my opinion, this architecture does not have legs. (And by "this architecture", I'm explicitly not referring to Tapestry here, but to HTML-centric development.) Raw HTML will only take you so far. The larger your application, the more you'll want to encapsulate reusable blocks of HTML. The more complex your HTML gets, the more you're going to want to break out of the forced association of raw HTML with server-side processing. Think bigger - think DHTML, mixed with XMLHTTP requests, aggregated into complex client-side components. Or SVG. Or the next client-side component technology to arrive. These sorts of scenarios are where component-centric development begins to shine. HTML-centric development is holding us back.

    An oft-heard rebuttal is "how can you expect web designers to build pages with anything other than HTML"? I find that insulting to web designers - in my experience, give them a good set of output components that don't require Java code, they learn to assemble them into pages quickly. After all, they had to learn HTML, and HTML+CSS+Javascript is *not* the easiest thing to learn.

    I said above that JSF only imperfectly enables component-centric development. Some of what JSF needs to enable this include:
     - A much wider set of components, including high-level layout components. Today, JSF is essentially still in an "HTML with some components sprinkled in" place.
     - A much easier way to write custom renderers, preferably without code, so web designers can create custom appearances with relative ease.

    -- Adam Winer (JSF EG member)
  13. ADF JSF license...[ Go to top ]

    "We grant you a nonexclusive, nontransferable limited license to use the programs only for the purpose of developing a single prototype of your application"

    This makes me very suspicious of your intentions towards JSF.
  14. This negativity is not wasted...[ Go to top ]

    It's actually smart skepticism based on what Sun's JSRs have traditionally produced. EJB is such a mess and really only being used effectively on a small number (relatively) of projects. JSF has all the same symptoms; As Bruce Tate pointed out in "Better, Faster, Lighter Java", JSF is vendor implemented and controlled by a small committee of people -- a recipe for disaster.

    JSF's best chance at being a good framework is the opensource world. Perhaps when Struts 2.0 becomes a reality.