click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian A. (JIRA)" <>
Subject [jira] Commented: (CLK-675) Portlet Support in Click
Date Sun, 23 May 2010 10:57:17 GMT


Adrian A. commented on CLK-675:

This might not be an easy task at all - considering the Click Page based architecture.

There might be several problems with Portals/Portlets:
 - there doesn't seem to be any fast portlet container implementation so far :(. All I've
tried were very very slow compared to the alternatives. (do you know one that is really fast?
 - mostly when users/customers want "portals" they don't need portlets but something that
just looks and behaves like a portal
 - many of the well known public Portals (that users keep refering to) are not portlet based.
For some of them the aggregation is done with Ajax, other use CMS functionality like modules/boxes
to achieve that portal look and feel.
So I'm not very sure if it's worth spending the effort, considering that e.g. with Ajax the
portal "effect" could be achieved much simpler and faster.

With jQuery:

With Prototype:

> Portlet Support in Click
> ------------------------
>                 Key: CLK-675
>                 URL:
>             Project: Click
>          Issue Type: New Feature
>          Components: extras
>            Reporter: George Stan
> Please support Portlets in Click.
> Tapestry has it, Wicket has it, and even if this is not a too good argument for it, I
believe click should have
> some sort of Portlet support too (even if it's not in the core, but a third party solution).
> Many companies adopted a portal solution, so for them it's not an option *not* to use
portlets. They use JSF,
> and Tapestry despite the fact of not being very easy to learn.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message