You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by "George Stan (JIRA)" <ji...@apache.org> on 2010/05/19 16:32:53 UTC

[jira] Created: (CLK-675) Portlet Support in Click

Portlet Support in Click
------------------------

                 Key: CLK-675
                 URL: https://issues.apache.org/jira/browse/CLK-675
             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.


[jira] Commented: (CLK-675) Portlet Support in Click

Posted by "Adrian A. (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CLK-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870386#action_12870386 ] 

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:
http://www.trilancer.com/jpolite/
http://stackoverflow.com/questions/498701/how-to-build-a-portal-page-with-saveable-state-in-jquery-ui
http://host.sonspring.com/portlets/

With Prototype:
http://blog.xilinus.com/2007/8/26/prototype-portal-class
http://aymanh.com/drag-drop-portal-interface-with-scriptaculous

> Portlet Support in Click
> ------------------------
>
>                 Key: CLK-675
>                 URL: https://issues.apache.org/jira/browse/CLK-675
>             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.


[jira] Commented: (CLK-675) Portlet Support in Click

Posted by "Matthias (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CLK-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878536#action_12878536 ] 

Matthias commented on CLK-675:
------------------------------

I know, that is not a simple Task and the reason for this feature request is not the gui in my case.
You are right that the performance in Portletserves are always poor but in our company we must  support a Portletserver.
The main reason for portlet support, is in my case the authentication/authorization access, not the gui.

It would be a big feature, if click supports a alternate super class page like PortletPage.















> Portlet Support in Click
> ------------------------
>
>                 Key: CLK-675
>                 URL: https://issues.apache.org/jira/browse/CLK-675
>             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.