[Vtigercrm-developers] Ideas for vtiger architecture moving forward

[Matthew Brichacek]

On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote:
> Proper use of a OO design would solves this for both of you.
> 
> All the common code and default module behavior should be moved into
> the a set of default classes or "engines" as Matthew is calling them.
> Then for each module we inherit the classes and make a couple method
> calls (ideally this is abstracted as well so to create a module all
> you do is create a class which inherits the base class) which
> generates the required database actions / html page.  If you want
> something different then the default, like Dennis describes, you
> simply extent the required method in your inherited class.  This way
> the common code is abstracted and only needs to exist once while the
> module specific code is in the module for easy modification.
I think we're right on the same page here, but if you take for example
the Campaign.php class, it should not be needed. All of the functions
and variables it defines are generic and do not need to be re-created
for each module that does simple data collection and display.
If you want to write a module that does more than this, and will need
it's own class, by all means, extend the EntityEngine class (or
CRMEntity if it becomes the engine) and then continue on your way.

> 
> The code is already partly structured this way (it's just not used
> properly).  There's already a base class CRMentity which every module
> inherits from.  What needs to be done is to clean up the CRMentity -
> module relationship so that only methods common to all modules and
> their default behavior is defined in CRMentity and only things which
> need to be changed are defined in the module class.  
But even things that need to be changed, may not need to be changed and
defined in separate module classes.  For example all the get_leads,
get_contacts, etc functions can be standardized and instead use a set of
DB keys to track relationship_types allowed for a module.
function get_leads($id,$entity) {
	if($this->is_relationship_type($entity->module,"Leads")) {
		stuff..
	} else
		return false;
}

> Then we need to
> create a class for each page type (again some of this already exists.
> ala inculdes/Listview.php, but here it isn't used at all) with the
> default behaviors of each page type.  Now we have an option, either we
> have each module inherit these page type classes (making changes as
> needed ala CRMentity) and have a common set of calls to render each
> page type or we create a SMALL file in each module with a couple of
> calls to the page type class to render the page and we substitute new
> functions as needed for customizations.  Personally I think the first
> option here is the better design, but unless you get it right it could
> become difficult to modify the parts of the page you want without
> re-witting a lot of the base class (should be avoided at all cost or
> we're right back in the mess we are in now).
Correct, and I think if you created the correct UI classes you could
very easily overwrite the functions you want to customize and _only_ the
functions you want to customize (like AddBlock() for example).


> That was a bit of a long winded explanation, let me know if anyone
> requires clarification.
I think we're pretty close to being in the same school of though but
maybe I needed to explain my thoughts in a bit more detail.  I really
just laid out a very high level overview of what I think should be done.

Matt