Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 81285 invoked from network); 12 Nov 2003 23:48:26 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 12 Nov 2003 23:48:26 -0000 Received: (qmail 70199 invoked by uid 500); 12 Nov 2003 23:48:08 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 70151 invoked by uid 500); 12 Nov 2003 23:48:08 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 70138 invoked from network); 12 Nov 2003 23:48:08 -0000 Received: from unknown (HELO sati.virbus.de) (145.253.246.81) by daedalus.apache.org with SMTP; 12 Nov 2003 23:48:08 -0000 Received: from sati.virbus.de (localhost [127.0.0.1]) by localhost (SMTP Server) with ESMTP id CD964166ABC for ; Thu, 13 Nov 2003 00:48:14 +0100 (MET) Received: from virbus.de (a183069.studnetz.uni-leipzig.de [139.18.183.69]) by sati.virbus.de (SMTP Server) with ESMTP id 948CB166AB6 for ; Thu, 13 Nov 2003 00:48:14 +0100 (MET) Message-ID: <3FB2C6F8.9080502@virbus.de> Date: Thu, 13 Nov 2003 00:49:12 +0100 From: Joerg Heinicke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-de, de, en-us, en-gb, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Revised ResourceLoadAction posted... References: <3FB24D0B.19520.D90937@localhost> <3FB2B3A0.1070700@verizon.net> In-Reply-To: <3FB2B3A0.1070700@verizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On 12.11.2003 23:26, Vadim Gritsenko wrote: >>> I've updated my ResourceLoadAction so that it optionally will save >>> the resource stream data (as a string) in your session/request with a >>> given attribute name. >> >> >> >> Technically speaking now, have you considered using output modules to >> indicate where the resource should be loaded? This should be more >> versatile than a fixed choice between session and request. > > > > Had anybody considered writing some dom:/ pseudo protocol to > save/retrieve DOM fragments to/from request / session / application > context? We have a Read/WriteDomSessionTransformer (for which Andrzej provided also a patch) doing this stuff. You mean replacing them with a dom pseudo protocol for simplicity and transparency? Sound good. Joerg