another WYSIWYG / Drag and Drop portal page example similar to the google sample can be found here: http://www.netvibes.com/ I also like to be able to have a fullfledged way of layouting my portal page via a flexible UI /layout model as is the case with Jetspeed ( a portal I otherwise do not like particularly well ) There you have pluggable decorators which can render your porlet frames (frameless window, framed window with insets etc..). You have pluggable page layouts ( three column, two column, etc...) to choose from. and so on. I don't find this in jboss portal. The "region" mechanism seems to be rather corse grained in comparison. ---- Another interesting thing I read about in the Jetspeed 2 Jira is their plan for a thingy they call Jetspeed Desktop: http://issues.apache.org/jira/browse/JS2-514 This seems to go even a bit further than having an AJAX supported WYSIWYG portal page layout mechanism which helps to define a server side layout. ---- I've been musing about assembling the perfect collection of technologies for being able to deliver rich web clients while at the same time being standards based and being able to rapid prototype. The fixed choices are that this should be portal driven, use Java Server Faces, Seam, Facelets, JSF-Avatar and EJB3. The bulding-block that has been missing for years is that there does not seem to be a JSF component kit which satisfies all needs. Most kits work well in standalone mode (Apache Tomawhak, Oracle ADFFaces aka Apache Trinidat etc) but they fail to work well in collaboration with a portal framework and / or seam. Additionally, the component/render kits are not really satisfyable and robust. I would have to combine aspects from 5 different AJAX kits and another 5 JSF kits to satisfy my vision. (Tomawhak, Trinidat, Tobago, Dojo, Qooxdoo, Rialto, ZK, DWR, jMaki, etc. etc.) What currently happens is that some JSF component/render kit provider now try to integrate components from all these kits into their component library. This is the same type of misuse happening with multiple inheritance where any object which happens to have an interesting method is turned into a supertype... In practice, it is not acceptable to download the javascript/html code for 20 AJAX and web frameworks before being able to look at a beautifully rendered page. I think the community is lacking a robust and satisfyable JSF component library/rendering kit. Everyone is doing some things right but no single vendor does it all right at the same time. - EXO alone supports WCAG 1.0 - Tomawhak is a pot pourri of external scripts reused and doesn't support drag and drop etc.. - ADFFaces is too invasive and doesn't integrate well with other supplementary technologies, so is the current version of SEAM. again, this list could be continued forever Therefore I think that instead of providing halfhearted approaches for embedding JSF rich client frameworks which have not been designed with portals in mind by allowing header injections and the like, I'm thinking more into the direction of defining an XML GUI language that the JSF portlets would emit. The portal would then be responsible for rendering this meta language into javascript/html etc. Again, there are many such XML GUI definition languages out there (OASIS' UIML, Netscape's XUL, W3C's XBL, etc...) but none is a satisfyable solution, probably because the contexts of these approaches are too different from the portal context. XUL was designed with thick desktop environments in mind. UIML is too old - the portal metaphor was uncommon then...) I don't know whether JBoss/Redhat have enough resources to start off from scratch to design a real groundbraking JSF component/render kit, but lets assume that this is most likely beyond the focus: how can you impove your UI? I'm finding myself in the same spot: IF I revamp all the UI stuff I've done which will be a tremendous effort, then I want to do it right the first time and without compromises. I would need to have something at hand that supports drag and drop, client side validation, portal affinity, half objects, AJAX, etc. However, this can only be achieved by mingeling different things together and spending a tremendous effort doing so. That's why I don't understand why all the world is focussing on narrow focus frameworks like lets say an "AJAX toolkit" instead of working on a comprehensive JSF kit with out of the box support for the abovementioned. For example, it would be appriciable to have transparent AJAX support like the ingenious approach taken Avatar. I can only applaud Ed Burns for this approach. Of course, a JSF framework using this approach should be designed by keeping in mind that it also has to be usable in the context of portals... Why am I saying all this? well because I would like to see that the JBoss Portal standard portlets like the CMS, administration or forum portlets are done using a JSF kit. But before conducting this migration, I believe that it is paramount to first work on a satisfyable JSF kit that has at least been designed with portal technology in mind. --- Another thing I'd like to say is that sample apps always asume that developers will put all libs within their webapps. So lets do a hello-world app. All the Tomawhak, myfaces, SEAM and facelets libs go into the webapp. On the business layer side, you'd like to use JBPM and there you have another two libs to pollute your application. Your hello world app turns out to be 20 MBs in size for holding a single web page. This of course is not the usecase that is applicable for real world scenarios. However, one can spend weeks trying to arrange all the libs so that the technologies work well together and yet not find a way to do it. Therefore, one requirement I would like to propose is that JBoss provides samples that really match production environment use-cases in addition to samples which focus on showcasing technological aspects and therefore righteously trying to reduce unnecessary plumbing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961383#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...