Dynamic Bea Portal: Drag&Drop, Ajax, Context Menu, etc...

Question

Hi all,
Here's a buzzy discussion for all enterprise portal geeks:
I am currently implementing a portal on WLP.
On the other hand, I'm also building a proprietary framework to host several applications for a large institution.
For the latter, we are using Ajax and solid Javascript development to create a desktop-like visual environment (with reusable components, drag and drop between applications, context menus, dynamic windows, reusable views: list, detail, etc).
Given the functional contrast (between the portal and the rich application), I am becoming terribly frustrated by the inflexibility of the portal/portlet paradigm, and the innability to incorporate most of these concepts without hacking the specification... it's evident to me that the jsr168, as implemented now, has sacrificed too much in favor of too little (WSRP and portability) and carries with limitations imposed by arguably "obsolete" problems such as client statelessness or the innability to refresh the browser on a per portlet basis.
One might argue that the latter comes from a commitment to the "no javascript" development philosophy. But, doesn't Weblogic console, Portal admin and even the sample portal use javascript for non-trivial tasks??
OK, so we can use javascript... :-)
mmh, in that case, here are some obvious enhancements that come to my mind which still could be applied without violating the specification:
- Drag and drop of portlets within a page
- Lifecycle and State management occuring asynchronously over the wire, for each portlet independently
- Dynamic invocation of a given portlet with a javascript Api (on demand)
- Context menu (or similar) used to invoke a relevant portlet (by allowing registration, just like in a shell)
I am being <b>very</b> conservative here... and yet these features alone would create a dramatically more dynamic user experience without pushing the spec. Plus, we would be able to create lighter portal applications (smaller activation tree and the whole page reload overhead).
Of course portlet state and inter-portlet communication should (or could) then be passed to the visual interface. But, hey, isn't that where it should be? If you think about it, no portlet should allow potentially insecure operations to occurr unchecked, and for this matter, the consumer server environment is as dangerous as the user client environment (if you hold true to the producer-consumer-user paradigm).
Now, talking about interoperable portlets... how standarized is inter portlet communication anyway?
And what about mobile and js-disabled souls!!? well, I believe fallback is the word for them.
Anyway, all this issues should be resolved by the portal container, that's what we are paying for ;)!
how?... easy: clever, solid javascript and a smart fallback strategy.
If you feel I'm talking on air here, here's some pretty solid air:
http://projects.backbase.com/RUI/portal.html
http://www.google.com/ig
I am currently experimenting on this issues, but I'm already having conceptual problems with the personalization service and others... (of course, it's all thought for something else).
Any ideas more than welcome.
BEA, what do you have in mind?
Regards,
Aldo

Answer 1

Hello Armin,
Do we have this feature available in Java Webdynpro now?
Best Regards,
Roby..