Re: Where we are going with 1.3

["Chris Travers" <..hidden..>]

On 4/12/07, David Tangye <..hidden..> wrote:
> On Fri, 2007-04-06 at 14:54 -0400, Christopher Murtagh wrote (regarding
> templates):
> >  I'm all for it. Everything that is outside of svn should be in the DB
> > IMO, because it's not code, it's data.
>
> Aren't templates (and C etc header files for example) a bit of a grey
> area in that they can represent constructs used by and tightly bound to
> code, so are not data in the same way as runtime user data that is
> processed by code.

I think that to the extent that templates are user editable they
should be treated as data.  This is for security and data integrity
constraint reasons.

This means that all invoice templates and user enditable templates
should go in the db.  THose which are core data entry screens need
not.  But that is my own position.

> Another thought: consider MVC. M = database data schema, V = screen code
> and support constructs (bad term sorry), C = controlling code.
> M code is implemented in the db (data schema including table
> definitions, views, some triggers? and some stored procs), V in files, C
> in both the db (some triggers and stored procs?) and in files.
> Where are templates in the MVC model? Methinks V (support constructs).

That isn't really how we are dividing our MVC code.

M = data logic and support constructs.  This is almost entirely
defined in the database and lightly wrapped in Perl.  A few areas like
sales tax calculation are defined in Perl.  Our Perl modules already
have some really cool features in this area.

V = data  import/export (including data entry), and support
constructs.  V includes web services.

C = control logic.  This is all in Perl and involves scripting against
the M-based objects.

Best Wishes,
Chris Travers