While most channels produce XHTML directly, you can use rich client technologies for channels.
Examples include Swing via Java Applets, AJAX (the architecture Google uses for things like GMail and Google Maps), the Flash-based Open Laszlo, and the JavaScript-based Qooxdoo.
Pete Boysen has implemented a theme called DnDPreferences that uses drag and drop for setting preferences in AL. It uses a JavaScript toolkit by Walter Zorn.
Direct Web Remoting is supposed to enable you to remote Spring managed beans to JavaScript.
Anyone producing channels using rich client technologies?
I collected a bunch of links on our own instance of confluence on rich client technologies...
User Interface Framework/Techniques
OpenLaszlo
Qoodoo
Tacos
Fade Anything Technique
Integrating Drag and Drop
Integrating HTML editing with FCKEditor
AJAX XmlHttpRequest Links
Ajax XmlHttpRequest
Very Dynamic Web Interfaces using XmlHttpRequest
XmlgHttpRequest Object
XHConn - Simple XMLHTTP Interface
XmlHttpRequest demos
Ajax XmlHttpRequest working examples
AJAX XmlHttpRequest tutorial
Amazon Zuggest
Japano
Direct Web Remoting
Direct Web Remoting @java.net
DWR - Direct Web Remoting
JSON-RPC
DWR and Spring
Comments (2)
Apr 15, 2005
Yuji Shinozaki says:
A colleague is close to finishing a calendaring channel which uses DHTML for dra...A colleague is close to finishing a calendaring channel which uses DHTML for drag and drop UI functionality. I don't think it is utilizing any paticular library or toolkit, just hand-coded DHTML. It is an IChannel implementation and not a portlet at the moment but the DHTML implementation is of course transferable.
I think the power of xmlhttprequest (the cross-browser technology that Google Suggest and Google Maps employs) is ripe for use in a portal. Imagine this: a portal framework where xmlhttprequests from individual channel markup are marshalled by the framework, giving the channels (portlets) the ability to update content without having to repaint the entire layout.
I am wondering whether you could even design it such that the channels (portlets) themselves even could be unaware of the xmlhttprequest mechanism. They are treated like a normal request cycle by the portlet/ichannel.
This would allow for "asynchronous" updates that do not require full page rendering.
Apr 18, 2005
Jason Shao says:
I think if you were determined to enable behavior within the channel framework, ...I think if you were determined to enable behavior within the channel framework, you could probably generate your responses using an EXCLUSIVE window-state to send back raw XHTML.
As far as transparently enabling functionality... Since portlets at their root ARE a packeaged servlet webapp, it seems that any of the various technologies for "automagically" exposing beans & services (JSON-RPC, DWR, Spring-Remoting etc.) as XML-RPC style services should work independently of the portlet container being aware of their existance.