[Vtigercrm-developers] Ideas for vtiger architecture moving forward

[Matthew Brichacek]

> 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.
So in these cases you could over-ride the system DetailView by creating
<vtiger_root>/Accounts/DetailView.html.php for your actual HTML stuff,
and <vtiger_root>/Accounts/Detailview.php if you want to change the
logic flow.   If you are only changing the look/feel, then re-declare
the AddBlock() function with your new special sauce inside of it and off
you go.


> 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.
See above, the correct separation of these layers in the system can
still give you the flexibility you need.


> 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.
> 
To create new field types it would just be a matter of creating a new
UIType, populating the DB fields you want to have that uitype (via XML),
and then creating the base HTML for it in the UIType.tpl file.
{if {$uitype} == "230"}
your_new_html
{/if}
On top of this you could just over-ride the system UI creator and
replace it with your own display classes.

> 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.
I actually think the entity engine will need to have a query builder in
it so that the queries can be built dynamically depending on the type of
data you are going for.  A true entity engine (like the one in
ofbiz.org) will not ever let you see a query, nor should you need to if
the entity engine is doing it's job correctly.

> 
> 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 hate utils.php :).  But the examples you lay out above would not at
all be impossible.  You would simply tell the entity engine (via an XML
file) that you want a seqno and header value assigned to each entity of
type=Quotes, and then in the query builder it will check for seqno and
if it find it, ORDER BY seqno will be appended to the query string.


Really what I am trying to accomplish is to make your life easier in the
long run than what it currently is, even when diverging from the
standard way of doing it with-in vtiger.  There is a learning curve that
will come along with this but correct documentation and developer
support via this mailing list should help you get past any of that.

Matt