Re: [Openinteract-help] Using several content-generators for one action?

[Heiko K. <Hei...@gm...>]

Hi Martin,

except the point, that you might not like to support all methods with 
all content-generators, I don't agree with your points.

Your current SOAP implementation (which I like) needs a proxy-url (i.e. 
http://my.oi2.com/WebServices) to get to get the correct soap-request 
handler. Only calls to that proxy should give you back a useable 
soap-response.) Why should then all URIs (soap-namespaces) contain in 
addition the _soap flag, i.e. "http://my.oi.com/action_soap"?

Calling directly http://my.oi.com/action with SOAP without the correct 
Proxy will still give you a html-page (and thus an error).


.html should be the default-type for all pages, so http://my.oi.com 
still functions, no requirement on a index.html. For .pdf files, you 
will need the http://my.oi.com/index.pdf. This requirement isn't that 
large. I have never seen a web-site delivering a pdf-page without a .pdf 
ending. I'm not even sure if the windows plugin handler will handle it 
without a .pdf at the end.


For an API to all OI-functionality, it would be nice to have the 
request-handler determine the request-type, even when some functionality 
is quite useless for some methods (your web-form example). One thing i 
must admit: The OI action/methods have been designed for web-pages, it 
is quite likely that it is not suitable for an API, where you would like 
to bundle the functionality. Thus it would feel quite natural to write 
own actions for a SOAP request.

Since I'm lazy, I think my idea would be quite easy enough to implement 
and would immediately give full access to the whole functionality which 
exists in the web-pages. It would be easy enough to switch off a 
content-generator for a action and add a own content-generator to a 
method as [action_soap].

Best wishes,

Heiko



Kutter Martin wrote:
> Hi Heiko,
> 
> OI2's solution is maybe technical, but does not have any impacts asides from
> a few more lines in the config file.
> 
> The config
> 
> [foo]
> content-generator = TT
> class = MyFoo::Action
> 
> [fooWebService]
> content-generator = SOAP
> class = MyFoo::Action
> 
> direct both actions to the same perl module.
> 
> There is no need to include the name of the content generator in the
> action's name - it was just an example.
> For an end user, an OI2 action is just a URL-snippet - and SOAP programmers
> definitely won't regard an URL containing something like '_soap' or
> 'WebService' or the like as strange - it's rather normal.
> 
> Delegating Content-Generator switching to the Request Handler has some
> serious disadvantages:
> 
> - Your suggestion would accept requests for all content handlers on the same
> URL.
> If you access an URL hosting a WWW-(HTML)-page with a SOAP-Call, (or a
> SOAP-Webservice with a browser) you would expect this call to fail or be at
> least non-functional.
> Your suggestion would change this.
> 
> Moreover, Requests from a Browser and SOAP-Requests could be required to use
> different authentications (e.g. normal Username/Password for WWW-Forms,
> Client SSL Certificate for SOAP). This is very hard to implement for
> different contents on the same URL (Apache can handle this for different
> URLs).
> 
> Determining the request type from the request content is rather difficult,
> if at all possible. The SOAP protocol defines not only a "Request-Response"
> model with SOAP request & SOAP response, but also a "Response" model, where
> the request is a simple HTTP GET (This is not supported by the current OI2
> SOAP implementation). I don't know how you would find out whether a GET on
> the same URL is meant for a SOAP content generator or a PDF content
> generator.
> 
> - Making the Request handler decide about Content Generation would expose
> all tasks of an action via all content generators (or introduce the same
> configuration overhad different actions do).
> This is to be avoided: Maybe you do not want to make some functions
> accessible via other means than SOAP, and maybe you don't want some other
> pages accessible via SOAP or PDF content generators (Forms for editing data
> are a classical WWW-Form-only example).
> 
> - The need for all "HTML" requests to match /\.html$/ and all PDF requests
> match /\.pdf$/ is a very artificial requirement almost never seen on
> web-servers on the internet. Or would you expect that e-bay would require
> you to request http://www.ebay.com/index.html instead of http://www.ebay.com
> as a start page ? 
> 
> This would confuse end-users more than having to access different URLs for
> PDF, HTML and SOAP version (something quite general: The usual "print
> version" link on lots of pages).
> 
> In my opinion, the current scheme has enough power to handle most scenarios.
> I don't think a request-type aware RequestHandler would bring more benefits
> than disadvantages.
> 
> Regards,
> 
> Martin Kutter
> 
> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf Of Heiko
> Klein
> Sent: Mittwoch, 6. Oktober 2004 10:51
> To: ope...@li...
> Subject: Re: [Openinteract-help] Using several content-generators for
> one action?
> 
> 
> Hmmm,
> 
> declaring a different action for a different content-generator is a
> rather technical than user-friendly solution. I guess we will end up
> with something like:
> 
> [foo]
> content-generator = TT
> 
> [foo_soap]
> content-generator = SOAP
> 
> [foo_wap]
> content-genertor = WAP
> 
> [foo_pdf]
> content-genertor = GS-PDF
> 
> 
> and we will have to write a lots of stuff for each of these action.
> Since a action is more of a class or namespace for a method, I don't see
> why it needs to include the content generator.
> 
> [foo_soap] needs a SOAP response and request generator. The soap API
> user will think its very strange that all namespaces have _soap included.
> 
> [foo_pdf] and [foo_wap] will most likely have a request for something
> ending with .pdf as an ending. (At least, nobody would think it's
> strange when you require this.)
> 
> 
> Without having looked closely at the code yet, I would make the request
> generator determine the content-type. After setting some default (most
> likely to .html), when the request ends with .pdf to pdf and with .wap
> to wap. SOAP has a different request-generator, so it will be very easy
> to set the content-type to soap there.
> 
> The only situation, where you will need different actions is when you
> want to present the same content-type (html) with different
> html-content-generators - IMHO not a very common situation in
> production. (In testing, sure this will happen, but for test-pages I
> want to have the possibilty to switch between foo_TT and foo_HTMLTemplate.)
> 
> So, if it makes sense, it is a feature request to implement several
> content-generator determined by content-type per action:
> [foo]
> content-generator default = TT
> content-generator soap = SOAP
> content-generator pdf = GS-PDF
> ....
> (don't know if this is parseable by the .ini-reader)
> 
> Best regards,
> 
> Heiko
> 
> Chris Winters wrote:
> 
>>>I'm currently trying out Martin Kutters SOAP add on for OpenInteract2.
>>>My idea is to use soap as remote API for OI2. Thus I would like to have
>>>two content-generators for all packages, one giving the usual
>>>html-response, and the other one giving a soap response.
>>
>>
>>That's been my idea for SOAP as well.
>>
>>
>>
>>>When I understand the current implementation of OI correct, then it is
>>>in principle possible to have several content generators in OI, but one
>>>action has exactly one content generator, defined by the action.ini
>>>file, not by the Response-type. I hope I'm wrong with this assumption,
>>>so my question is, how do I enable different content-generators for one
>>>action? Or is my understanding of an 'action' wrong?
>>
>>
>>Your understanding is right. But I think what's missing is you can map
>>multiple action specifications to the same class. For instance in an
>>action.ini you might have:
>>
>>[foo]
>>class = OpenInteract2::Action::Foo
>>content_generator = TT
>>
>>[bar]
>>class = OpenInteract2::Action::Foo
>>content_generator = SOAP
>>
>>The same data are retrieved from the action + task, but they're passed off
>>to a different content generator depending on how they were invoked. Make
>>sense?
>>
>>The 'news' package has some commented-out examples of doing this with
>>Text::Template and HTML::Template.
>>
>>
>>
>>>And in some packages, I haven't seen the content_generator flag in the
>>>action.ini. Where is the default defined?
>>
>>
>>In server.ini:
>>
>>[action_info default]
>>controller         = tt-template
>>content_generator  = TT
>>
>>Hope this helps,
>>
>>Chris
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> openinteract-help mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-help
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> openinteract-help mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-help
> 
>