openinteract-help — For new and current users, we offer support, troubleshooting and assistance.

Re: [Openinteract-help] mod_perl_solo setup disables php

[<me...@st...>]

>>>>> "Richard" == Richard Hubbell <ric...@gm...> writes:

Richard> AddType application/x-httpd-php .php .phtml .php3 .html .htm

This is where you're getting in to trouble.  "A man cannot serve two
masters".  You need to pick ".html" as either a PHP file or a mod_perl
file.  Choose wisely.  Of course, you can narrow your choice by
Directory or by Location, but you still need to choose.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: [Openinteract-help] mod_perl_solo setup disables php

[Richard H. <ric...@gm...>]

On Wed, 23 Mar 2005 09:58:09 -0500, Chris Winters <ch...@cw...> wrote:
> * Richard Hubbell (ric...@gm...) [050322 18:18]:
> > Using a mod_perl server (no proxy) with OI and when I enable the
> > Include /oi/website/httpd_modperl_solo.conf and restart the server
> > I lose php.
> >
> > From the apache/conf/error_log file:
> > (using  Include /oi/website/httpd_modperl_solo.conf )
> >
> > Apache/1.3.31 (Unix) mod_perl/1.29 configured -- resuming normal operations
> >
> > (not using  Include /oi/website/httpd_modperl_solo.conf )
> >
> > Apache/1.3.31 (Unix) mod_perl/1.29 PHP/4.3.8 configured -- resuming
> > normal operations
> >
> > What's going on here?
> 
> I've never seen this before. Does PHP actually not work after you've
> brought in mod_perl functionality? (I'm not sure of the relationship

PHP and mod_perl worked fine until I 
Include httpd_modperl_solo.conf

I found a solution but have run into another problem (see below).
The solution was to do this: ( load php after include )

apache/conf/httpd.conf:

Include /oi/website/conf/httpd_modperl_solo.conf

LoadModule php4_module        libexec/libphp4.so

AddType application/x-httpd-php .php .phtml .php3 .html .htm
AddType application/x-httpd-php-source .phps



> between being advertised in the server-info line and actually
> working...)

lsof shows me that the php .so was loaded but php was not
working.

> 
> The next thing to do is whittle it down to the simplest case. What if
> you comment out the OI2 stuff (the PerlRequire and pointer to
> Apache::OpenInteract2) and make a super-simple mod-perl handler. Does
> the same result occur?

See above.

The other problem I see now is that if I go to "System Documentation" page
and click on "View OpenInteract Documentation" it wants to save the index.html
as a file  (it opens the save file as dialog box in my browser).  


Thanks.

Richard

> 
> If so, I'd ping the mod_perl mailing list for help:
> 
>   http://perl.apache.org/maillist/modperl.html
> 
> Chris
> 
> --
> Chris Winters (http://www.cwinters.com)
> Building enterprise-capable snack solutions since 1988
>

Re: [Openinteract-help] mod_perl_solo setup disables php

[Chris W. <ch...@cw...>]

* Richard Hubbell (ric...@gm...) [050322 18:18]:
> Using a mod_perl server (no proxy) with OI and when I enable the
> Include /oi/website/httpd_modperl_solo.conf and restart the server
> I lose php.
> 
> From the apache/conf/error_log file:
> (using  Include /oi/website/httpd_modperl_solo.conf )
> 
> Apache/1.3.31 (Unix) mod_perl/1.29 configured -- resuming normal operations
> 
> (not using  Include /oi/website/httpd_modperl_solo.conf )
> 
> Apache/1.3.31 (Unix) mod_perl/1.29 PHP/4.3.8 configured -- resuming
> normal operations
> 
> What's going on here?  

I've never seen this before. Does PHP actually not work after you've
brought in mod_perl functionality? (I'm not sure of the relationship
between being advertised in the server-info line and actually
working...)

The next thing to do is whittle it down to the simplest case. What if
you comment out the OI2 stuff (the PerlRequire and pointer to
Apache::OpenInteract2) and make a super-simple mod-perl handler. Does
the same result occur?

If so, I'd ping the mod_perl mailing list for help:

  http://perl.apache.org/maillist/modperl.html


Chris


-- 
Chris Winters (http://www.cwinters.com)
Building enterprise-capable snack solutions since 1988

[Openinteract-help] mod_perl_solo setup disables php

[Richard H. <ric...@gm...>]

Hi all,

Using a mod_perl server (no proxy) with OI and when I enable the
Include /oi/website/httpd_modperl_solo.conf and restart the server
I lose php.

From the apache/conf/error_log file:
(using  Include /oi/website/httpd_modperl_solo.conf )

Apache/1.3.31 (Unix) mod_perl/1.29 configured -- resuming normal operations



(not using  Include /oi/website/httpd_modperl_solo.conf )

Apache/1.3.31 (Unix) mod_perl/1.29 PHP/4.3.8 configured -- resuming
normal operations


What's going on here?  


Thanks.
Richard

Re: [Openinteract-help] sending files to user

[Chris W. <ch...@cw...>]

* Cornel Ghiban (un...@gm...) [050316 09:33]:
> I'm trying to send a file to user using OI like this:
>
> sub my_download {
>             # ..............
>             open(F,$filepath) or return NOT_FOUND; # file not found
>             my $r = $R->apache;
>             $r->no_cache(1);
>             $r->content_type('application/octet-stream');
>             $r->headers_out->set(
>                 'Content-disposition' => 
> 'attachment;filename='.$fileName);
>             $r->send_http_header;
>             $r->send_fd(\*F);
>             close(F);
>
>             return OK;
> }
>
> I get the file ok,  but I also get the HTML output from OI and the
> file which is saved on the disk is not usable.
> What can I do to get only the file and nothing else?

OI already has the facility to send a file -- all you should need to
do is this:

sub my_download {
     $R->{page}{send_file} = $filepath;
     $R->{page}{content_type} = 'application/octet-stream';
     my $r = $R->apache;
     $r->no_cache(1);
     $r->headers_out->set(
       'Content-disposition' => 'attachment;filename='.$fileName
     );
}

You can find the code where we send the file in
OpenInteract->send_static_file().

Chris

-- 
Chris Winters (http://www.cwinters.com)
Building enterprise-capable snack solutions since 1988


--
Chris Winters
Creating enterprise-capable snack systems since 1988

[Openinteract-help] sending files to user

[Cornel G. <un...@gm...>]

Hi,

I'm trying to send a file to user using OI like this:

sub my_download {
            # ..............
            open(F,$filepath) or return NOT_FOUND; # file not found
            my $r = $R->apache;
            $r->no_cache(1);
            $r->content_type('application/octet-stream');
            $r->headers_out->set(
                'Content-disposition' => 'attachment;filename='.$fileName);
            $r->send_http_header;
            $r->send_fd(\*F);
            close(F);

            return OK;
}

I get the file ok,  but I also get the HTML output from OI and the
file which is saved on the disk is not usable.
What can I do to get only the file and nothing else?

-- 
Thanks,
Cornel

[Openinteract-help] master template

[Cornel G. <un...@gm...>]

Hi.
How can I force a OI package not to use a master template?

Thanks,
Cornel Ghiban

[Openinteract-help] Trouble creating package skeleton?

[Luis C. de C. <mon...@ya...>]

   Hi list.
   I just installed a copy of OI

Module  OpenInteract (C/CW/CWINTERS/OpenInteract-1.62.tar.gz)

   and when I try to follow the tutorial at

http://www.openinteract.org/docs/developer.shtml

   I simply don't get trought this message:

------------------------------------------------------------
oi_manage --base_dir=/home/champs/src/oi/ --package=fruit create_skeleton
Creating package skeleton in current directory.
=========================

Log4perl: Seems like no initialization happened. Forgot to call init()?
Cannot create object without existing file or 'new' permission 
[/home/champs/src/oi/conf/package_repository.perl] [write]
------------------------------------------------------------

   I've googled for this message, and don't find anything interesting.
   Also cant' find any tips at the FAQ (did I missed something?).

   If somebuddy could (please) gimme a tip, I would thank him/her very much.
-- 
=======================================================
   Luis Campos de Carvalho is BsC in Computer Science,
   Certified Oracle DBA, UNIX and Linux lover, Perl
   Fanatic and Leader of the Sao Paulo Perl Mongers
   http://br.geocities.com/monsieur_champs/
=======================================================

Re: [Openinteract-help] OI2 and DB Entity Relationships

[Chris W. <ch...@cw...>]

On Dec 10, 2004, at 6:28 PM, Coder wrote:
> I am having trouble understanding how the OI2 architecture models 
> entity
> relationships in code and susequently referes to the at run time.

There are a couple of things to separate here.

  - OI2 uses SPOPS for its entities. This might change to be more 
flexible, but not in the very near future.
  - OI2 has very good support for SPOPS as an object-relational mapping 
tool
  - OI2 does not preclude other mapping tools

The only reason OI2 does not support Class::DBI is that nobody who has 
known enough about Class::DBI has stepped forward as a guinea pig to 
test out integration. (Which should actually be quite minor.) Will you 
be the first? :-)

Here's what I mean by minor:

  - Class::DBI objects should be able to use OI2 datasources. This means 
you'll only have to define database information in one place. I assume 
this means you wire up a method in Class::DBI to return a database 
handle on demand, but that might just be how I think about things. 
(This is very easy, BTW.)

  - We need to initialize Class::DBI objects at startup. This could be 
as simple as listing a set of class names and having OI2 require() them 
all. (Also very easy.)

  - Is there any data definition language manipulation? That is, so you 
can do something like:

    My::Class::DBI->create_tables( 'mysql', $dbh );

I think that's it. There are likely other possiblities -- looking up a 
CDBI class by name vs hardcoding a class name (like the rest of OI2), 
doing any one-time initialization at package installation.

Is there anything I'm missing?

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988

Re: [Openinteract-help] OI2 and DB Entity Relationships

[<ti...@re...>]

The penny has dropped ... I now understand the comment someone made about the
extra hassle for the DBAs managing schemas designed to accomodate the SPOPS DB
object relationships.

The missing link was in here
http://spops.sourceforge.net/doc/SPOPS/Manual/Relationships.shtml

For my main application this means an extra 12-15 tables

Quoting Coder <mli...@re...>:

> All,
>
> I am having trouble understanding how the OI2 architecture models entity
> relationships in code and susequently referes to the at run time.
>
> I have been using Class::DBI for a while now and understand it's mapping
> quite
> well - it's pretty straightforward:
>
> Each entity/object is represented by a table and that object has
> relationships
> (one-to-one, and one-to-many) with other objects.
>
> Each object can tell you what it's children are and each child it's parent
> when
> queried using the correct method.
>
> These are the main functions I am having probelms translating into 'OI2
> speak'.
>
> Can anyone shed some light? I have looked through the archives, but have to
> admit am a little more confused. The OI2 Tutorial is good, but uses only a
> one
> table, and the Advanced Tutorial does not appear to have been written as yet.
>
> I have seen reference to the fact that Class::DBI could be incorporated, but
> no
> concrete examples of how.
>
> This is the last stumbling block for me before I migrate my apps to OI2, so
> your
> assistance is much appreciated.
>
> Ticha
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> openinteract-help mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-help
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Openinteract-help] OI2 and DB Entity Relationships

[<an...@io...>]

Hi Coder!

I think OI2 uses SPOPS instead of Class::DBI as object persistence and 
database mapping. Chris might have added some config options and other 
code to ease the transition to Class::DBI, but I'm not sure if such a 
conversion has ever been done / tested to work.

My suggestion would be to go for SPOPS. It has a decent documentation 
but some difficulties might arise from the fact that OI2 uses ini files 
to generate the SPOPS object configuration instead of plain perl which 
OI1 uses. Most of the examples in SPOPS documentation are from OI1 era 
and thus the syntax is presented just as perl hashes. In OI1 the SPOPS 
object configuration was set in packages conf/spops.perl (a perl syntax 
config) and nowadays it is in conf/spops.ini (an ini syntax config). OI2 
has some helper scripts to convert the old .perl files to the .ini 
syntax but the ini syntax should not be very hard to figure out when you 
know what you want to express.

First you should probably read the SPOPS documentation, especially the 
configuration part ( 
http://spops.sourceforge.net/doc/SPOPS/Manual/Configuration.shtml ) or 
OI1 Developer's guide ( http://www.openinteract.org/docs/developer.shtml 
) to get an idea how to build has_a (for the parent) and links_to (for 
the children) relations and then read the light OI2 documentation to get 
the idea on how to express these thing in .ini files.

The has_many relation you might be familiar with from Class::DBI does 
not yet exist in SPOPS. I believe it is being worked on ( on testing 
phase with lots of arm wrestling on some details =) ) at the moment, but 
you can manage quite well without it since links_to can be used to 
achieve the same result.

As you might notice OI2 has not yet reached stable status and does not 
even carry 2.0 version number so things like throughout documentation 
are still a bit lacking. The code itself is in my experience quite 
stable and we are using it in production environment (*eeeks*) but it 
surely has quite a learning curve especially with some parts lackin 
documentation.

Good luck!

- Antti

Coder wrote amont other things:
> Each object can tell you what it's children are and each child it's parent when
> queried using the correct method.
> 
> These are the main functions I am having probelms translating into 'OI2 speak'.
> 
> Can anyone shed some light? I have looked through the archives, but have to
> admit am a little more confused. The OI2 Tutorial is good, but uses only a one
> table, and the Advanced Tutorial does not appear to have been written as yet.
> 
> I have seen reference to the fact that Class::DBI could be incorporated, but no
> concrete examples of how.
> 
> This is the last stumbling block for me before I migrate my apps to OI2, so your
> assistance is much appreciated.
> 
> Ticha

[Openinteract-help] OI2 and DB Entity Relationships

[Coder <mli...@re...>]

All,

I am having trouble understanding how the OI2 architecture models entity
relationships in code and susequently referes to the at run time.

I have been using Class::DBI for a while now and understand it's mapping quite
well - it's pretty straightforward:

Each entity/object is represented by a table and that object has relationships
(one-to-one, and one-to-many) with other objects.

Each object can tell you what it's children are and each child it's parent when
queried using the correct method.

These are the main functions I am having probelms translating into 'OI2 speak'.

Can anyone shed some light? I have looked through the archives, but have to
admit am a little more confused. The OI2 Tutorial is good, but uses only a one
table, and the Advanced Tutorial does not appear to have been written as yet.

I have seen reference to the fact that Class::DBI could be incorporated, but no
concrete examples of how.

This is the last stumbling block for me before I migrate my apps to OI2, so your
assistance is much appreciated.

Ticha

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Openinteract-help] improper mime type set

[Steve S. <ste...@co...>]

When adding a document, I sometimes find that I can't view it or 
edit it after initially creating it.  I went to the database today
after one of these occurrences and found that mime_type was set to
'application/octet-stream' instead of 'text/html'.  When I updated
the database to change it, everything worked.  Any idea what might
cause this?

-- 
Steve Sapovits    ste...@co...

Re: [Openinteract-help] Problem with INCREMENT in postgresql

[Wijnand W. <wi...@ne...>]

Ok, sorry, I missed a line in my server.ini:
spops         = SPOPS::DBI::Pg


Wijnand

[Openinteract-help] Problem with INCREMENT in postgresql

[Wijnand W. <wi...@ne...>]

Hi List,

I am trying to explere OpenInteract but when setting up a example
website I am getting stuck.

The problem seems to be the handling of increments.
When oi2_manage install_sql --package=SYSTEM starts adding users I get
following error in my log:
18:50:25 ERROR OI2.INITIALIZE OpenInteract2::SQLInstall::User (99)
Failed to create superuser: DBD::Pg::st execute failed: ERROR:  null
value in column "user_id" violates not-null constraint
at /usr/local/libdata/perl5/site_perl/SPOPS/SQLInterface.pm line 297.

This same things happenes with other tables with an id field.
When I manually try to add the sequence I get an error saying the
sequence already exists.

Anyone knows what is wrong here?

Wijnand

Re: [Openinteract-help] Template Toolkit and ppm

[Chris W. <ch...@cw...>]

On Oct 27, 2004, at 5:31 PM, Ron Pero wrote:
> The readme for TemplateToolkit says this:
>
> If you're running ActivePerl on a Win32 platform then you can use the
> Perl Package Manager (PPM) to install the Template Toolkit.  Chris
> Winters maintains a repository of pre-compiled PPM packages which 
> contains
> the Template Toolkit, AppConfig and others.  For further information, 
> see:
>
>     http://openinteract.sourceforge.net/
>
> But I don't see anything at your site about it. Can you enlighten me?

You can grab 2.13 from:

http://www.openinteract.org/ppmpackages/Template-Tookit.ppd

But maintaining this has now moved to the much more active (and 
complete) theoryx PPM archive which you can add to PPM with the 
following command in the ppm shell (all on one line):

rep add theoryx 
http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58

Best,

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988

[Openinteract-help] Template Toolkit and ppm

[Ron P. <rp...@ma...>]

Dear Chris

The readme for TemplateToolkit says this:

If you're running ActivePerl on a Win32 platform then you can use the
Perl Package Manager (PPM) to install the Template Toolkit.  Chris
Winters maintains a repository of pre-compiled PPM packages which contains
the Template Toolkit, AppConfig and others.  For further information, see:

    http://openinteract.sourceforge.net/

But I don't see anything at your site about it. Can you enlighten me?

Many thanks,

Ron
--------------------------------------------
My mailbox is spam-free with ChoiceMail, the leader in personal and corporate anti-spam solutions. Download your free copy of ChoiceMail from www.choicemailfree.com

[Openinteract-help] CommonUpdate and CommonAdd with several tables

[Mari W. <mar...@me...>]

I am currently working on an OpenInteract2 package with a database
backend involving several tables.  I have set up SPOPS to access the
database, and displaying the data from the resulting objects works ok.
My question arises when I attempt to use CommonUpdate or CommonAdd to
deal with these data.  Updating or adding records in the 'main'
database table works without problems, but I am not at all sure to go
about updating other tables than that.

Is this a case of:

 - me missing something (possibly) obvious?

 - the feature is implemented but not documented?

 - the feature is not implemented yet?

 - the feature is not implemented and not intended to be implemented
   either?

I do, of course, have the option of doing the extra work myself in
_update_customize, but, if my understanding is correct, that sort of
defeats some of the purpose of the Common* classes in the first place.

Can anyone shed some light on this issue?

Mari :)

-- 

Mari Wang - ma...@me...

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

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

Hi,

I have been thinking most about the limited amount of names we're having 
for action/methods and I was thinking about bundling those which have 
the same content and just a different content-type.

That we use one SOAP entry point (SOAP::Lite calls this a proxy, when I 
understand right), is fine for me. Ant the results, as you describe them 
in the table, are nearly exactly what I think of. (The URL 
http://myoi.com/action.soap whould not exist, but the SOAP entry 
point/proxy locator URL http://myoi.com/soap with the identifier URI 
http://myoi.com/action .

I prefer a configuration where everything kan be configured from the 
top-level file (i.e. enabling the SOAP handler for all packages) and 
that the packages can specify when they don't want to have the one or 
other. But thats more a question of taste.

Having a split of action/method/presentation-type (with a dot or a slash 
or a soap-entry-point) seems natural to me.

Best regards,

heiko

Kutter Martin wrote:
> 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
> 
> 
> -------------------------------------------------------
> 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
> 
> 

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

[Kutter M. <mar...@si...>]

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

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

[Kutter M. <mar...@si...>]

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

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
> 
> 

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

[Kutter M. <mar...@si...>]

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

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

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

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
> 

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

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

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
> 

-- 
Dr. Heiko Klein                              Tel. + 47 22 96 33 44
Air pollution Section/Research Department    Fax. + 47 22 69 63 55
Norwegian Meteorological Institute           http://www.met.no
P.O. Box 43 Blindern  0313 Oslo NORWAY       http://www.emep.int