Re: Proposed Architecture Changes in 2.0 (Request for comments)

[Aurynn Shaw <..hidden..>]

Hi;
> Looking forward from 1.3, I am going to propose the following framework changes.
>
> I think in general, the 1.3 framework is better than the 1.2 framework
> in terms of understandable, testable code.  Unfortunately the
> framework isn't perfect and will run into a few issues on mod_perl,
> coding styles, etc.  Also there are a few areas of the 1.3 codebase
> that need to be clearly refactored going forward.
>
> 1) Modules should be broken off into modules where objects have
> consistent, documented structures.  The 1.3 Company/Person logic needs
> to be redesigned to work along these lines.
>
> 2)  Each object needs to have a corresponding and documented "flat
> representation" used in HTML forms, HTTP posts etc.

Could you go into more detail on this? It sounds like we're talking 
about an automatic DB Model -> HTML Form translation layer.

> 3)  Each database-based object should have a number of different
> constructors including one from a "flat representation," one that
> copies internal representation elements passed in the arg string, and
> one which retrieves from the database via the appropriate keys.

I still feel this is a really, really bad idea - implicitly pulling data 
from the arg string and treating DB instances as partial representations 
of the request object is A Bad Idea.
Even when dealing with very long incoming POSTs, directly creating DB 
objects from the request strikes me as ill-advised. I think further 
discussion on this is definitely warranted.

> 5)  The UI template rendering will be handled outside of the workflow
> script.  Also prior to exiting db connections, etc. will be closed,
> and the user object destroyed.

This is a good idea, in that we can return structured data from our 
controllers/workflow scripts and have multiple representation generators 
- XML, JSON, LaTeX, HTML, &c.

> 6)  Workflow scripts will allow stacks of coderefs to be pushed onto
> before, instead, and after piles, allowing for shims to be placed by
> system integrators at these points.

Are we looking at this being used in a wide scale? How important is it 
going to be for controllers to be modified in this fashion?

I'd also advise, as part of the ongoing rearchitecture, moving the 
controllers into a consistent object base, so this functionality can be 
implemented behind the scenes, and is invisible to controller authors.

~A


--
Aurynn Shaw

The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 ext 103
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
We are all in the gutter, but some of us are looking at the stars.
  -- Oscar Wilde

..hidden..