openinteract-help

[Openinteract-help] getting started

[Steve S. <sap...@gs...>]

I installed okay -- had some problems with Oracle, so I switched
to MySQL.  Everything's about working it seems.  One small bug I
can't figure out:

In the Illustrated Manager's Guide To OpenInteract doc, diagram.png
does not show up.  If I look for it directly I get a "File Not Found"
page error.  I have Apache set up with a front-end Apache proxying
back to a mod_perl Apache as suggested.  I see the request in both
logs.  I can see the doc as expected in a regular Apache server
environment.  Any ideas there?  I did add two rewrite rules to the
proxy to pick up existing CGI's and a directory as a migration path.
Neither of those rules remotely matches the diagram.png URL.

The bigger question I'm still tackling mentally reading the docs is
the best way to map data to pages.  I have many data sources -- some
database-oriented, some file based, some even from other sources.  We
have a tool set we developed that abstracts some of this into ETL like
transforms.  Ideally I want to plug into that.  I can see how I'd write
packages suitable for TT template substitution -- mostly I'd write
wrappers using this underlying toolset as the base data manager; the
wrappers mapping that to a TT model. That seems good enough, but it's
not clear to me if I should go beyond that and be importing data into OI.
What exactly is the difference?  Not too dumb a question I hope ...

This looks very good at first glance.

-- 
Steve Sapovits    GSI Commerce, Inc.    http://www.gsicommerce.com
sap...@gs...

Re: [Openinteract-help] getting started

[Steve S. <sap...@gs...>]

I wrote:
> 
> In the Illustrated Manager's Guide To OpenInteract doc, diagram.png
> does not show up.  If I look for it directly I get a "File Not Found"
> page error.  I have Apache set up with a front-end Apache proxying
> back to a mod_perl Apache as suggested ...

I forgot to add that I do not have root priveleges on the install
box so I have the proxy listening on 8080 and the mod_perl back end
listening on 8081.

-- 
Steve Sapovits    GSI Commerce, Inc.    http://www.gsicommerce.com
sap...@gs...

Re: [Openinteract-help] getting started

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

On Sun, 2002-11-17 at 01:34, Steve Sapovits wrote:
> In the Illustrated Manager's Guide To OpenInteract doc, diagram.png
> does not show up.  If I look for it directly I get a "File Not Found"
> page error.  I have Apache set up with a front-end Apache proxying
> back to a mod_perl Apache as suggested.  I see the request in both
> logs.  I can see the doc as expected in a regular Apache server
> environment.  Any ideas there?  I did add two rewrite rules to the
> proxy to pick up existing CGI's and a directory as a migration path.
> Neither of those rules remotely matches the diagram.png URL.

Ah, good catch. The problem is that the request is being passed to the
backend server but OI doesn't have the page registered. You can solve
this in two ways:

1) You can add the following to your front-end proxy:

 RewriteRule .png$ - [L]

2) You can scan the directory for new documents and add 'diagram.png' as
a viewable object. From the 'Admin Tools' menu select 'Page Actions'
then 'Scan' and enter '/oi_docs/' as the directory.

I'll change the install to add this image properly..

> The bigger question I'm still tackling mentally reading the docs is
> the best way to map data to pages.  I have many data sources -- some
> database-oriented, some file based, some even from other sources.  We
> have a tool set we developed that abstracts some of this into ETL like
> transforms.  Ideally I want to plug into that.  I can see how I'd write
> packages suitable for TT template substitution -- mostly I'd write
> wrappers using this underlying toolset as the base data manager; the
> wrappers mapping that to a TT model. That seems good enough, but it's
> not clear to me if I should go beyond that and be importing data into OI.
> What exactly is the difference?  Not too dumb a question I hope ...

OI provides a data access model for you to use, but you're not tied to
it for new development.  Similarly, OI provides an integrated view
processing model with all sorts of goodies (Plugin, including other
templates, components, etc.) but you're not tied to it either.

I'm not sure how your existing system works, but if you've put a lot of
work into your data model you might want to keep that. And if you've
already got a templating/view system setup you can access it just like
you would any other perl module.

The thing to remember is that at the core an OI action has one task:
generate content. Every OI action returns content, even if that means
(pseudo-)forwarding the flow to another action.

So instead of something like:

sub show {
    my ( $class, $p ) = @_;
    my $R = OpenInteract::Request->instance;
    my $object_id = $p->{object_id} || $R->apache( 'object_id' );
    my $object = $R->myobject->fetch( $object_id );
    return $R->template->handler( {}, { object => $object },
                                  { name => 'mypkg::mytmpl' } );
}

you can have:

sub show {
    my ( $class, $p ) = @_;
    my $object_id = $p->{object_id} || $R->apache( 'object_id' );
    my $object = MyDataModel->retrieve( 'My::Object', $object_id );
    return MyViewProcess->generate( 
                    'objectview', { object => $object } );
}

And OI won't really care.

In the next version you can define a generic ContentGenerator and link
that to an action, so you should be able to swap different ways of
generating content in and out. (We'll see how it works...)

Thanks,

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-help] getting started

[Steve S. <sap...@gs...>]

Chris Winters wrote:

> OI provides a data access model for you to use, but you're not tied to
> it for new development.  Similarly, OI provides an integrated view
> processing model with all sorts of goodies (Plugin, including other
> templates, components, etc.) but you're not tied to it either.
> 
> I'm not sure how your existing system works, but if you've put a lot of
> work into your data model you might want to keep that. And if you've
> already got a templating/view system setup you can access it just like
> you would any other perl module.
> 
> The thing to remember is that at the core an OI action has one task:
> generate content. Every OI action returns content, even if that means
> (pseudo-)forwarding the flow to another action.
> 
> So instead of something like:
> 
> sub show {
>     my ( $class, $p ) = @_;
>     my $R = OpenInteract::Request->instance;
>     my $object_id = $p->{object_id} || $R->apache( 'object_id' );
>     my $object = $R->myobject->fetch( $object_id );
>     return $R->template->handler( {}, { object => $object },
>                                   { name => 'mypkg::mytmpl' } );
> }
> 
> you can have:
> 
> sub show {
>     my ( $class, $p ) = @_;
>     my $object_id = $p->{object_id} || $R->apache( 'object_id' );
>     my $object = MyDataModel->retrieve( 'My::Object', $object_id );
>     return MyViewProcess->generate( 
>                     'objectview', { object => $object } );
> }
> 
> And OI won't really care.
> 
> In the next version you can define a generic ContentGenerator and link
> that to an action, so you should be able to swap different ways of
> generating content in and out. (We'll see how it works...)

This gives me something more to chew on.  Let me throw some more specifics
at you.  We have many existing data stores I'd want to feed up through OI
and its TT front end.  A lot of these are Oracle databases/tables.  Those
are managed by existing apps., but it would seem I could plug those in as
read only and still benefit from the full OI stack (security, access, etc.).
I didn't see any master read-only flag -- just a setting that lists the
columns that are not to be updated.  Is that correct?  For read-only, are
there advantages to going full OI versus doing something like you suggest
above?

In addition to the DB tables we have this other data translation tool set.
That can either work off DB tables or other data stores; and it creates
non-database stores (e.g., files in various formats) we'd want to display.
It would seem one way to do this would be to create an SPOPS interface to
our data tool set -- fill in enough of the methods to have data accessed
read-only.  It has a well-defined interface so I think this might be
relatively easy.  I'm just not 100% clear on the benefits of doing that
versus just using a direct TT interface to that data.

One other question I haven't seen answered:  For large data driven tables,
what's the procedure for having those displayed paged?  I know TT offers
something here, but does OI do anything more?  Do you have to load a full
table set for each access and page into it, or is there something better?

Thanks.

-- 
Steve Sapovits    GSI Commerce, Inc.    http://www.gsicommerce.com
Email:   sap...@gs...
Work:    610-491-7087
Mobile:  610-574-7706
Pager:   877-239-4017

Re: [Openinteract-help] getting started

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

On Mon, 2002-11-18 at 09:57, Steve Sapovits wrote:
> This gives me something more to chew on.  Let me throw some more specifics
> at you.  We have many existing data stores I'd want to feed up through OI
> and its TT front end.  A lot of these are Oracle databases/tables.  Those
> are managed by existing apps., but it would seem I could plug those in as
> read only and still benefit from the full OI stack (security, access, etc.).
> I didn't see any master read-only flag -- just a setting that lists the
> columns that are not to be updated.  Is that correct?  For read-only, are
> there advantages to going full OI versus doing something like you suggest
> above?

Actually, SPOPS has a tool for this. If you add: SPOPS::Tool::ReadOnly
to your object's isa declaration, like:

my $spops = {
   myobject => {
      class => 'This::Object',
      isa   => [ qw/ SPOPS::Tool::ReadOnly OpenInteract::SPOPS::DBI
                     SPOPS::DBI::MySQL  SPOPS::DBI / ],
      ...
   },
};

Then any calls to save/remove get intercepted into a no-op.

> In addition to the DB tables we have this other data translation tool set.
> That can either work off DB tables or other data stores; and it creates
> non-database stores (e.g., files in various formats) we'd want to display.
> It would seem one way to do this would be to create an SPOPS interface to
> our data tool set -- fill in enough of the methods to have data accessed
> read-only.  It has a well-defined interface so I think this might be
> relatively easy.  I'm just not 100% clear on the benefits of doing that
> versus just using a direct TT interface to that data.

There's not much of a benefit. If you were creating tools for other
people to use it would be useful, but if it's for an in-house project
(or set of projects) there's not much use beyond being consistent with
what OI currently uses. That you're probably already used to using your
interface overrides any benefit OI would have.

> One other question I haven't seen answered:  For large data driven tables,
> what's the procedure for having those displayed paged?  I know TT offers
> something here, but does OI do anything more?  Do you have to load a full
> table set for each access and page into it, or is there something better?

Yes -- check out the 'results_manage' package; specifically
OpenInteract::ResultsManage. What happens is that your query will fetch
all the IDs the first time; these are stored in a temporary file keyed
to a value which you use as a search ID. Then you pass in the search ID,
the number of items per page and the page number and you'll get in
return an iterator which will cycle through those objects.

Chris
 
-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.

Re: [Openinteract-help] getting started

[Steve S. <sap...@gs...>]

Chris Winters wrote:

> There's not much of a benefit. If you were creating tools for other
> people to use it would be useful, but if it's for an in-house project
> (or set of projects) there's not much use beyond being consistent with
> what OI currently uses. That you're probably already used to using your
> interface overrides any benefit OI would have.

One thing I'd like to be consistent on is the access control/security.  I
would need to plug in to SPOPS/OI fully to get that, right?  Seems like
with the read-only code you sent I could do that without too much pain.
You think it's worth it?  And I'd also want to be able to handle results
consistently, as with the paging, etc.

Thanks for the other info.  I have a much clearer road map now.

-- 
Steve Sapovits    GSI Commerce, Inc.    http://www.gsicommerce.com
sap...@gs...

Re: [Openinteract-help] getting started

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

On Mon, 2002-11-18 at 10:53, Steve Sapovits wrote:
> One thing I'd like to be consistent on is the access control/security.  I
> would need to plug in to SPOPS/OI fully to get that, right?  Seems like
> with the read-only code you sent I could do that without too much pain.
> You think it's worth it?  And I'd also want to be able to handle results
> consistently, as with the paging, etc.

Security is one of the more attractive features, and you'd just have to
fit an SPOPS wrapper around your existing data to get it.

> Thanks for the other info.  I have a much clearer road map now.

Excellent. If you're into this sort of thing it would be great to get
another case study like John Sequira's:

http://radio.weblogs.com/0103492/gems/notes.html

Particularly since what you're doing is a retrofit rather than creating
something entirely new.

Chris
 
-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.