Comments on: Widgets vs. Portlets http://www.megginson.com/blogs/quoderat/2008/07/14/widgets-vs-portlets/ what was Fri, 19 Mar 2010 13:06:42 +0000 http://wordpress.org/?v=2.5.1 By: Widgets will win the battle http://www.megginson.com/blogs/quoderat/2008/07/14/widgets-vs-portlets/#comment-36433 Widgets will win the battle Tue, 29 Jul 2008 14:33:43 +0000 http://www.megginson.com/blogs/quoderat/?p=221#comment-36433 [...] ..against the portlet. David Megginson have written an excellent post on Widgets vs. Portlets. [...] [...] ..against the portlet. David Megginson have written an excellent post on Widgets vs. Portlets. [...]

]]> By: Viet http://www.megginson.com/blogs/quoderat/2008/07/14/widgets-vs-portlets/#comment-36224 Viet Wed, 16 Jul 2008 10:53:06 +0000 http://www.megginson.com/blogs/quoderat/?p=221#comment-36224 Using a portlet container does not equals 1995 Mac desktop style, look at eXo WebOS which makes a different usage of the portlet technology (http://www.exoplatform.com/portal/public/en/product/webos/overview). Using a portlet container does not equals 1995 Mac desktop style, look at eXo WebOS which makes a different usage of the portlet technology (http://www.exoplatform.com/portal/public/en/product/webos/overview).

]]> By: Viet http://www.megginson.com/blogs/quoderat/2008/07/14/widgets-vs-portlets/#comment-36223 Viet Wed, 16 Jul 2008 10:47:18 +0000 http://www.megginson.com/blogs/quoderat/?p=221#comment-36223 @Matthias: As you said there is WSRP which allow runtime decoupling, so living in the same runtime is recommended for simplicity and performances but it is not mandatory! Library versioning is solved in Java EE environments where different portlet applications can have their own version of the library. Doing a portal in a browser using widgets will work fine if you stick to one component model, i.e all your widgets are Google widgets or whatever else. For instance iGoogle works fine because they defined their component model and they only work with it. Once you start to mix technologies, you open the door to potential issues as the same DOM document is shared between the different widgets (toolkit versionning, prototype modifications done by toolkits, etc...). @Matthias:

As you said there is WSRP which allow runtime decoupling, so living in the same runtime is recommended for simplicity and performances but it is not mandatory!

Library versioning is solved in Java EE environments where different portlet applications can have their own version of the library.

Doing a portal in a browser using widgets will work fine if you stick to one component model, i.e all your widgets are Google widgets or whatever else. For instance iGoogle works fine because they defined their component model and they only work with it.

Once you start to mix technologies, you open the door to potential issues as the same DOM document is shared between the different widgets (toolkit versionning, prototype modifications done by toolkits, etc…).

]]> By: Matthias http://www.megginson.com/blogs/quoderat/2008/07/14/widgets-vs-portlets/#comment-36179 Matthias Mon, 14 Jul 2008 16:34:18 +0000 http://www.megginson.com/blogs/quoderat/?p=221#comment-36179 Portlets live in the same runtime. This opens the door for one portlet affecting the whole system due to memory leaks or other failure modes. It may also incur library versioning problems. There is no clean way to kick a portlet out of a running container. I find these points to be BIG counterarguments. Does WSRP solve this? Maybe. But I also see the way going towards widget based systems with integration in the browser level (how long will it take until we have integration nightmare there ... ?) Portlets live in the same runtime. This opens the door for one portlet affecting the whole system due to memory leaks or other failure modes. It may also incur library versioning problems. There is no clean way to kick a portlet out of a running container. I find these points to be BIG counterarguments. Does WSRP solve this? Maybe. But I also see the way going towards widget based systems with integration in the browser level (how long will it take until we have integration nightmare there … ?)

]]>