Rialto is a cross browser javascript widget library. Because it is technology agnostic it can be encapsulated in JSP, JSF, .Net or PHP graphic components. The widget library includes forms, drag & drop, tree, data list with fix header and resizable columns, pop up, splitter, and more.

Rialto enables single page application development, and is available under the open source Apache License.

A taglib version of Rialto is already available. JSF and PHP versions of Rialto are on the way.

Here is a demo of Rialto :
http://rialto.application-servers.com/demoRialto.jsp

Here is a proof of concept for Rialto JSF:
http://rialto.application-servers.com/NewsReaderJSF/

This (JS widgets) library is the way to go for browser based applications. We need JS objects for widgets to be manipulated by client side JS code.

But, we also need these widget components on the server side too, preferably with the similar object model. With similar I meen that at least the names and meaning of the properties, methods and events are the same.

There are progreses on both sides (client and server) to provide decent component model, but we need unified one.

That means server side component framework which renders JS objects instead of HTML, letting JS objects render HTML. And the object model for both must be similar at least (as described above).

I agree with Mileta. The "server-side" approach is preferable. Not only because of the object model api but also because it allows packing the shaky JS code into an application independent "presentation engine" such that you can write your apps in pure server-side Java.

This approach is feasible with JS, Java, or Flash, as described in http://www.javalobby.org/articles/ajax-ria-overview/.

You can find a concrete design solution in http://javadesktop.org/articles/canoo/index.html (based on Java, but also feasible in JS)

I agree with Mileta. The "server-side" approach is preferable. Not only because of the object model api but also because it allows packing the shaky JS code into an application independent "presentation engine" such that you can write your apps in pure server-side Java.

That's the benefit of JSF. A lot of JSF components are AJAX-enabled these days, and you still get a full component object model on the server. Otrix's WebStudio Enterprise, Oracle's ADF Faces, and JScape's WebGalielo components all include AJAX functionality (and will be including even more).

Kito D. Mann
Author, JSF in Action
http://www.jsfcentral.com

That's the benefit of JSF. A lot of JSF components are AJAX-enabled these days, and you still get a full component object model on the server. Otrix's WebStudio Enterprise, Oracle's ADF Faces, and JScape's WebGalielo components all include AJAX functionality (and will be including even more).

But we need JSF renderers that render JS objects, NOT HTML. JS objects themselves should render HTML (and have 'the same' object model as JSF components if possible).

Having JSF components been 'AJAX enabled' is not enough.
We need object model for widgets on both sides.
Btw, I am sick and tired of 'AJAX enableness'.

Off-topic: Must reply to myself as there is no post editing feature on TSS yet :(.

It seems very a interesting library.

Congratulations. We appreciate your efforts.

Kind Regards

This (JS widgets) library is the way to go for browser based applications. We need JS objects for widgets to be manipulated by client side JS code.But, we also need these widget components on the server side too, preferably with the similar object model. With similar I meen that at least the names and meaning of the properties, methods and events are the same.There are progreses on both sides (client and server) to provide decent component model, but we need unified one.That means server side component framework which renders JS objects instead of HTML, letting JS objects render HTML. And the object model for both must be similar at least (as described above).

Why don't you take a look of this OSS proejct:

ZK ( http://zk1.sourceforge.net )
Live demo ( http://www.potix.com/zkdemo/userguide )

I think it does exactly what you want. However, its client side components are done based on the prototype.js .

Here is a proof of concept for Rialto JSF:http://rialto.application-servers.com/NewsReaderJSF/

This is good news. However, I was unable to register with the application. It just hangs when I try to save my registration.

Ed

one is from server in tags to push out little widgets. (Struts Ajax/WebParts is an ex.)

the other is for the application to be closer to ui, and ajax jusk makes requests for the ws.
pull.
(this is how WinFX, DWR, Flex and Swing work, they run on client and request data). The 2nd way (push) would likely win out if it makes for better looking applications. With WS built in J2EE5, and I do not think 1st way has legs, it's just a stop gap.
The application is only deployed and it make requests.

.V

1. it is very very slow
2. hangs when i try to register
3. Believe it or not throws a lot of Javascript errors on IE.
this tells me how the holy grail of client side api has always failed in the past will continue to do so in future.
Be it ajax, swing, or plaing java script.

I guess one could chalk it up to a bad web site...

If not, the load time for this toolkit is worse than Java applets -- under Java 5 at least...

this looks rich indeed. these javascript/dhtml/ajax whatever technologies all have a nice "wow" factor, but they're less usable than their counterparts in the rich client area. keyboard access to these type of applications lack much to be desired. i was using the treeview from the Rialto example, and thought arrow keys would navigate me through the nodes. nope.

i use mozilla as my primary browser. i'm very use to it's type ahead feature, where i can start to type something and it'll search the links on the page. so, when i'm on the yahoo mail site, and start to type "inbo" the cursor is on the inbox, and , press enter, and i'm in the inbox. much more efficient than moving to the mouse, moving the pointer to visually match up where the inbox link is and then left clicking on that link. out of habit from navigating to my inbox, i tried something similar in gmail, but found that the browser didn't seem to know how to get to those links.

Hi,
I also noticed the same issues, I had IE 6 with WinXP SP2.
I viewed the source of one page that generated an error, it was :
<script type="text/javascript">
_uacct = "UA-63979-2;
urchinTracker();
</script>

It's obvious that the encoding string "UA-63979-2" is not properly terminated. I don't know what's wrong. But it seems an automatically generated script

Hi,I also noticed the same issues, I had IE 6 with WinXP SP2. I viewed the source of one page that generated an error, it was : <script type="text/javascript">_uacct = "UA-63979-2;urchinTracker();</script> It's obvious that the encoding string "UA-63979-2" is not properly terminated. I don't know what's wrong. But it seems an automatically generated script

It seems then you should blame Google Analytics rather than Rialto...

You lads at Rialto have done a great job there. Not bad at all.

What strikes me as difficult for managing this sort of application is managing GUI state changes between page transitions.

Ultimately, a richer GUI allows the users of web applications to manipulate more complex object models in a much smaller number of pages than a traditional wizard would allow, but you're unlikely to reduce this number to zero for all applications - and then what happens when the user decides to go back and change something? The more complex you've made your GUI, the more complex you've made it for yourself to return that user to the page in the state he last saw it.

Rialto doesn't of course aim to address these needs as it's a widget library!

Cheers

Mike

Excellent job!

Looking forward to the JSF components. This is exactly what I've been dabbling with lately..

-Chris

I am at home using my Mac. The demos don't seem to work on Safari, which may not matter to many folks (but matters to me at this moment). I'll try the demos on Monday when I am using my laptop. For now, I'll use my imagination.

The library is impressive... I've found it while searching for some client-side widget lib for a Healthcare-related development, quite a coincidence that Rialto was developed for the same purpose.

I found some JS errors in Internet Explorer, I'll try to fix them as I start to use the libraries. I hope the SVN repository accepts contributions.

Kind Regards,
Guido Scalise
Las Palmas de Gran Canaria - Spain

People look at this and get the impression that "rich" component-based web-apps are slow. Maybe they are?

Credit to the Rialto team. After some maturing, this could be a viable option for a rich client interface. Until it reaches that level of maturity, you might check out qooxdoo and its demo.