Re: vtiger arch going forward

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: vtiger arch going forward

Dennis Grant
>> It is plain that as of now, there are only 2 "strong/loud" arguments.

>> I am sure you all will agree that both of them are not overly
>> subscribed by any majority yet.

> Yes but there is only one idea on the table, and 1 set of criticisms
> followed by absolutely no suggestions on how to better the first idea.
> This was really my bitch about the first set of posts.

Then frankly, you misread.

1) All code must be commented. Ideally, this would be a priority such
that commenting existing code would be an actual project, but
realistically, the goal of "all NEW code must be commented" or perhaps
"every time you touch the code, a comment must be inserted" is doable.

2) The current (4.x) architecture uses a number of "common" functions
(so identified by virtue of living in the include directory) that are
not really common. An easy test is that if at any time a soi-disant
"common" function tests to see what module it was called from and then
acts differently based on the result of that test, it ain't common.

Those functions should be broken out of the include directory and moved
into the appropriate module directory - perhaps something like
modules/Foo/UI.php (although this naming convention is definitely open
for discussion)

3) Any time you go to the database, the actual SQL should be exposed; it
helps integrators understand the layout and function of the database and
makes extending the database much easier. It's OK to streamline db
functions somewhat though - something like:

$query = 'SOME SQL';
@2D_array = query_db($query) or handle_db_error;

Is OK.

3) All modules must be atomic. At no time is it EVER permissible that
changing the code in module FOO *changes* the functionality of module
BAR - with one exception; if module FOO ever *calls* module BAR, and a
code change to BAR has broken the interface, then it is understood that
FOO calling BAR will break (and shame on whoever changed BAR's

In some cases, this will actually move functionality INTO common code,
and that's a good thing. For example, currently HelpDesk calls code in
Emails to do its email notification stuff (HORROR!) This would be better
served by a function in utils.php that called some sort of generic email

$result = send_email($to, $from, $cc, $bcc, $subject, $body, $flags);

4) There are two major challenges facing the vtiger architecture,
independent of code structure:

a) Per-user localization, which in turn is broken down into:

i) User language of choice; and
ii) User operating currency (which may be a function of what office the
user is working out of)

b) Per-user security (a user cannot edit someone else's Quote, for

Both of these are ABSOLUTE MUSTS going forward, and there's a lot of
heavy lifting there. No matter what the code structure is, these two
design structures must be part of the arch.

I'm hoping that 5.0 has support for this already...

>> Let us get some more ideas- however radical they be- into this list
>> and then we will vote the good ideas in.

> This is a great idea.  I have been looking forward to someone else
> posting some ideas to get the ball rolling.  I for one welcome radical
> ideas if anyone has any.

Hrm, well, let's see how welcoming you *really* are.


Get started with creating presentations online -