Re: [Openinteract-help] OI package and SPOPS objects structure

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

On Fri, 2002-05-24 at 06:51, Ben Avery wrote:
> I'm building a information and workflow system onto an existing relational
> schema, which is fairly complex (around 25 tables), and which has three
> types of user with different roles, but whose activities use and affect the
> same tables.
>
> I'm wondering the best approach to structuring the packages and objects?
> I thought of making a package for each user's activities (there is very
> little shared functionality), and making each table into a SPOPS object
> (with any more complex activities handled explicitly with SQL) but then
> which packages should the common tables belong to?
> Could I make a separate 'schema' package which contains all the tables as
> SPOPS objects?

OpenInteract doesn't really care about packages per-se. At server
startup it merges all the relevant information from all installed
packages into a single data structure provided by the configuration
object.

So the packages are really for us humans who have trouble keeping these
things separate. As a result, it's really up to you how you organize
them. A few rules of thumb off the top of my head:

 - If you find yourself updating templates/objects/actions/handlers in
two packages at the same time, they probably belong in one package

 - If you have more than five or six objects that are not tightly
related (dependent objects, etc.) in the same package, you might think
about splitting some functionality out into another package

 - Keeping the schema (struct/foo.sql) definition in the same package as
the object definition (conf/spops.perl) is a very good idea.

 - If you have non-object tables, what package are they most closely
related to? If the answer is more than 1, it's probably a good idea to
create a 'mycompany_common' package and put them there. Doing this is
also a good idea for common object behaviors, template plugins, site
widgets, etc.

Hope this helps,

Chris

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