From dev-return-101972-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Tue Dec 01 16:20:56 2009 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 90471 invoked from network); 1 Dec 2009 16:20:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Dec 2009 16:20:56 -0000 Received: (qmail 62515 invoked by uid 500); 1 Dec 2009 16:20:55 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 62411 invoked by uid 500); 1 Dec 2009 16:20:55 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 62403 invoked by uid 99); 1 Dec 2009 16:20:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2009 16:20:55 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [88.198.46.98] (HELO indoqa.com) (88.198.46.98) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2009 16:20:52 +0000 Received: from [192.168.20.30] (pluto.systemone.at [85.124.93.178]) by indoqa.com (Postfix) with ESMTP id CF9D71A0001 for ; Tue, 1 Dec 2009 17:20:31 +0100 (CET) Message-ID: <4B154258.7020600@indoqa.com> Date: Tue, 01 Dec 2009 17:20:40 +0100 From: Steven Dolg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: REST / Can't find URLResponseBuilder References: <1259380920.2884.9.camel@luna> <1259390633.2656.5.camel@joske-laptop> <1259414045.2884.90.camel@luna> <1259476360.2654.5.camel@joske-laptop> <1259497147.2884.102.camel@luna> <4B1540CF.1070401@indoqa.com> In-Reply-To: <4B1540CF.1070401@indoqa.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Steven Dolg schrieb: > Johannes Lichtenberger schrieb: >> On Sun, 2009-11-29 at 07:32 +0100, Jos Snellings wrote: >> >>> In the samples, a typical use of StringTemplate is shown: a page is to >>> be interpreted by the StringTemplate engine, and a number of properties >>> are passed via the hashtable. >>> The idea is that you would open a view on the object. >>> So, - the query points to a resource >>> - the controller decodes what the resource is and what you want (view >>> it, update it?) >>> - the way to view it could be: pass my resource to a StringTemplate >>> invocation: new Page('stringtemplateinvocation',resource); >>> >>> However, I have not tried to elaborate this so far. Shall I post it >>> when >>> i have a useable example? >>> >> >> Yes it would be great. My concern is that I don't want to display a >> template page. I want to process the request (the parameters Google >> Earth sends when zooming in) and within my Generator query a native XML >> database system and built the algorithmic logic inside the generator >> (what data out of the shreddered xml file is needed and has to be >> transformed with an XSLT stylesheet). So I basically know how RESTful >> webservices work, but I don't know how to use cocoon3 in this case (I >> assume new Page(...) isn't the right thing to return when I just want to >> pass the request params to my generator. So I don't want to use >> StringTemplate in this case (but it's nontheless a great thing). So the >> query points to a controller, which decides that it's a GET request >> (view) and passes the parameters on to my generator (which I still have >> to write). >> Would be great if you or someone else could help me out (it's a project >> in a course of our university ;-) and I thought cocoon is great for this >> concern (get RESTful parameters, hand it on to a generator which selects >> the needed data out of a shreddered xml file according to the >> parameters, then transform the xml fragments with a XSLT stylesheet and >> serialize the result, so that Google Earth can use the KML fragments >> generated). >> > > Hi, > > I'm not entirely sure I understand what you want to do (or to be more > precise which parts already exist and which don't), but I'll try to > improvise. I just found your other mail from earlier ("REST / own generator") and it seems your only problem is to access the HTTP request parameters. If that's the case ditch the controller and access them in your generator like I explained in the first approach below. They are already there - no need to use a controller to make them accessible... > I can imagine two approaches: > > 1. > You can access HTTP request parameters from a generator (or any other > PipelineComponent - a Controller is just a fancy PipelineComponent) as > well. > The SitemapServlet will add all HTTP request parameters to the > invocation that is built to handle the request and will be passed to > every PipelineComponent in the > "org.apache.cocoon.pipeline.component.PipelineComponent.setup(Map Object>)" method. The keys will be the names of the HTTP request > parameters. > Read the parameters in your generator, and then perform the rest of > your logic. > > > 2. > Keep the controller and do all pre-processing necessary within the > controller: the XML DB, XSLT (if you just want to use XLST have a look > at org.apache.cocoon.sax.util.TransformationUtils) etc. > When you are ready, store the data required for your generator in a > parameter map (just like you did in the code fragment you posted) and > delegate to a pipeline that uses your generator. > The generator will be able to access the data the same way I described > above. > Only difference would be that in this case the key would be defined by > your controller, while in the approach above the key would be > determined by the name of the HTTP request parameter. > > > hth, > Steven > >> Thank you, >> Johannes >> >> >