Return-Path: 
 <dev-return-87533-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 59131 invoked from network); 24 May 2006 16:18:56 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 24 May 2006 16:18:56 -0000
Received: (qmail 33895 invoked by uid 500); 24 May 2006 16:18:49 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 33715 invoked by uid 500); 24 May 2006 16:18:48 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 33626 invoked by uid 99); 24 May 2006 16:18:48 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 May 2006 09:18:48 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of peter.hunsberger@gmail.com
 designates 64.233.184.227 as permitted sender)
Received: from [64.233.184.227] (HELO wr-out-0506.google.com) (64.233.184.227)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 May 2006 09:18:47 -0700
Received: by wr-out-0506.google.com with SMTP id 69so1611026wra
        for <dev@cocoon.apache.org>; Wed, 24 May 2006 09:18:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=eV+hayyH93p38eLWclKAOcN+oRLT6NUI/4uc8MRDRbq2V47Bi6fK5nknPEuwnEde+I/VgdNgIXnTke/wppNbtJ6XyqHH3XtwZZAapXg9hOaEdghJGy4Y24/lIQTJtmhZIvI8T3AJUJp3x5zUlY5vTVJ5oFTzyPXznR2detk/fD4=
Received: by 10.54.160.15 with SMTP id i15mr4485538wre;
        Wed, 24 May 2006 09:18:26 -0700 (PDT)
Received: by 10.54.103.4 with HTTP; Wed, 24 May 2006 09:18:26 -0700 (PDT)
Message-ID: <cc159a4a0605240918v45ddc775pfd10aae3521b2de6@mail.gmail.com>
Date: Wed, 24 May 2006 11:18:26 -0500
From: "Peter Hunsberger" <peter.hunsberger@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: Pattern for use of sub-pipelines to grab content at different
 stages?
In-Reply-To: <447473DE.1010102@arielpartners.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <4473F06A.9050706@arielpartners.com>
	 <cc159a4a0605240656h7f4caeb5p8217a45781b71077@mail.gmail.com>
	 <447473DE.1010102@arielpartners.com>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

On 5/24/06, Craeg Strong <cstrong@arielpartners.com> wrote:
> Hello:
>
> Thanks for the informative reply!
>
> Peter Hunsberger wrote:
> > On 5/24/06, Craeg Strong <cstrong@arielpartners.com> wrote:

<snip/>

>  my master plan is to replace Struts with Cocoon in a massive
> J2EE application.
> The application supports the custom display requirements of 150
> different labor unions so it is really more like a product line than a
> product

This is essentially what we do, but with the cache organization like I
described.  (We produce 1000's of dynamically customized pages;
medical data presented differently for each treatment protocol and
dependant on the authorizations of the user viewing the data.)

Remember, the final page will only be cacheable to the extent that any
of the components are cacheable.  Thus, if you create a header that
can be cached for 1 hour and footer that can be cached for 5 days the
page will only be cached for 1 hour. Producing the footer ahead of
time didn't buy you anything...

What you want is user specific data components, not user specific
presentation components.  The presentation is the last thing to go out
the pipeline (the final set of assembled data components).    Don't
think in terms of HTML, think in terms of XML that can easily be
converted into HTML.  The HTML presentation details are in the final
XSLT.  The XML data components are what are aggregated (and cached).

That's not to say the final result can't be cached.  It can, but it's
cache validity is only as good as the cache validity of that of the
shortest lived data component.

I know this is a bit orthogonal to the way a lot of front end people
think. But it makes sense from an EJB point of view; what is the cycle
time of the entities and session beans?

<snip/>

> I just have to make sure that each of the generators in the cacheable
> sub-pipeline is itself cacheable and generates the session id as a
> caching key.
>
> Am I on the right track?

Yup, you got it.

--=20
Peter Hunsberger