Menu
▾
▴
RE: [Openinteract-help] Using several content-generators for one action?
|
From: Kutter M. <mar...@si...> - 2004-10-08 06:58:47
|
Hi Heiko !
...after a while of thinking, I got the idea that you actually suggested
something different (sorry that I didn't get this before): a request handler
that can handle different types of requests (like SOAP, WWW-Form).
This would mean an end to the need of a separate entry point for SOAP
requests, and allow to return an error if a user tries to access an action
returning SOAP-Content via a browser, or an action returning HTML (or PDF or
whatever) content via SOAP.
This would mean that you could access your actions by whatever way you like,
and always get a correct response:
Accessed by: Browser SOAP
Page Result
http://myoi.com/action.html HTML Page SOAP Fault
http://myoi.com/action.soap HTML Error page SOAP Response
http://myoi.com/action.pdf PDF file SOAP Fault
How this is configured in the action config should be a secondary issue.
Regards,
Martin Kutter
-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of
Kutter Martin
Sent: Mittwoch, 6. Oktober 2004 16:58
To: ope...@li...
Subject: RE: [Openinteract-help] Using several content-generators for
one action?
Hi Heiko
> 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"?
...it's not quite a proxy-URL. It's just another entry point for OI2 (like
CGI, Standalone or Apache are).
And the SOAP request handler allows to access different actions at the same
URL by specifying the Action as SOAP method URI. This is somewhat common for
web Services, though it is not REST-design.
...and you don't need a _soap suffix for actions which use a SOAP Content
generator.
You can just call them whatever you like.
OI actions are *not* namespaces - they are just URL-snippets like /action/
to the user
and a lookup table with associated modules for OI2.
> .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.
I have - and windows usually does know the MIME-type application/pdf and
thus handle the associated document correctly.
I think this argument is raising to a philosophical level: You would like
[action]
class FOO
content-generator BAR
content-generator FOOBAR
content-gererator BAZ
The current implementation does
[action]
class FOO
content-generator BAR
[someotheraction]
class FOO
content-generator FOOBAR
[onemoreaction]
class FOO
content-generator BAZ
These implementations are almost equal in terms of functionality - where you
have
http://url/action.bar
http://url/action.foobar
http://url/action.baz
in the first variant, you have
http://url/action
http://url/someotheraction
http://url/onemoreaction
If OI2 would support the '.' character in action names (I don't know if it
does) , you could even do
[action.bar]
class FOO
content-generator BAR
[action.foobar]
class FOO
content-generator FOOBAR
[action.baz]
class FOO
content-generator BAZ
with
http://url/action.bar
http://url/action.foobar
http://url/action.baz
in the second one.
The only difference is the config file - and if you specify which task is
valid for which content generator, config file complexity and length is
equal for both variants.
Regards,
MArtin Kutter
-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of Heiko
Klein
Sent: Mittwoch, 6. Oktober 2004 16:20
Cc: ope...@li...
Subject: Re: [Openinteract-help] Using several content-generators for
one action?
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.
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
>
>
-------------------------------------------------------
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
|
