Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 14884 invoked from network); 13 Dec 2000 09:36:31 -0000 Received: from pns.dff.st (HELO mail.dff.st) (62.153.127.51) by locus.apache.org with SMTP; 13 Dec 2000 09:36:31 -0000 Received: from mail.dff.local ([172.16.1.10]) by mail.dff.st with esmtp (Exim 3.14 #3) id 1469F1-0004ld-00 for cocoon-dev@xml.apache.org; Wed, 13 Dec 2000 11:34:31 +0100 Received: from shodan.dff.local ([172.16.2.1] helo=shodan) by mail.dff.local with smtp (Exim 3.16 #3) id 1468KS-0006zQ-00 for cocoon-dev@xml.apache.org; Wed, 13 Dec 2000 10:36:04 +0100 From: "Torsten Curdt" To: Subject: RE: XSPGenerator Date: Wed, 13 Dec 2000 10:36:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20001212180146.D11067@hydrogen.internal.luminas.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > On Tue, Dec 12, 2000 at 06:38:09PM +0100, Torsten Curdt wrote: > > Guys, guys, guys... Still.. > > Will we then be able to control what to be aggregated > > via XSP(!)? I think this important! (At least for me!) > > Can you explain why you think this is necessary? Give me an > example to play with? We actually need it for form processing (to show errors without redirects) but I think there are other examples as well. What if you have several page parameters and need to do a complex calculation (whatever) to decide what to show. Lets say ..hmm... I have users in a database. And if one of them has it's birthday today, I want to include a HappyBirthday.xml (sorry, pretty stupid ;) ..but how can you do this without the ability to modify the include fiel via XSP? I just read the post from Robin and if it will be possible with then I'm fine :) Although I'm not so sure if (and when why) we need two different mechanisms... (two things to maintain) -- Torsten