Return-Path: Delivered-To: apmail-click-dev-archive@www.apache.org Received: (qmail 71315 invoked from network); 23 May 2010 10:57:44 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 23 May 2010 10:57:44 -0000 Received: (qmail 23061 invoked by uid 500); 23 May 2010 10:57:44 -0000 Delivered-To: apmail-click-dev-archive@click.apache.org Received: (qmail 23007 invoked by uid 500); 23 May 2010 10:57:43 -0000 Mailing-List: contact dev-help@click.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@click.apache.org Delivered-To: mailing list dev@click.apache.org Received: (qmail 23000 invoked by uid 99); 23 May 2010 10:57:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 May 2010 10:57:42 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 May 2010 10:57:39 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o4NAvH69028844 for ; Sun, 23 May 2010 10:57:17 GMT Message-ID: <3339266.39271274612237152.JavaMail.jira@thor> Date: Sun, 23 May 2010 06:57:17 -0400 (EDT) From: "Adrian A. (JIRA)" To: dev@click.apache.org Subject: [jira] Commented: (CLK-675) Portlet Support in Click In-Reply-To: <11172443.14291274279573963.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on 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.