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