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.