You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Steven Dolg <st...@indoqa.com> on 2009/12/01 22:21:29 UTC
Re: REST / Can't find URLResponseBuilder
Jos Snellings schrieb:
> If I understand you well, your assignment is to:
>
> * catch a get URL emitted by Google Earch
> * this url contains coordinates
> * on the basis of these coordinates you lookup things in an XML file.
>
> Here's my advice: forget about the RESTController and just write a
> generator, like:
> public class SehensWuerdigkeitenGenerator extends AbstractSAXGenerator
> implements CachingPipelineComponent {
>
> @SitemapParameter
> private String language;
>
> @SitemapParameter
> private String cmd;
>
> private String pur;
> private String par;
>
> private HttpServletRequest request;
>
Well I agree that this looks very nice, unfortunately the
@SitemapParameter annotation is only available in the REST module of
Cocoon and only working for Controllers.
A meaningful explanation would include the layered approach and
assumptions about the environment - I'll do this another time.
However the intended way would be:
for Parameters retrieved through the sitemap
@Override
public void setConfiguration(Map<String, ? extends Object> parameters) {
this.language = (String) parameters.get("language");
}
for Parameters retrieved through the actual invocation (e.g. HTTP request)
@Override
public void setup(Map<String, Object> parameters) {
this.cmd = (String)parameters.get("cmd");
}
> And you do the interesting bits within:
>
> public void execute() {
> -> read your bits
> SAXConsumer consumer = this.getSAXConsumer();
> try {
> consumer.startDocument();
>
> consumer.startElement("", "page", "page", new
> AttributesImpl());
> ---> do the interesting stuff to be sent to XSLT
> }
>
> Oh, by the way, another possibility: just read your XML file if it's
> just one. And extract the chunks you need in the XSLT transform, with
> XPath. The last could be the shorter.
>
> Mmmm you are a student. I am an old man and I would say: bear in mind
> that 'REST' is just another concept, sometimes java people like to make
> things complicated... "Why make things simple and efficient if you can
> make them complex and wonderful".
>
And now I know where this marvelous quote is from.
Well done, old man! :-P
Steven
> By the way, I will redirect this discussion to cocoon users.
>
> Cheers,
> Jos
>
>
>
>
>
> On Sun, 2009-11-29 at 13:19 +0100, Johannes Lichtenberger wrote:
>
>> 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).
>>
>> Thank you,
>> Johannes
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: REST / Can't find URLResponseBuilder
Posted by Jos Snellings <Jo...@pandora.be>.
O yes, you are right! It dates from a couple of trials in alpha-1,
when I was having trouble to make setup() work. Thanks.
Jos
On Tue, 2009-12-01 at 22:21 +0100, Steven Dolg wrote:
> Jos Snellings schrieb:
> > If I understand you well, your assignment is to:
> >
> > * catch a get URL emitted by Google Earch
> > * this url contains coordinates
> > * on the basis of these coordinates you lookup things in an XML file.
> >
> > Here's my advice: forget about the RESTController and just write a
> > generator, like:
> > public class SehensWuerdigkeitenGenerator extends AbstractSAXGenerator
> > implements CachingPipelineComponent {
> >
> > @SitemapParameter
> > private String language;
> >
> > @SitemapParameter
> > private String cmd;
> >
> > private String pur;
> > private String par;
> >
> > private HttpServletRequest request;
> >
>
> Well I agree that this looks very nice, unfortunately the
> @SitemapParameter annotation is only available in the REST module of
> Cocoon and only working for Controllers.
> A meaningful explanation would include the layered approach and
> assumptions about the environment - I'll do this another time.
>
> However the intended way would be:
>
> for Parameters retrieved through the sitemap
>
> @Override
> public void setConfiguration(Map<String, ? extends Object> parameters) {
> this.language = (String) parameters.get("language");
> }
>
>
> for Parameters retrieved through the actual invocation (e.g. HTTP request)
>
> @Override
> public void setup(Map<String, Object> parameters) {
> this.cmd = (String)parameters.get("cmd");
> }
>
>
>
> > And you do the interesting bits within:
> >
> > public void execute() {
> > -> read your bits
> > SAXConsumer consumer = this.getSAXConsumer();
> > try {
> > consumer.startDocument();
> >
> > consumer.startElement("", "page", "page", new
> > AttributesImpl());
> > ---> do the interesting stuff to be sent to XSLT
> > }
> >
> > Oh, by the way, another possibility: just read your XML file if it's
> > just one. And extract the chunks you need in the XSLT transform, with
> > XPath. The last could be the shorter.
> >
> > Mmmm you are a student. I am an old man and I would say: bear in mind
> > that 'REST' is just another concept, sometimes java people like to make
> > things complicated... "Why make things simple and efficient if you can
> > make them complex and wonderful".
> >
>
> And now I know where this marvelous quote is from.
> Well done, old man! :-P
>
>
> Steven
>
> > By the way, I will redirect this discussion to cocoon users.
> >
> > Cheers,
> > Jos
> >
> >
> >
> >
> >
> > On Sun, 2009-11-29 at 13:19 +0100, Johannes Lichtenberger wrote:
> >
> >> 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).
> >>
> >> Thank you,
> >> Johannes
> >>
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org