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

[Chris Travers <..hidden..>]

On Mon, Mar 8, 2010 at 10:32 AM, Aurynn Shaw <..hidden..> wrote:

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

I was actually thinking of a representation that allows something with
a flat representation (HTTP POST, maybe some sort of text files, etc)
to have some sort of conversion possible to the native data structure.
 This would allow more centralization of data validation than it would
if each workflow script has to do this independently.

>> 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.

Regardless of where we automate such a transformation, I think it
would be helpful to automate it.  Is there a specific objection to
automating the movement from a flat representation to a native
representation?  Or do you think there is a better place to put such
automation?

>
>>
>> 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.

Yep.

>> 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?

Mostly it is useful for customization.

> 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.

Yep.  I am thinking maybe moving them to
LedgerSMB::Web::Workflow::[module_name] and adjusting the directory
structure accordingly.  The session and auth management could be moved
to LedgerSMB::Web::Session and LedgerSMB::Web::Auth....

Best Wishes,
Chris Travers