not enamored by JSF 1.1

[Andy Gibson]

Originally posted by Dave Brown:


Ask yourself first if your really need to use a framework. The only additional 'frameworks' or perhaps tools is a better word in my web apps have been using are hibernate and sometimes spring, displaytag for my tables, and other more specific tools like iText for pdf generation.

The requirement for a framework like Struts/JSF, even spring MVC hasnt become obvious to me yet although part of me is wanting an opportunity to get my teeth into one of the frameworks simply because when I look at the J2EE job market, it seems most high paying financial companies are asking for those skills.

Out of interest, what are you using? JSP & Servlets? I could go back to CGI, but I am trying to find a solution that includes frameworks that makes things easier, more manageable, and make us more productive. In addition, as you noted, it can't help to learn some of those skills.

Regarding this thread, I just read an interesting blog post which is worth reading in light of the fact that so many JSF advocates are suggesting using other frameworks in conjunction with JSF to make up for its shortfalls : JavaServer Faces is the new Servlets.
It talks about the fact that good development frameworks such as Seam are being built upon JSF just as Faces, Struts etc were built on top of servlets.

In light of this, servlets are widely used without thinking of the actual merits of them. I wonder whether JSF will go the same route on the back of Seam and other frameworks built on JSF.

[Gregg Bolinger]

JSF (with Hibernate and Spring or Seam) feels like the right choice given that it is Suns standard

Being a Sun standard doesn't mean anything. JDO was a Sun standard. So is EJB2 and look what a mess that is. Sun did something half right by going with JPA for EJB3. (they should have just let Hibernate fill the role by itself).

What you should be looking at is simply what will be the best tool for the job. Another problem I've seen some shops get into is relying on one single tool for everything. Just because Framework A is good for project 1, it may not be a good fit for Project 2. It would be nice if this were the case, but in my opinion, it doesn't work that way. For example, we are currently developing a module for a company using Stripes. Another module they want built has a flash front end and will require FlashRemoting. Stripes doesn't fill this need. So we will be using something else (probably no framework at all). That's the beauty of choices. You can nearly find a good fit for any project. Can't say that about .NET.

I'm not saying that JSF isn't a good choice for you. It may be. But touting it as a Sun standard is not a good reason to make that decision. Make that decision because architecturally JSF fits with your project(s) needs and solves the problems presented. There are many other things to consider as well, which you seem to have covered somewhat; development time, learning curve, etc.

It also offers the kind of event handling that .net shines in.

JSF isn't the only framework with an event model.

Since most of this discussion has been related to productivity, then surely IDE integration matters also?

So tell me, what IDE is going to support the implementation of JSF you choose? And is that IDE going to fit the needs of the development group? Just pointing out that IDE support isn't necessarily a good reason to choose a framework either. Sure, it can matter, but should it be a deciding factor? I don't think so. Personally, I'm am the most productive with IntelliJ IDEA in any given framework I need to work in. I can't stand D&D generated code. If my IDE supports JEE development, I'm gold. I understand that some people need a bit more hand holding however, and that is their decision. ;)

[Gregg Bolinger]

I wonder whether JSF will go the same route on the back of Seam and other frameworks built on JSF.

God help us if that happens.

[Dave Brown]

Sorry for the cross topic question but from a netbeans user to Greg, One thing I like about netbeans j2ee integration is the (I think its called) Hot deployment.. Once I deploy my app to my chosen app server, I can make a subtle change to a jsp file, save it, refresh my browser and immediately see the change.. Can IDEA do that ? When I had a go with IDEA, admittedly not a long tryout.. I found I kept having to redeploy the entire app. Which can become annoying if i'm making lots of small adjustments to a stylesheet for example...

[Gregg Bolinger]

Originally posted by Dave Brown:
Sorry for the cross topic question but from a netbeans user to Greg, One thing I like about netbeans j2ee integration is the (I think its called) Hot deployment.. Once I deploy my app to my chosen app server, I can make a subtle change to a jsp file, save it, refresh my browser and immediately see the change.. Can IDEA do that ? When I had a go with IDEA, admittedly not a long tryout.. I found I kept having to redeploy the entire app. Which can become annoying if i'm making lots of small adjustments to a stylesheet for example...

Well, that's your fault for relying on the IDEA for deployments. What happens if someone else is not using Netbeans and needs to deploy that app? All my IDEA projects are Java projects at heart. I mean, after all, it's all Java anyway. Just because I didn't set it up as a "Web Module" doesn't mean IDEA doens't understand JSP's anymore.

All my projects are managed via very simple Ant scripts and sometimes Cruise Control added on top of that. I create a context for my webapp that points to where I want it to point to for all my resources. I work in a realistic working "deployed" webapp. When I change a JSP, all I have to do is refresh my browser. When I change a class file, I wait 2 seconds for the server to refresh, and I can refresh my browser. The only time I need to redeploy is if I change a configuration file of somesort that actually requires a restart.

I can go into more detail if you would like. Fill free to contact me outside of the forums or start a new discussion.

[Andy Gibson]

Originally posted by Gregg Bolinger:

Being a Sun standard doesn't mean anything. JDO was a Sun standard. So is EJB2 and look what a mess that is. Sun did something half right by going with JPA for EJB3. (they should have just let Hibernate fill the role by itself).

Agreed, EJB2 was a mess I am glad I missed out on, I'm not assuming that JSF will suddenly be embraced by all because it is a Sun standard, but it does give it an advantage, especially since it is a reasonable solution to the MVC problem.

What you should be looking at is simply what will be the best tool for the job.

Well, in our case, we are not developing software for multiple customers, we are an in-house team working on a single, but modular project.

That's the beauty of choices. You can nearly find a good fit for any project. Can't say that about .NET.

Inversely though, it means having to learn a number of frameworks, and having to find employees that are able to use the same number of frameworks. At least with .net you would either know it or not.

I'm not really a big fan of the 'right tool for the job' philosophy. It has a simplicity that is obvious, and a subtlety that is finicky. Like suggesting that you need to use one type of hammer for nailing 2X4s and another for crown mouldings, or it implies you would try and use said hammer for putting in screws or drilling holes. I'd rather become really familiar with one drill and use it for a variety of holes rather than use a different drill for each type of hole.

I'm not saying that JSF isn't a good choice for you. It may be. But touting it as a Sun standard is not a good reason to make that decision. Make that decision because architecturally JSF fits with your project(s) needs and solves the problems presented.

On that basis pretty much any framework (struts, spring MVC, JSF, stripes etc) can be used since they are all solving the problem in the same ways. In most cases, the problems are the same: add object, list objects, edit objects & save objects. The differences in frameworks arise in their solutions to the problems which are present regardless of the type of application (i.e. state management, bookmarked links, templating and the back button, browser compatibility etc.).

So tell me, what IDE is going to support the implementation of JSF you choose? And is that IDE going to fit the needs of the development group? Just pointing out that IDE support isn't necessarily a good reason to choose a framework either. Sure, it can matter, but should it be a deciding factor? I don't think so. Personally, I'm am the most productive with IntelliJ IDEA in any given framework I need to work in. I can't stand D&D generated code. If my IDE supports JEE development, I'm gold. I understand that some people need a bit more hand holding however, and that is their decision.

Personally, I'm enjoying writing my JSF by hand. I too dislike any web front end that is D&D generated, including visual studio or just regular old HTML editors. However, what I did like was coding my web front end by hand, then flipping to a visual representation which gives me an idea of whether it looks right, then selecting a component here and there, and letting the IDE help me add event handlers and I just fill in the code. It was a time saver, especially as I didn't know how to add event handlers in .net at the time ;-)
To date, I don't think I've seen any broad Java IDE support for web design. Netbeans has a Visual Designer, but it relies on the rave components and that your beans have a particular superclass. It's not like you can just open up a JSF page and go to town on it. Plus, not sure how things will work out if you want to use templating with it.

On a related note, here is a case where choice doesn't give you the advantage. I don't see the Java IDE teams writing GUI editors for every new presentation layer that comes along. This is possibly another advantage for being a standard. OTOH, ASP.net, being the only choice means that IDEs only need to concern themselves with ASP.net markup in the web pages. Not only can the designer present the user with the default controls, but it can also handle custom controls that have been installed.

Reagrding IDEs, I'd be perfectly happy with an editor with code auto completion and the ability to easily call targets from my Ant script and a file browser. I like to write my code from the ground up so I know I understand what is in there, instead of using New Project wizards or Appfuse. This is especially important to me right now as I'm starting out on this stuff, but it does make it a bugger to work with in an editor.

[Andy Gibson]

Originally posted by Gregg Bolinger:


All my projects are managed via very simple Ant scripts and sometimes Cruise Control added on top of that. I create a context for my webapp that points to where I want it to point to for all my resources. I work in a realistic working "deployed" webapp.

<snip>

I can go into more detail if you would like. Fill free to contact me outside of the forums or start a new discussion.

I tried to set this up in my ant scripts as I liked the hot deploy in netbeans. What server are you using (for development) and how did you get that web server to point to a directory to use it as a deployed application. Is it some kind of commonly known activity that has a name that I can look up?

Cheers,

Andy

[Fabio Kung]

Great topic!

I guess the problem isn't on JSF itself, but on renderers. The JSF engine is great and VERY flexible, but I haven't seen any renderers producing good xhtml (and semantic) code!

If we must lose some control over the GUI code (html) in flavor of component based views, the generated code should be at least standards compliant...

To build component based web apps, today I would go with JSF 1.2 + Facelets, otherwise I'd rather www.vraptor.org

It is very simple, follows strong conventions over configurations and includes some nice ideas from seam and stripes.
[ January 14, 2007: Message edited by: Fabio Kung ]