[Vtigercrm-developers] Ideas for vtiger architecture moving forward

[Allan Bush]

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.

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

That was a bit of a long winded explanation, let me know if anyone
requires clarification.

On 7/14/06, Dennis Grant <dgrant at accuratetechnologies.com> wrote:
>
> > My basic idea comes down to writing wrapper classes that are used to
> > abstract most of the unnecessary functions from developers and instead
> > provides a uniform API to access modules, permissions, input, etc.
>
> Oooh.
>
> > The idea comes in three pieces.  Common UI classes, most of which is
> > already done with the new UI.  A "mainframe" engine similar to the
> > joomla $mainframe.  And last but certainly not least is an entity
> engine
> > that would abstract most of the entity details from developers and
> truly
> > provide the unified API.
>
> To be honest, I think this is moving in the wrong direction.
>
> If everybody used the same vanilla VTiger installation, this would make
> a lot of sense - one common UI for the entire set of users, and a much
> cleaner codebase for developers. Happy happy for everybody.
>
> Unfortunately, a lot of us are NOT using vanilla VTiger; we have to
> customize the application to meet the needs of our user base. And a lot
> of the time, our users really really want changes that may seem utterly
> trivial from a developer standpoint, but for whatever reason, they
> REALLY want it that way.
>
> And the customer is always right, so we have to do it.
>
> I don't, for example, want to see something like where Accounts and
> Contacts share the same DetailView module - because in my setup, there
> are large differences between the DetailView we do for Accounts, and the
> DetailView we do for Contacts.
>
> It is a whole lot easier to deal with each module having its own code,
> even if that code is 95% common with other modules in a vanilla install,
> because that way, if I'm working on the Contacts DetailView, I don't
> have to worry about changes spilling over into the operation of another
> module.
>
> Yes, it makes changing common code more difficult, 'cause now I have to
> drill down into each submodule and make the same change over and over
> again, and I can certainly see where modularizing and sharing code makes
> that job a lot easier. But the assumption it is based on, while true of
> a vanilla install, is NOT true in a customized install environment.
>
> I'd prefer to see every module live in its own subdirectory of the
> modules directory, much as is does in 4.x, but more rigorously (ie,
> separate Sales Orders from Purchase Orders, don't group them in Orders)
> and each module should have its own, atomic codebase.
>
> We're doing things in the field that are far more advanced than just
> custom fields (although we make use of those too) and we need the
> flexibility that comes with exposing the dirty details.
>
> Same thing with database queries. It's tempting I know to try and
> abstract all those away with wrapper functions (and there are some
> wrapper functions that are OK - something like
> getContactEmail($contactID) or getContactAccount($contactID) or
> isDeleted($crmID) are all simple and handy and useful for simplifying
> out some of the database access overhead.
>
> But as soon as you start getting into more complex queries, I want to
> see the SQL right there in the code. I need to understand EXACTLY what
> is going on, and I may need to muck with the query; especially if I have
> changed/extended the database/table.
>
> For example, our users had a need for Quotes to preserve the order in
> which Products were added to the Quote. The intent is that they wanted
> the PDF export of a Quote to do something like this:
>
> Big expensive item 1
> Option A for item 1
> Option B for item 1
> Option C for item 1
> Big expensive item 2
> Option A for item 2
> Option C for item 2
>
> But as the items came out of the database in the order in which they
> were added to the database, what they got once they saved it might be
> something like:
>
> Option C for Item 2
> Option A for item 1
> Big Expensive item 2
> ...etc
>
> >From a developer point of view, that's OK, 'cause all the items are on
> there and the total is right, so what's the big deal? Well to them, this
> WAS a big deal - a really big deal. They wanted this changed, and my
> boss wanted it to happen NOW; so I extended the QuoteProductsRel to
> include a sequenceNumber.
>
> Then they wanted to be able to add headings, like this:
>
> Heading 1
> Big expensive item 1
> Option A for item 1
> Option B for item 1
> Option C for item 1
>
> Heading 2
> Big expensive item 2
> Option A for item 2
> Option C for item 2
>
> So I extended QuoteProductsRel to include a heading field that, if
> populated, would print on the line preceding the product it was
> associated with.
>
> Etc etc etc.
>
> This sort of stuff is WAY easier if the code to do it is right there,
> and not buried in a common function somewhere (like a lot of the UI code
> is, where you have the Mother of all If Statements lurking in utils.php
> that has to account for *every single module* before it presents the UI.
>
> I'd like to see some standardization on the module file structure
> though:
>
> modules/Foo/EditView.php for the edit UI for the module object
> modules/Foo/DetailView.php for the detailed view of the object
> modules/Foo/Save.php for saving the object to the DB
> modules/Foo/CreatePDF.php for creating a PDF version of the object
> modules/Foo/UIElements.php for the common UI functions (that are now
> stuffed in include/utils.php
> modules/Foo/BarPopup.php if there is a popup window to select associated
> Bar objects
>
> etc.
>
> It makes dealing with modules easier if we know where the various
> functions are kept.
>
> DG
>
> _______________________________________________
> Get started with creating presentations online - http://zohoshow.com?vt
>