Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Identifier used in FragmentExtractorTransformer
Date: Fri, 21 Oct 2005 08:54:55 +0200
Message-ID: <5E091A68F794974CAF431CA31F5AF2CC3C4F64@server.bizzdesign.nl>
Thread-Topic: Identifier used in FragmentExtractorTransformer
Thread-Index: AcXVpSxL0aY8mZdFTVGlIk1I/HmjnQAZuUkQ
From: "Bart Molenkamp" <b.molenkamp@bizzdesign.nl>
To: <dev@cocoon.apache.org>

Hi,

How is this problem related to caching? It is not that hard for me to =
provide a patch which just generates a new identifier, but I'm wondering =
if it breaks caching...

Bart.

> -----Oorspronkelijk bericht-----
> Van: Joerg Heinicke [mailto:joerg.heinicke@gmx.de]
> Verzonden: donderdag 20 oktober 2005 20:35
> Aan: dev@cocoon.apache.org
> Onderwerp: Re: Identifier used in FragmentExtractorTransformer
>=20
> On 20.10.2005 15:15, Bart Molenkamp wrote:
>=20
> > My problem is that the id is based on the request uri (and the =
number of
> > fragments that it extracts during a single transformation). The =
problem
> > is that the contents of an XML document, and the content of the SVG
> > image in that document (some chart generated from a database query) =
is
> > different for each user calling that page. But the request uri is =
always
> > the same, thus the ID for each extracted fragment is also always the
> > same, resulting in each extracted fragment being overwritten in the
> > transient store.
> >
> > This has some nasty side-effects, e.g. when using the browser's back
> > button, or even the possibility to have charts displayed from other
> > users.
> >
> > Therefore, I think it is good to change the way that id's are =
generated.
> > I was thinking to move the current ID generating code into a =
protected
> > method, and those who want other ID generation can extend the
> > transformer and overwrite the method.
> >
> > Is this a good idea, and if so, shall I provide a patch? Can it be
> > applied before the 2.1.8 release?
>=20
> http://issues.apache.org/bugzilla/show_bug.cgi?id=3D28724
>=20
> J=F6rg