[Vtigercrm-developers] Ideas for vtiger architecture moving forward

Dennis Grant dgrant at accuratetechnologies.com
Fri Jul 14 06:24:34 PDT 2006


> 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 




More information about the vtigercrm-developers mailing list