RE: ANN: [portal] New CachingPortletAdapter

-Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Friday, January 07, 2005 5:46 PM To: dev@cocoon.apache.org Subject: Re: ANN: [portal] New CachingPortletAdapter DURDINA Michal wrote: Sorry for just a quick response. JSR168 - portlet specification

ANN: [portal] New CachingPortletAdapter

Hi, after some days of coding I finished the implementation of CachingPortletAdapter ! With CachingPortletAdapter you can have JSR168 portlets that behave (almost) exactly as they were every opened in single web browsers. This means that only one portlet that triggered the action is regenerated

RE: ANN: [portal] New CachingPortletAdapter

CachingPortletAdapter Hi, the portlet standard already supports caching; each portlet can be configured to be cached and the portlet container (in our case pluto) should cache the content. So I think our portal already does the caching. Or do I oversee something? Carsten DURDINA Michal wrote: Hi

RE: JSR-168 Portlets

Carsten Ziegeler wrote: I did get it running in Tomcat with just the Pluto libs in lib/shared and it worked - it's a long time ago Now, the better way imho would be if the portlets would run inside of Cocoon rather than inside of Tomcat. So, you deploy your portlet wars into your

[portal] Upload not working for JSR168 portlets in Cocoon portal

Hello, have you ever tried upload from within portlet in cocoon portal? I can't get this working. I think it is because of the condition that is checking current request content type (must be 'multipart/form-data' for upload) and the implementation of portal servlet request wrapper

[portal] handling portlet action request

I know this should be targeted more to cocoon-users but I believe this would be interesting also for developers. Two types of portlet requests are handled by CocoonPortlet in methods: processAction(request, response) render(request, response). Speciallity of handling ACTION

RE: Design of unmarshaling sitemap component

-Original Message- From: Hunsberger, Peter [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 7:06 PM To: [EMAIL PROTECTED] Subject: RE: Design of unmarshaling sitemap component DURDINA Michal [EMAIL PROTECTED] writes: Hi, I would like to discuss the design problem

[portal] bookmarks to portlets

Hi, is there any solution how to make a bookmark in PortalEngine to JSR168 portlet? I need to pass a parameter in the bookmark to portlet via url. I know how to do this with coplets (using custom bookmark event that stores parameter to coplet attributes), but I am not sure how to handle this

RE: [portal] JSR168 portlets problems under PortalEngine

Hi, I found some more issues about running JSR-168 portlets in the Cocoon Portal. 1. There is one serious problem with IncludingHTMLSerializer when serializing 2 and more portlets whose are interleaved with bigger amount of HTML markup. Serialization is carried out in blocks of 8Kb and

RE: [portal] JSR168 portlets problems under PortalEngine

? Thanks Thanks Carsten Carsten Ziegeler Open Source Group, SN AG http://www.osoco.net/weblogs/rael/ -Original Message- From: DURDINA Michal [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 9:37 AM To: [EMAIL PROTECTED] Subject: RE: [portal] JSR168 portlets problems

RE: [portal] JSR168 portlets problems under PortalEngine

... 1. test2.jsp: Call to portalContext.getSupportedWindowStates() returns null. I fixed this (hopefully) yesterday morning in the CVS. Haven't got chance to test it again. After I updated my whole cocoon-distribution from CVS and build clean webapplication only with portal-block

[portal] JSR168 portlets problems under PortalEngine

Hi, I found some problems while running jakarta-pluto testsuite under CocoonPortalEngine. I would like to report them and offer help if needed. 1. test2.jsp: Call to portalContext.getSupportedWindowStates() returns null. 2. test2.jsp: Call to renderRequest.getParameter(testName) returns null

[Portal] Question: Why JSR-168 portlet impl moved?

Hi, I am curious why Carsten moved portlet implementation from scratchpad to portal block... I thought JSR-168 portlet implementation would go to core. I think that CocoonPortlet (JSR-168 portlet implementation) and portal block are two different things. CocoonPortlet makes cocoon

RE: [Portal] Question: Why JSR-168 portlet impl moved?

://marc.theaimsgroup.com/?t=10771857645r=1w=2 Thanks Carsten -Original Message- From: DURDINA Michal [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 3:58 PM To: [EMAIL PROTECTED] Subject: [Portal] Question: Why JSR-168 portlet impl moved? Hi, I am curious why