Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Message-ID: <403CFB1B.9070105@leverageweb.com>
Date: Wed, 25 Feb 2004 14:44:27 -0500
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: ESQL update and select statements in the same map:match problem
References: 
 <OF17D41A73.6A5145E0-ON85256E45.0068BA4A-85256E45.006A7E12@notes.duke.edu>
In-Reply-To: 
 <OF17D41A73.6A5145E0-ON85256E45.0068BA4A-85256E45.006A7E12@notes.duke.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It's not a bug -- and I wouldn't recommend using a workaround like the 
one below (which would probably work).  Don't try to modify the data 
model while it's being turned into sax (the job of the generator).  
Other non-MVC friendly frameworks force this but Cocoon almost forces 
you not to because of all the problems it can cause in real-world 
applications.

In your case, either use flow to call logic which modifies your database 
(beyond scope of my response) or use an action.  Actions and flow are 
both guaranteed to execute before the pipeline is assembled and are 
designed to be the place for data manipulation (with the exception of 
the side-effect transformers like the SQLTransformer, also out of 
scope).  If you already have an xsp which does the job, turn it into an 
xsp action and you're done.

Geoff


Christopher Painter-Wakefield wrote:

>
>
>I don't know anything about the internal workings of the map:aggregate, but
>I would guess it is not waiting for the first part to complete before
>opening a connection for the second part.  This would make sense, for
>performance reasons, and there is no particular reason for cocoon to expect
>the parts to be dependent on each other.  So I don't think it is
>necessarily a bug, nor a caching mechanism, just that map:aggregate doesn't
>imply sequential processing.
>
>Just curious, should the map:aggregate have an "element" attribute
>specifying the root element for the combined output?  Also, what does
>"strip-root='yes'" do?  I couldn't find it in the documentation
>(http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Aggregating).
>
>You could probably make things sequential (and still achieve aggregation)
>by using either a cinclude transformer, or even more simply by using an
>XSLT transform step with the document() function, e.g.,
>...
><xsl:template match="output-of-update-point">
>      <new-root>
>            <xsl:copy-of select="."/>
>            <xsl:copy-of select="document('cocoon:/xml/exec.get_point')"/>
>      </new-root>
></xsl:template>
>...
>
>with a sitemap like
><map:generate src="cocoon:/xml/exec.update_point"/>
><map:transform src="aggregate-get-point.xsl"/>
>
>or some such.
>
>-Christopher
>
>hi people
>
>i have the folow code :
>
><map:aggregate>
>             <map:part src="cocoon:/xml/exec.update_point"
>strip-root="yes"/>
>             <map:part src="cocoon:/xml/exec.get_point" strip-root="yes"/>
></map:aggregate>
>
>where i call 2 .xsp
>
>1. update_point.xsp
>where i update a record in my database
>
>2. get_point.xsp
>where i get the updated record
>
>the problem is that this aggregation update the database record (i have
>check the content) but generate output (get_point) with the before update
>values
>
>is this a caching mechanism case, is it possible to bypass this problem or
>it's just a bug?
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org