The iternum ui framework is a full fledged ui framework firmly based on Servlet 2.3/ JSP 1.2 APIs. Development of the iternum ui framework started last fall due to the slow and initially unsatisfactory output of the Java Server Faces (JSF) JSR.

Since then it has been used in various projects most notably as the frontend layer for the online diabetes diary Sugarpoint.

The projects goals are:

- Rapid Application development support
- Clean component model
- Advanced form handling
- Rich component set
- Pluggable look and feel
- Easy internationalization
- Clean integration with the JSP programming model

Visit the iternum ui framework home:
http://www.iternum.com/i3ui/index.jsp

Is everyone that down on JSF? Have Sun missed the boat on it?

...

Yeah, what took them so long? Surely missed the boat on this one...

Evidently, Iternum doesn't get it. What's the point of creating yet another web UI toolkit when the real challenge is creating a next-gen browser propelled by next-gen XML markup such as XHTML/XUL/SVG and so on.

I guess creating your own UI toolkit is the fashionable thing to do. For more info about next-gen browsers propelled by XML check out the XUL Alliance site or catch breaking news at the XUL News Wire about real innovation instead of another rearrangement of deck chairs on the HTML titanic story.

I kind of like the direction. Could you direct me to a link that outlines how security integrity can be maintained? Also, My JSPs can be dynamic XML documents that are served to a XUL client, right?

John C. Dale
Down in the Desert, Inc.

How SVG is better than PostScript?
I think it is time to say good-bye to browsers and use normal PostScript based XWindow server on client side to access server side programs. There was/is NeXTstep who does the trick.

Gerald, I really can't see what XUL has to do with this. As far as I can see you can use any ui framework (iternums as well as JSF or what have you) to render XUL. The purpose of a UI framework is to provide the *implementation* for event handling, internationalization etc. and not (or at least not primarily) its represnentation. So you can render XUL if you want to.

On the other hand, I think stuff like 2-tier XUL motors is a stupid idea (I am not sure if that is what you want, but it sort of sounds like it). I am not even sure that whether people should resort to writing (or drag and dropping) XUL altogether or whether it should mainly be a way to tell the motor what to do.

And considering that the JSF talks at JavaOne were *packed* I assume that there is indeed a need for such toolkits.

<wolfgang>
Gerald, I really can't see what XUL has to do with this. As far as I can see you can use any ui framework (iternums as well as JSF or what have you) to render XUL. The purpose of a UI framework is to provide the *implementation* for event handling, internationalization etc. and not (or at least not primarily) its represnentation. So you can render XUL if you want to.
</wolfgang>

I guess you have never tried XUL. XUL doesn't need a UI toolkit such as JSF layered on top of it because in contrast to HTML XUL is already full-featured and designed on purpose and not by accident for rich clients.

Let's say you want to submit XML form data using SOAP then why not use XForms? Let's say you want to create a new XUL widget why not use a XUL plug-in? and so on and so forth.

Sun just ignores the next-gen browsers propelled by next-gen XML markup such as XUL because they want to push their server boxes and because XUL makes Java UIs such as Swing irrelevant on the desktop. Just read Sun's pathetic XUL pink paper and share a laugh about Sun's 10000 % pure Java vision.

- Gerald

Did anybody try it? How does it compare to Tapestry?

I do not want to put down the project, I have not looked deeply enough into it. But based on the demo's this library can not provide anything more than JSF and because it is marketing itself as a JSF alternative it should provide a clear advantage.

I hate myself for not writing a JSF component set that demonstrate what is possible, until I do that in the os community there is not much weight to my words.

For those who are interested in JSF, it is fully capable of creating very rich user interfaces, maybe not out of the box, but with custom components certainly.

The other post about the jsf component set from orbeon is a lot more interesting.

My 2 cents.

Mark, I agree you have a point. iternum ui is in fact conceptually pretty similar to JSF as it was motivated for the need of programmatical componentization of web applications.

However JSF itself is pretty far from defining a decent component set and initially parts of it (the specification, that is) were pretty much broken, like component aggregation etc.

We started this about a year ago and I've since done a couple of projects using it and came to like it. And considering that JSF while finally nearing it is - sigh - still not completed, it was a logical decision to publish it, because - unlike JSF - it has been proven in real world projects.

I can assure everyone here that JSF has and is being proven in at least one 'real' world project that provides excellent performance with a very complex ui.

The initial JSF spec did not provide a good mechanism for component aggregation. We rolled our own into ea2 release through internal children. Sun has very nicely incorporated the same idea into the ea4 release with the introduction of facets. It is actually very easy to create complex aggregate components.

I can understand some frustration with the slow pace which jsf has matured. With the latest release they have really pushed it leaps and bounds closer to very good solution.

My point is simply that looked at jsf previously and thought it was too rough around the edges, it probably still is, but I expect that by the time the next release is made that will not be the case any longer.

For any developer who is willing to do a little extra work the benefits are well worth it.

Mark, I find your statements giving me hope for JSF. I really hope Sun will provide a great web UI framework in JSF. However, I am having trouble with two of your statements when I put them together from two of your posts.

Statement 1: "I hate myself for not writing a JSF component set that demonstrate what is possible,...'

Statement 2: "It is actually very easy to create complex aggregate components."

If it is truly easy, then why has it not been done ? Either by you or someone who knows how ?

Hello,

I really enjoy the concepts of JSF but what about using it in production environnment ? I had wait one year for having a good and stable struts 1.1 (will be soon replaced by 1.2), how many time do you think that it will take before we can use JSF in production applications ? I we must wait the final version, and if there is no decent open source implementation (for the moment i have seen nothing except one dead project on sourceforge), i think that nobody would use JSF, but will go on other platforms (like .NET for the people who can/want use microsoft) because there is a real need for web components, easily reusable on different webapplication. For my part i will look closer to Tapestry, who is at the version 3.0 : i think that it would be stable (more than JSF ea4!)

Tapestry has the advantage that it has responded to end-user feedback over the last three years. In addition, components are an intrinsic concept in Tapestry ... JSF is an attempt to bolt components onto JSPs which really don't like them.

I took a brief look at some of the docs and examples for this Internium product. In fact, it looks at bit familiar, much like Tapestry 2.3, in that the JSP tags are just placeholders for the components, with the rest of the component definition elsewhere. Looking over the code is also familiar ... there are only so many ways to skin a cat.

The workflow stuff may be interesting, I didn't dig deep enough to see what its all about.

I was unimpressed by the fact that some of the demos required JSP scriptlets (Calendar).

Didn't see any examples of components having thier own templates ... a cornerstone of Tapestry.

Dissapointed that the framework comes with only JavaDoc, no detailed documentation. Did I miss it?

I downloaded the demo, and the license file says that commercial use is forbidden. Is this a commercial product?

Christoph, we have not 100% decided about the actual license but most likely it will be an Apache Style license, allowing commercial use and redistribution. The current license is sort of a leftover of the preview version. I am a bit under pressure at the moment but will fix it as soon as I find some time.

Karl

thanks karl for clarifying this.

if you plan to put it under a non viral opensource license, i will definately take a look.

regards
 chris