cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: REST / Can't find URLResponseBuilder
Date Tue, 01 Dec 2009 16:20:40 GMT
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<String, 
> 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
>>
>>   
>


Mime
View raw message