Now JavaServer Faces is "out there", we are seeing components being created. Otrix announced the availability of the public beta version of WebMenu and WebTree. WebGalileo has announced Faces 1.0, which consists of many components including TabbedPanel, Toolbars, Menus, Trees, and Tables.

Visit WebGalileo: www.javawebcomponents.com

Visit Otrix: otrix.com

WebMenu is a Java Server Faces component that creates professional looking menus in minutes. It can be completely customized and allows full control over the look and feel of menus and menu items. It also provides unique features such as checkmarks, group of menu items, a rich object model and much more.

WebTree is a Java Server Faces component that provides outstanding power and flexibility to display hierarchical data.

I just wanted to point out there MyFaces (the open source JSF implementation) also has some custom components, and there's another open source project with JSF components. Also, WSAD 5.1.2 supports JSF 1.0, and has some custom components as well. I keep track of JSF products at JSF Central.

Kito D. Mann
Author, JSF in Action
http://www.JSFCentral.com - JSF FAQ, news, and info

Is this the point where JSF reaches critical mass? Since ASP.NET was released there have been several companies that develop components to work with asp.net. I would guess that now that JSF is beginning to see that same industry spring up that many of these component evelopers will join in the fray. Their experience in developing components will be wonderful in pusing the ability of developers to create sharp and clean pages very quickly with JSP/JSF. I think seeing these first few companies try their hand at components is wonderful. Especially seeing Otrix pushing mobile versions of all their controls late this year. Way to go JSF.

It will be intereesting to see how this plays out for the bigger servers as their components will not be locked into their containers. You just take the components and use them in any JSF compliant implementation. Makes me wonder if companies like IBM/BEA will even create component suites or if they will leave it to smaller vendors.

These look cool and all. However putting say 14 open source packages and maybe 5 commercial packages to create a development platform isn't my idea of a good time in dev world.

Does anyone else feel like java is getting nickled and dimed to death? Little parts here... little parts there, and basically with SUN saying "Here's our answer for this little corner of the universe, now go somewhere else to get a solution."

I mean if you get JSF, and then these components, you're still left with something far less evolved than ASP.NET. Things just seem to be creeping along, and all the while .NET keeps pulling out a huge lead.

I don't want to start a .NET vs Java war, but .NET is a direct competitor. It just seems like all of us java developers are staggering in the mud with SUN at the moment.

I share the same idea. Makes me wonder when we are gonna have something close to Infragistics........

Makes me wonder when we are gonna have something close to Infragistics........

I can't imagine it will be long. They already have a java suite.

http://www.infragistics.com/products/jsuite_portal.asp

JSuite 7
The most comprehensive set of components for:
"AWT, JFC & JavaBeans" , not JSF .

Does Infragistics support JSP? I saw AWT/Swing only

Marina

P.S. check out http://www.servletsuite.com/jsp.htm by the way

Nice to see the first JSF component suites to appear, but we need more. Much, much more!
JSP is poisoned to success, whatever some might say, simply because it is the standard Java specification for statefull web UI components and there are no major flaws discovered so far.

typo: JSF, not JSP

and maybe "poised to succeed" instead of "poisoned to success"??

although, i have to admit.. that has the making of a good saying!

;)

Check out http://www.common-controls.com for a non jsf solution to similar problems.

It took a few minutes of surfing http://www.javawebcomponents.com/ to convince me that it wasn't a solution, their website is shocking, almost pre 1995....

Well, I did not see any shutter components on the web in '95. So I'm not sure what you mean. Maybe you think the gray background color old-fashioned.

I think it's a very good thing that JSF components are appearing. It's one of the reasons I advised our client for going with JSF.
This will stand or fall I think with interoperability of JSF components from multiple vendors and portability over the available JSF implementations.

Joost

I think you're wrong.May be because you don't have the solution for JSF or may
be you're nervous because you're behind them in the area of solutions for contemporary Presentation frameworks.

As I know sun has some partners (major component companies) which by the release of java studio creator (Rave project) they also will release their component packages for java server face and creator. But probably this will not happen sooner than java one conference.

Any way It seems by the release of Rave we will have enough component for work.

Any way It seems by the release of Rave we will have enough component for work.

I think this is a bit over-optimistic. Documentation on Rave is still very thin, considering that is was introduced with great boohay at last years Java One (FYI: That was a YEAR ago). It is now more than half a year behind schedule, as is jsdk1.5. Compared with JSF this is of course a very brief period, but makes me wonder it makes Sun no more credible. Besides, the JSF request cycle is imho far to complex, especially if used within another framework, like portal frameworks etc.

Karl

This is all very well, but it shows the original JSF dilemma: You need both components and a renderkit and a jsf container.

Even if I try very hard, I cannot imagine that I want to write a custom renderkit for the various componentsuites that I would need to put together to create what I want. Likewise, I do not want to create "customization files" for different component vendors. It just does not work out.

That leaves me only with choosing a single vendor for my frontend components and that in turn will almost certainly be the vendor of my EJB platform, because of the general design flaw of JSF using the so called model 2 "design pattern".

Bottom line: This is a standard that fails to add any value now. It would have been a very good thing two or three years ago, but looking at what BEA, Oracle and the likes are shipping now, there is very little room for JSF nowadays.

This is all very well, but it shows the original JSF dilemma: You need both components and a renderkit and a jsf container..

Maybe Kito Mann can enlighten us in this, but AFAIK, component providers are going to ship custom components as a complete file, you would need just to drop them into any JSF compliant container, and be able to mix and match different vendor's components. You would have to deal with renderkits only if you needed to customize the inner workings of components or change its implementation radically (from HTML to SVG, for example), and since they would ship with a default renderkit, there is no need to create one for every component, anyway most of components visuals customization can be done with stylesheets and no coding.

Even if I try very hard, I cannot imagine that I want to write a custom renderkit for the various componentsuites that I would need to put together to create what I want. Likewise, I do not want to create "customization files" for different component vendors. It just does not work out.

See above explanation regarding this. You don't need to write custom renderkits for every component, providers should ship them with default rederderkits. I didn't get what you meant with "customization files".

That leaves me only with choosing a single vendor for my frontend components and that in turn will almost certainly be the vendor of my EJB platform, because of the general design flaw of JSF using the so called model 2 "design pattern". Bottom line: This is a standard that fails to add any value now. It would have been a very good thing two or three years ago, but looking at what BEA, Oracle and the likes are shipping now, there is very little room for JSF nowadays.

JSF is based on MVC design pattern, not model 2. That makes it completely independent of whatever model you adopt, be it EJB, POJO, or any other. AFAIK, there is no strings attached for using JSF with a mix of different vendor's components and undelying server (servlet, EJB, etc.). BEA and Oracle are already shipping or planning to ship JSF implementations on their line of application servers.

Regards,
Henrique Steckelberg

Henrique is correct -- there's no need to develop a render kit unless you're doing more sophisticated stuff -- like developing new components or augmenting existing ones. For most users, render kits are completely transparent.

So, for each suite of components, all you need to do is drop a JAR in your classpath, and you should be good to go. For third party components like the ones developed by Otrix, you should be able to use them with any JSF implementation (that includes the RI, MyFaces, or ones that ship with J2EE servers). In many cases, the extra components that major vendors ship will also work with different JSF implementations -- I know that's true of WSAD's componets (I've spoken to their product manager).

Kito D. Mann
Author, JavaServer Faces in Action
http://wwww.jsfcentral.com -- JSF news, FAQ, and info

Henrique is correct -- there's no need to develop a render kit unless you're doing more sophisticated stuff -- like developing new components or augmenting existing ones. For most users, render kits are completely transparent. So, for each suite of components, all you need to do is drop a JAR in your classpath, and you should be good to go. For third party components like the ones developed by Otrix, you should be able to use them with any JSF implementation (that includes the RI, MyFaces, or ones that ship with J2EE servers). In many cases, the extra components that major vendors ship will also work with different JSF implementations -- I know that's true of WSAD's componets (I've spoken to their product manager).Kito D. MannAuthor, JavaServer Faces in Actionhttp://wwww.jsfcentral.com -- JSF news, FAQ, and info

Kito, you should really know that this is most likely not true, even for plain html. While the components should work with all other vendors - otherwise it would make no sense - it is very unlikely that a more complex component, like a date chooser, a tree, a tabbed pane etc. will get away without customization or indeed without implementing a custom render kit. At least as long as the "corporate communication departments" hold all the power of how a website will look like.

<blockquoteKito, you should really know that this is most likely not true, even for plain html. While the components should work with all other vendors - otherwise it would make no sense - it is very unlikely that a more complex component, like a date chooser, a tree, a tabbed pane etc. will get away without customization or indeed without implementing a custom render kit. At least as long as the "corporate communication departments" hold all the power of how a website will look like.You can change 99% of what JSF components look like simply by using CSS stylesheets. You don't need to mess with renderkits, as stated previously, unless you want radical changes, like making components generate SVG code instead of HTML code, and the likes.

You can change 99% of what JSF components look like simply by using CSS stylesheets. You don't need to mess with renderkits, as stated previously, unless you want radical changes, like making components generate SVG code instead of HTML code, and the likes.

The you repeat it does not make it more true - sad it may be. Consider using round tabs vs. rectangular tabs on a tabbed pane, or use images as the pane headers, consider definition of images to use on a calendar component or in a tree control. True, you might get away without creating a new renderkit and do with plain configuration, but stylesheets are clearly not enough.

Besides, you do expect that the creators of the original renderkit have catered for all options you will need. More often than not, the renderkit will generate something that uses the same style in the original rendered content where you will need different styles. Consider a very simple example: A breadcrumb trail where the last node uses the same style as the separator. Now, you need to apply different styles, or the separator needs to be replaced with an image, or the separator needs to be cliackable or or or

The you repeat it does not make it more true - sad it may be. Consider using round tabs vs. rectangular tabs on a tabbed pane, or use images as the pane headers, consider definition of images to use on a calendar component or in a tree control. True, you might get away without creating a new renderkit and do with plain configuration, but stylesheets are clearly not enough.

You gave the response: simple configuration, in the case the components already have those. Adding new configurations to an existing component would require trivial changes in most cases to the renderkit, BTW.

Besides, you do expect that the creators of the original renderkit have catered for all options you will need. More often than not, the renderkit will generate something that uses the same style in the original rendered content where you will need different styles.

Most of the times CSS resolve, other more complex changes may require at most simple changes to component's renderkit code, I really don't know what the fuss is all about regarding this.

Consider a very simple example: A breadcrumb trail where the last node uses the same style as the separator. Now, you need to apply different styles, or the separator needs to be replaced with an image, or the separator needs to be cliackable or or or

These changes are trivial in most cases, in the case they are not already present in components, and they must be done only once, so again, these are not fundamental problems that invalidate JSF in any way. Just make sure your component providers implement the options and behaviours you need, and you should be good to go! :)

Besides, having components (any kind of component) that may not cater to every user's need present and future is not an issue exclusive to JSF, it happens in every place where components exist. The point is, the specification should be flexible enough to allow for new needs to be implemented, and IMHO JSF has it.

Regards,
Henrique Steckelberg

JSF is based on MVC design pattern, not model 2. That makes it completely independent of whatever model you adopt, be it EJB, POJO, or any other. AFAIK, there is no strings attached for using JSF with a mix of different vendor's components and undelying server (servlet, EJB, etc.). BEA and Oracle are already shipping or planning to ship JSF implementations on their line of application servers.Regards,Henrique Steckelberg

For the moment, I am trying hard not to evangelize what MVC means. The problem is that the application server frameworks - like the usual portal frameworks etc - themselves are built on model2 or "MVC". Using JSF on top of that is stacking two frameworks that are in fact built for the same thing. This is almost certain to create problems and confusion.

Also, the approach chosen for JSF to use a single "controller servlet" (still!) makes me steam. It was a very bad decision two years ago and it still is, since it bypasses declarative security and has sported millions of man-hours of development time to recreate what was in the servlet spec in the first place, at the same time hindering fixing the flaws inherent in the security model, since nobody used declarative security in the first place.

Otrix announced ...

I find it extremely annoying that a statement is posted about a company(??) that does not care to tell me:

- Its legal form
- Its location
- Its phone number

It makes me wonder if it exists. It devalues all information about trade marks (trade marks WHERE please?). It is illegal at least in the european union. It does not introduce any trust using the stuff.