The new release of WebCharts3D now fully support JavaServer Faces specifications.
 
You can easily drag and drop charts into the page in any JSF visual editor, edit chart's styles in WYSIWUG mode, define server-side action, modify the chart's styles and model using object model, and bind its attributes to managed beans' properties.

View WebCharts.

fyi
The link http://www.gpoint.com/WebCharts50/ in this message gives a "403 Forbidden" status response.
Jan

I've been playing around with
Cewolf and
JFreeChart for a while. They work very nicely in web applications,and are very easy to set up. Probably not as fully-featured as this, but a great open-source alternative.

Mike

Agreed
I've used them with WebSphere and they worked well.

I'm excited to see other companies jumping on board with JSF. I'm sure the other charting tools are just as good, but to have something that drops right into any JSF application is golden.

I'm excited to see other companies jumping on board with JSF. I'm sure the other charting tools are just as good, but to have something that drops right into any JSF application is golden.

Companies readily support everything that makes sales no matter if that makes sense or not.
IMO JSF seems like square peg in a round hole: it is not that object oriented as Echo or WebOnSwing and not as markup component oriented as Tapestry.

Companies readily support everything that makes sales no matter if that makes sense or not. IMO JSF seems like square peg in a round hole: it is not that object oriented as Echo or WebOnSwing and not as markup component oriented as Tapestry.

I believe the underlying point is that lots of companies have a single "framework" to work with in plugging their products. Say good or bad at this point, the congruence helps.

The comment about JSF not being as object oriented, I would be interested in reading the reasons behind that statement. The articles I've read about Echo seem very similar to JSF; except JSF allows both programatically defining the view and configuring the view in a JSP *or* external XML file like Tapestry. I'm sure you are referencing the Hans Bergsten article at OnJava.com-- and the new JSF/JSP specs fix the "horse and cart" issues Hans mentions.

Jacob Hookom (JSR-252 EG)

The comment about JSF not being as object oriented, I would be interested in reading the reasons behind that statement.

Well, ‘not object oriented’ is not appropriate term, I am trying to say that JSF does not provide enough separation between layers and responsibilities. It feels messy IMO.
Velocity – clear template/page oriented approach, it is pretty obvious who does what where;
Swing – clearly programmatic layout, easily externalizable into peer class as a script, xml, or java code. LnF package is responsible for consistent view.
Tapestry – clearly separates designers and developers, clearly allows presentation technology specific and reusable components (html, wap, etc);

Yes, JSF in its core seems fine, but in the conjunction with JSP and pretty weird relationships between JSP tag/taglibs and JSF ones… is feel messy. I kind of see good pieces in JSF here and there but overall it looks inconsistent, overly complicated, and past oriented (html).

Just my 2c

Yes, JSF in its core seems fine, but in the conjunction with JSP and pretty weird relationships between JSP tag/taglibs and JSF ones… is feel messy. I kind of see good pieces in JSF here and there but overall it looks inconsistent, overly complicated, and past oriented (html).

Those are all valid comments, and the new spec (1.2) was written in order to fix the aforementioned issues.

I'm working on a project right now that does B2B medical sales, but we had a requirement to also allow other businesses to give the pages their own treatment. The solution? CSS. Same JSPs for everyone, same generated HTML, just different CSS stylesheets. I think CSS is one of the most underestimated technologies out there right now. JSF relies on CSS to take care of the "view seperation" you mention.

Best CSS example on the net: http://www.csszengarden.com.

Along the lines of XHTML vs. WAP, etc-- JSF uses renderkits to take care of that issue. The problem is that there hasn't been much interest in other renderkits at this point other than XHTML.

The solution? CSS. Same JSPs for everyone, same generated HTML, just different CSS stylesheets. I think CSS is one of the most underestimated technologies out there right now. JSF relies on CSS to take care of the "view seperation" you mention.Best CSS example on the net: http://www.csszengarden.com

I wish all user browsers support CSS equally... But even they do it is not enough. UI should allow simple and clear programmatic manipulation: hiding components, creating and adding components on the fly. Nothing fancy: Delphi, VB, Swing have it for ages...

Along the lines of XHTML vs. WAP, etc-- JSF uses renderkits to take care of that issue. The problem is that there hasn't been much interest in other renderkits at this point other than XHTML.

IMO there is a different problem: often it seems easier to create and support two or interfaces (HTML, Swing, and WAP) than create one reusable UI definition.
WAP screen small and interactions are different, Swing and HTML interfaces could share definition but it will lead to underuse of Swing capabilities etc.
From this perspective JSF's attemp of common UI definition seems childish and doomed.
(I wish that I am wrong )

IMO there is a different problem: often it seems easier to create and support two or interfaces (HTML, Swing, and WAP) than create one reusable UI definition.WAP screen small and interactions are different, Swing and HTML interfaces could share definition but it will lead to underuse of Swing capabilities etc.From this perspective JSF's attemp of common UI definition seems childish and doomed.(I wish that I am wrong )

I agree. This is a point that has troubled me in a lot of MVC inspired frameworks and -applications. Since I never read about this I took the opportunity at Javapolis to discuss this with Duncan Mills (Struts Team of Oracle ADF) and some Beehive guy (possibly Eddie O'Neil). They agreed and proposed some abstraction above the level of pages that aggregates fields automatically at the right page-granularity for a client.
Of course this hits the problem that users do care for the order and grouping of fields they enter.
I'm not aware of a solution that solves this and lets you build client agnostic userinterfaces.

ILOG jViews Charts also has full JSF support and it certainly makes a big difference, especially in handling 'smart' interactivity as JSF components hide all the routine JavaScript complexities of interaction with server side. We've moved to JViews Charts a couple of months ago and now we seriously consider JSF as a strategic replacement for existing proprietary web frameworks within the organization. So I'm glad to hear that another product has gone towards the same direction.
P.S. Lack of advanced visual JSF editors is still an issue though...

Yes, I agree, the ILOG products I have used are great, but so is the amount of money you have to pay them.

Sun has their Studio Creator:
http://developers.sun.com/prodtech/javatools/jscreator/index.jsp

I've taken it for a test spin and it's extremely easy to flesh out the UI. The best part of it is that the JSP code generated uses CSS for all "visual" placement which I've commented a bit on my blog:

http://hookom.blogspot.com/2004/09/state-of-presentation-design.html

Studio Creator's use of CSS allows programmers to quickly flesh out functional applications without concerning themselves with the look and feel; afterwards a designer can simply modify the CSS in a seperate file-- creating the look and feel. This allows for seperation of concern on larger teams since programmers and designers aren't mucking in each other's work.

Other vendors such as Exadel, IBM, BEA, and I believe Macromedia Dreamweaver are now supporting or going to be supporting JSF as the Java standard.

In addition to Sun's Java Studio Creator, IBM's WebSphere Studio tools (and their forthcoming re-branded "Rational" releases) support JSF with visual designers, as does the latest (preview) version of Oracle's JDeveloper. JBuilder supports a unique code-centric editor that still allows drag-and-drop components and edit their properties on a property editor.

You can find a full list of JSF IDEs, components, and other products at JSF Central.

Kito D. Mann
Author, JavaServer Faces in Action (http://www.manning.com/mann/index.html)

Sun has their Studio Creator:http://developers.sun.com/prodtech/javatools/jscreator/index.jspI've taken it for a test spin and it's extremely easy to flesh out the UI. The best part of it is that the JSP code generated uses CSS for all "visual" placement which I've commented a bit on my blog:http://hookom.blogspot.com/2004/09/state-of-presentation-design.htmlStudio Creator's use of CSS allows programmers to quickly flesh out functional applications without concerning themselves with the look and feel; afterwards a designer can simply modify the CSS in a seperate file-- creating the look and feel. This allows for seperation of concern on larger teams since programmers and designers aren't mucking in each other's work.Other vendors such as Exadel, IBM, BEA, and I believe Macromedia Dreamweaver are now supporting or going to be supporting JSF as the Java standard.

... Sun's Java Studio Creator

JSC and Java is broken on Linux 2.6 kernels for many months now, the FAQ seems ridiculous
http://developers.sun.com/prodtech/javatools/jscreator/reference/faqs/index.jsp#jdk_nio_bug

Is it that difficult to fix the bug in JDK or work around it in JSC? There were few jdk minor releases since and it is still broken.
Conspirasy?

Sounds like it's been fixed for a while: http://swforum.sun.com/jive/thread.jspa?forumID=123&threadID=47697
http://swforum.sun.com/jive/thread.jspa?threadID=46519&start=15&tstart=0
<BR>

... Sun's Java Studio Creator

JSC and Java is broken on Linux 2.6 kernels for many months now, the FAQ seems ridiculoushttp://developers.sun.com/prodtech/javatools/jscreator/reference/faqs/index.jsp#jdk_nio_bugIs it that difficult to fix the bug in JDK or work around it in JSC? There were few jdk minor releases since and it is still broken. Conspirasy?

Sounds like it's been fixed for a while: http://swforum.sun.com/jive/thread.jspa?forumID=123&threadID=47697

It might be for subscribers. I downloaded trial, ran update, read SUNs official FAQ that says: no support for 2.6 kernels. That did not provide much encouragement for me to buy JSC.