[Vtigercrm-developers] Ideas for vtiger architecture moving forward

[Ivar Simpkins]

Sorry DG this doesn’t wear with me.

'The price of programmability' is what it's about.

 There is the short term solution and it has its merits, but planning a
structured API can only have its long term benefits. Where does vTiger
want to be in the future, this has to be answered. If it wants to be in
the top ratings, then I think every effort has to be made, to
reconsolidate and then plan for the future.

Sure the learning curve is steep but the rewards are enormous. Would it
not be better to prefect a generic function, in an OO structure which
does all you want, one entrance, one exit and away you go. 

A well documented code base that automatically builds your API
documentation gives you a valuable toolbox, now concentrate the
communities efforts on pulling together and raising the lowest common
denominator and you have a work the progresses moving a an incredible
rate.

And as Matt said:

'What do you think?  Am I nuts?  Does it take too much away from the
developer in the name of standardization?  To me it feels like the next
natural step to cleaning up the system and creating defined layers as
far as security, display and entities are concerned.  It should cut down
on all the unnecessary code re-creation in the system as well.'

NO, you are not nuts, it gives you the long term ability to use ones
creativity to best avail without (always) having to worry about the nuts
& bolts.

I think this is a courageous step in the right direction, where, after
surviving the learning curve, all will benefit, creating a homogeneous
standardised kernel, with the ability of Plug 'n Play ala Joomla and
probably much more. 

'The price of programmability' is high but seeing the caliber of work
produced so far, I am convinced Matt is on the right track to creating a
new dimension in CRM.

Please excuse the tone but its hard to see the same mistake been made
over and again.

Ivar

> 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 


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date:
2006/07/13
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date:
2006/07/13