[Vtigercrm-developers] Ideas for vtiger architecture moving forward

[Allan Bush]

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


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
>