• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

To Hans: When to use JSF?

 
Ranch Hand
Posts: 937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In your book you are mentioning use JSF , if the site is highly user interactive and for a basic dynamic web app there is no need to use JSF?

Can you please elaborate that?


 
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by sunitha raghu:
In your book you are mentioning use JSF , if the site is highly user interactive and for a basic dynamic web app there is no need to use JSF?

Can you please elaborate that?




I'll try. JSF is an event-driven, component-based UI framework, which provides a model similar to the model used for many GUI development kits, such as Swing. This makes it easier to develop complex user interfaces than it is with template-based technologies like JSP and Velocity, but it comes at a price.

For instance, if the main dynamic part of your application is a table showing (read only) a list of products in a selected category, you can develop it with a simple JSP page, using the JSTL SQL tag library and a JSTL <c:forEach> tag. It takes five minutes if you're familar with JSP and JSTL, and you don't have to write a single line of Java code.

With JSF, you can do pretty much the same (just replace the <c:forEach> with <h ataTable> , but you have to learn a new framework (and no, JSF isn't just JSP with a new set of tag libraries). If you use something like Tiles or SiteMesh for a common page layout, you may be in for a surprise when you add JSF with JSP to the mix (I have an article in the pipeline that describes the problems with using JSP for JSF in more detail, so let's leave it at that for now). To really take advantage of JSF, though, you should also develop at least one bean that handles the database access instead of putting that type of logic in a JSP page.

The point is that if things are simple, don't make them complex by using a technology that's overkill; don't kill a fly with an air missile! If you don't gain anything by using JSF (and you don't for a simple read-only focused web application), don't!
 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hank,

If what you are explaning related to complexity that comes with JSF is the case, what exactly is the value proposition of JSF.

Why we need JSF when we can accomplish many aspects using JSP, JSTL, Struts/Tapestry etc.

By the way can you elaborate on if JSF and Tapestry can work together?
 
sunitha reghu
Ranch Hand
Posts: 937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hans,
If someone is very good in coding java and do have a good speed in developing a web app using jsp/beans/sevlets why that person have to use JSF. There is a learning curve in using JSF. I am very confused here
How JSF going to help the productivity?
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll try to answer both questions here.

JSF is great for complex user interfaces, i.e., for web applications that look and feel as much as a GUI app as possible. For such an application, JSF boost productivity and reduces complexity.

As a concrete example, say you need an editable table, where the user can change the values of a number of cells and submit them all at once. The values need to be validated, the table must be sortable and scrollable. Doing this with JSF is fairly simple (I show an example in the book), but doing it with plain JSP and/or servlets is pretty complex an messy. For this kind of interface, JSF is a better choice than plain JSP.

Because JSF components handle both input and output, they are also a lot easier to reuse between applications than, say, a JSP tag library (which just generates output). It's therefore likely that you'll soon see many custom components enter the market, both open source and commercial libraries.

But not all applications have complex user interfaces, and for a simple application, the benefits of using JSF may not be enough to offset the learning curve. JSF is great for complex user interfaces, but probably overkill for a lot of simple interfaces; don't use it just because it exists, use it because you have a problem to solve that matches the JSF feature set.

I'm trying to avoid the same situation we had a few years ago when people were using EJB for simple applications were it clearly was overkill, giving EJB a bad rap because the extra complexity wasn't warranted for the simple applications. Complex problems requires a more complex solution, so make sure you don't use a complex solution to solve a simple problem.
 
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

As a concrete example, say you need an editable table, where the user can change the values of a number of cells and submit them all at once. The values need to be validated, the table must be sortable and scrollable. Doing this with JSF is fairly simple (I show an example in the book), but doing it with plain JSP and/or servlets is pretty complex an messy. For this kind of interface, JSF is a better choice than plain JSP.



please correct me if i am wrong: After a user event on the component, only the component will be updated. Does it make a connection to the server ?
Say two dropdowns (classic web issue, if you do not want to work with flavours of javascript) One dropdown depends on the selection in the other dropdown. If you select something in the first dropdown, only the second dropdown will refresh itself (going back to the server, i assume ?)
Or am i too far off ?
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by bas duijzings:


please correct me if i am wrong: After a user event on the component, only the component will be updated. Does it make a connection to the server ?
Say two dropdowns (classic web issue, if you do not want to work with flavours of javascript) One dropdown depends on the selection in the other dropdown. If you select something in the first dropdown, only the second dropdown will refresh itself (going back to the server, i assume ?)
Or am i too far off ?



JSF is server-side technology; all code using the JSF API executes on the server.

That said, JSF components can add client-side code to the response, for instance code that updates one selection list based on the selection in another. None of the standard components defined by the specification generates client-side code, but it will likely be common for custom components to do so.

Without client-side code, you need to go back to the server to change the content of the second list. One way to implement this is with a ValueChangeEvent listener attached to the first list, which is invoked the next time the form is submitted (possibly by a simple "onchange" client-side event handler for the first selection list). I show an example of this in the book.
 
bas duijzings
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just hoped you could do without the client side code, so i guess you cant.
Just a shame, since there are projects where you are not allowed to use client side code for things other then simple presentation (like image swapping) Businesslike issues in client side code, like managing a flow, or a submit, is often not allowed.
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by bas duijzings:
I just hoped you could do without the client side code, so i guess you cant.
Just a shame, since there are projects where you are not allowed to use client side code for things other then simple presentation (like image swapping) Businesslike issues in client side code, like managing a flow, or a submit, is often not allowed.



Can you be more elaborate on this. Why there is no client side code allowed in that project etc??
 
bas duijzings
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
like i said kishore, i worked on a couple of projects where you were not allowed to use javascript because of differences in netscape and internet explorer. This was back in the days when netscape was still an important player, and we did not have a near monopoly from microsoft. (i know there are others) The javascript and the dom models are different and therefore development and maintenance will cost lots more. The only javascript allowed was image swaps on mouseovers, but nothing fancy like building up multiple arrays in javascript for use in dropdowns, or keeping a shopping basket.

On the other hand (a bank in this case) they were worried about the site not functioning when someone switched off javascript support (stop laughing, those people do exist).

regards,
 
sunitha reghu
Ranch Hand
Posts: 937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To use or not to use Javascript depends on which scenario we need to use. For example a validation should be done on server side because user can always turn off. But to increase the usability of the site like auto tabbing
we can always use JS.
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by sunitha raghu:
To use or not to use Javascript depends on which scenario we need to use. For example a validation should be done on server side because user can always turn off. But to increase the usability of the site like auto tabbing
we can always use JS.



May be with JSF, there will be no need to use JavaScripy anymore. Just a guess from my side.
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kishore Dandu:


May be with JSF, there will be no need to use JavaScripy anymore. Just a guess from my side.



JSF has no impact whatsoever on whether to use JavaScript or not. See this thread.
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hans Bergsten:
I'll try to answer both questions here.

JSF is great for complex user interfaces, i.e., for web applications that look and feel as much as a GUI app as possible. For such an application, JSF boost productivity and reduces complexity.
<< snip >>
.



We are developing a suite of web applications and using JSF (and JDO) to do it, even though the initial site we are doing is a full migration from Struts (and Hibernate). We went through a serious learnign curve and still are crawling - the site would have been sone a week ago if we used the old code but we were given the green light to migrate and it's been awesome. the amount of actual code you need to write is much less with JSF than struts, but there are some limitations we have not puzzled over enough yet. the mixing of JSF and tiles is a challenge and there is too mcuh of this ugly <f:verbatim> stuff in the final JSP, but perhaps we are approaching it wrong.

still we are happy to have made the leap and feel that we have built a good baseline for a best - practice web app.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm thinking about developing a site that is similar to Slashdot or Kuro5hin in Java. I'm beginning to start evaluating frameworks to use in its creation. Is this the sort of project that you would recommend for JSF? Or would Struts be better for that sort of thing?

Also, you said that the JSF API is server side. However, it is an event driven framework. It'd seem to me that most events are user triggered. How does the page communicate the user events back to JSF on the server? Is it through simple links that are pre-written by JSF (as a result of JSF API programming), form submission, or some other method that I can't think of?
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mike Brewer:
I'm thinking about developing a site that is similar to Slashdot or Kuro5hin in Java. I'm beginning to start evaluating frameworks to use in its creation. Is this the sort of project that you would recommend for JSF? Or would Struts be better for that sort of thing?

Also, you said that the JSF API is server side. However, it is an event driven framework. It'd seem to me that most events are user triggered. How does the page communicate the user events back to JSF on the server? Is it through simple links that are pre-written by JSF (as a result of JSF API programming), form submission, or some other method that I can't think of?



I don't think a Slashdot-like site is the ideal candidate for JSF; the user interface is mostly dynamic output and very little input, far from something that looks like a traditional GUI. It may be easier to develop with plain JSP, with something like Struts or Maverick for the request processing. A site like http://travelocity.com/, where the user can enter dates in different ways, tables the user makes selections from, etc., is a better candidate for JSF.

Regarding the JSF event model, the JSF events fire when the form is submitted, either as a result of clicking a link produced by JSF, clicking a submit button in a form produced by JSF, or through a JavaScript event handler (e.g., an "onchange" event handler for a selection list). This is the same as for all other event-driven server-side technologies, such as XMLC/Barracuda and Tapestry.
 
author
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The power of JSF is RAD development. Vendors such as WebSphere Studio provide an environment to quickly assemble pages: My article series shows the potential of JSF:

http://www-106.ibm.com/developerworks/websphere/techjournal/0401_barcia/barcia.html


Other technologies, such as SDO (Service Data Objects) will compliment JSF.

By hand, JSF is probably harder than other frameworks like Struts.
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Roland Barcia:
The power of JSF is RAD development. Vendors such as WebSphere Studio provide an environment to quickly assemble pages.



True, that's an important aspect I've ignored in this thread (because I tend to not use RAD tools myself).

JSF is designed to make it easy to combine with RAD tools for web application development. If your team is into using these kinds of tools, the extra complexity I've been talking about may be less of an issue (depending on how good the tool is, of course) and may therefore make even applications with fairly simple user interfaces good candidates for JSF.

My earlier comments should be seen in the context of using just standard text editors and/or general purpose Java IDEs.
 
Ranch Hand
Posts: 834
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi, hans ,

can i assume jsf as web based java foundation class(jfc) ? as i know jsf is kind of UI framework with event-driven (correct me if i'm wrong).

1) what are the user interface components involved in jsf ?

2) is there any java ide provide support on jsf so far ?

3) any website we can have a look which compliment with jsf
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Originally posted by Alvin chew:
hi, hans ,

can i assume jsf as web based java foundation class(jfc) ? as i know jsf is kind of UI framework with event-driven (correct me if i'm wrong).

JSF is similar to JFC/Swing. The differences are primarily to deal with the fact that with JSF, the widgets are displayed in a client (e.g., a browser) that uses a request/response protocol (e.g., HTTP) to the process where the components live, while Swing only need to deal with one process holding everything.


1) what are the user interface components involved in jsf ?


Pretty much a one-to-one mapping to the HTML form elements, plus a few extras such an editable table and layout components.


2) is there any java ide provide support on jsf so far ?


I don't think any JSF RAD tools are released yet, but all major j2EE vendors (IBM, Sun, BEA, Macromedia, Oracle, etc.) are working on such tools and some are available as early access.

3) any website we can have a look which compliment with jsf[/QB]

The main site for JSF is http://java.sun.com/j2ee/javaserverfaces.
 
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JSF, Intended Audience and Network Support
Seems to me tht JSF is also better suited to situations where you know your applications users are working through a fast connection due to the frequent albeit, I hope, terse messages that are sent to the server with the firing of each event. An intranet application requiring a complex, interactive interface where you have more control over who connects and through what network would provide the benefits of easy administration afforded by a thin client app, but allow for a richer, more interactive experience.

State Management
State management (...within a user's session) must be critical in the JSF framework, can you point me to an article or provide an overview on how state management is structeured, the life cycle etc. Also related to this would be discussing how this impacts scalability and the ability to load balance.

Push vs Pull
Is there anything in JSF currently, or in the works for future versions to provide some push capability so that the server can reach out and touch the client to initiate some event. My guess is no, because doing so is a grand departure from how browsers work today in that every browser would need the ability to listen for incoming messages instead of the more primitive method of having something on the page that polls the server and only creating the illusion of a push capability.
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Originally posted by Byron Estes:
JSF, Intended Audience and Network Support
Seems to me tht JSF is also better suited to situations where you know your applications users are working through a fast connection due to the frequent albeit, I hope, terse messages that are sent to the server with the firing of each event. An intranet application requiring a complex, interactive interface where you have more control over who connects and through what network would provide the benefits of easy administration afforded by a thin client app, but allow for a richer, more interactive experience.

Maybe, but for some applications and/or with JSF components that also use JavaScript, server accesses may not be such a big issue.


State Management
State management (...within a user's session) must be critical in the JSF framework, can you point me to an article or provide an overview on how state management is structeured, the life cycle etc. Also related to this would be discussing how this impacts scalability and the ability to load balance.

I describe the basics for JSF component state managing in my book, and am sure other books will as well. There's also the spec itself. I haven't seen any articles about this yet, though.

Basically, JSF can save the component state either on the server (in the session) or in the client (embedded in the response as hidden fields). Unless the state is huge, client state saving has some advantages, such as minimizing the session size and making load balancing easier (assuming you don't use the session for application data, which you typically do).

For application data, the same rules as for any server technology apply: only store what you absolutely have to in the session.

Push vs Pull
Is there anything in JSF currently, or in the works for future versions to provide some push capability so that the server can reach out and touch the client to initiate some event. My guess is no, because doing so is a grand departure from how browsers work today in that every browser would need the ability to listen for incoming messages instead of the more primitive method of having something on the page that polls the server and only creating the illusion of a push capability.

I don't expect any push capability to be added for the reasons you describe.
 
Ranch Hand
Posts: 130
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hans,

I'm currently developing some jsp pages which do their best to mimic an editable table where users get a number of results from database and then update them. This is similar to what you mention below.

But I'm wondering if you can give any idea as to just how steep the learning curve is on learning enough of JSF to get a working application. I know this is pretty subjective and that there are members of varying abilities and experience. I'm someone who's done a few projects with jsp and servlets but have never looked at Struts or any other framework. Though I'm in a department of 10-15 I'll be the only one doing any work on this most likely. In your estimation do you think JSF if something that someone working on their own and balancing other non-Java projects could pick up in a month or so?

Thanks for your thoughts,

Ken


JSF is great for complex user interfaces, i.e., for web applications that look and feel as much as a GUI app as possible. For such an application, JSF boost productivity and reduces complexity.

As a concrete example, say you need an editable table, where the user can change the values of a number of cells and submit them all at once. The values need to be validated, the table must be sortable and scrollable. Doing this with JSF is fairly simple (I show an example in the book), but doing it with plain JSP and/or servlets is pretty complex an messy. For this kind of interface, JSF is a better choice than plain JSP.

 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ken Januski:
Hans,

I'm currently developing some jsp pages which do their best to mimic an editable table where users get a number of results from database and then update them. This is similar to what you mention below.

But I'm wondering if you can give any idea as to just how steep the learning curve is on learning enough of JSF to get a working application. I know this is pretty subjective and that there are members of varying abilities and experience. I'm someone who's done a few projects with jsp and servlets but have never looked at Struts or any other framework. Though I'm in a department of 10-15 I'll be the only one doing any work on this most likely. In your estimation do you think JSF if something that someone working on their own and balancing other non-Java projects could pick up in a month or so?

Thanks for your thoughts,

Ken



As you said, it depends on a lot of factors, but with your background, you should be able to learn the JSF basics fairly quickly; a month of reading and playing around with some prototypes in between other assignments sounds reasonable to me.
 
slicker
Posts: 1108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Might be dumb question, but how easy is it to use JSF, if I just have pages of data from a db with links to other pages. Not too much user interface for now, but that may change. Can I do use jsf here, so that if more user activities develops I don't have to throw away jsp and replace??
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by John Dunn:
Might be dumb question, but how easy is it to use JSF, if I just have pages of data from a db with links to other pages. Not too much user interface for now, but that may change. Can I do use jsf here, so that if more user activities develops I don't have to throw away jsp and replace??



Sure you can, but if it's a good idea depends on a number of factors.

For instance, if you already know how to do it with plain JSP and want to do it fast, doing it with JSF will likely take longer (the learning curve). If that's the case, you may want to do it with JSP first and migrate to JSF when needed instead.

On the other hand, if you're not in a rush to get it done and you already know that the user interface will eventually be more complex, JSF may be a good choice even for the first version (a way to learn).

There's no "right" answer here. All I've tried to do in this thread is to say that "hey, JSF may be overkill for some applications, so don't use it just because it exists, use it because it helps you solve a problem." I may have focused too much on this, but I've seen so many times how some technologies are overused just because they are "cool" or are seen as silver bullets (e.g., XML and EJB instead of simple properties files and plain Java/JDBC/JDO). There are no silver bullets and one size doesn't fit all, so pick the tools/technologies that let you develop your application with the least amount of work and complexity.
 
Your mind is under my control .... your will is now mine .... read this tiny ad
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic