[Vtigercrm-developers] Ideas for vtiger architecture moving forward

Matthew Brichacek mmbrich at fosslabs.com
Fri Jul 14 10:18:54 PDT 2006


On Fri, 2006-07-14 at 10:13 -0700, Allan Bush wrote:
> I'm pretty sure we're on the same page Matt, my reply was more of an
> attempt to convince Dennis then an attempt to disagree with anything
> you said.
> 
> In your example though I'm not sure how much I like having a function
> called "get_leads" in the base class.  I think there's way too much
> coupling between "modules" right now and I'd like to get away from
> that, however I'm not sure what the best way to do that is without
> losing any of the control we currently have.  That's probably another
> discussion though.
I'm not a big fan of how this is done either but you're right, this
falls into another discussion about how to clean up current practices
going forward with a new structure.

> 
> I agree with your design, I could probably argue all day over the
> implementation of the details, but as long as it's constant and
> logical I don't care too much.
Plenty of details that are yet to be worked out ;).



Matt

> 
> 
> On 7/14/06, Matthew Brichacek <mmbrich at fosslabs.com> wrote:
> > 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
> >
> > _______________________________________________
> > Get started with creating presentations online - http://zohoshow.com?vt
> >
> _______________________________________________
> Get started with creating presentations online - http://zohoshow.com?vt 




More information about the vtigercrm-developers mailing list