[Vtigercrm-developers] Ideas for vtiger architecture moving forward

[Matthew Brichacek]

I have some ideas for cleaning up the structure of vtiger as we move
forward.  I am just going to lay them out here, let me know what you
think.

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.

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.

Lets start with the big one, Entity Engine:
The entity engine would be accomplished in three steps.  The first step
is to move all common variables and functions into the EntityEngine
class (which extends CRMEntity).  The entity engine would go into the DB
to populate these with the correct info.  For example tab_name,
tab_name_index and all the other most common variables would be stored
in the db and populated when the entity engine has a request for that
module.  The next step would be to create common set of functions in
this class that would be exposed to the developer.  The initial
functions I can think of are things like get/set functions for different
field values, etc.  The last step to the entity engine would be an XML
install system.  If a developer came along and wanted to create a simple
data collection module, like the current campaigns module, they would
simply create an XML file that defines all the fields to be displayed,
what relationship types are allowed, etc.  The entity engine would then
create the correct tables, populate the needed tables for the entity
engine (the ones holding tab_name, etc) and register the new entity type
with the system.

This leads into the UI system because if the developer is just creating
the XML file, how are common views displayed (list, detail, edit,
relatedlists)?

The UI system would be a set of classes to extend smarty and again
abstract the gory details of the internal workings from the developer.
VTigerUI::DetailView($entity) would follow a flow:
1) Display all common elements (header, etc):
$this->createTigerHeader();
2) Display the common 2 tab display for edit/detail/related views
$this->getCommonUI("DetailView");
3) Create a block for each block type in the DB, and create the fields
for it as well.
$this->assign("NUM_BLOCKS",sizeof($entity->blocks));
foreach($entity->blocks as $blockid=>$fields) {
	$block_fields = array();
	foreach($fields as $fieldname=>$field_data) {
		$block_fields = $this->CreateEditField($fieldname,$field_values); //
creates new edit fields based on uitype and returns an array as
$array[sequence_number] = "HTML output"
	}
	$this->assign("BLOCK_".$blockid,$this->addBlock($blockid,
$block_fields));
}
4) Display data :)

And just like magic, the ListView, DetailView, EditView and
CallRelatedList files can all go away and these common views can be
managed in a much easier way.

Next, the mainframe.  In joomla (as far as I understand) the mainframe
is meant to handle all GET, POST, REQUEST and SESSSION variables and it
also sanitizes that input before giving it to the developer
($mainframe->get_input("REQUEST","data")).  On top of this it handles
some user security and other things.  In vtiger I could see it being
used for many similar things.  Take for example the CreateDetailField()
function call above.  Inside of this call would be:
if($mainframe->is_allowed("Detail",$field->id)) {
	stuff..
else
	return;

There are still other details to be worked out, but you see that this
isn't a _really_ large change for the flexibility it will give you in
the system.

After it's all said and done you should have two sets of documents that
a developer would have access to, the module developers document that
would be a document outlining the three pieces discussed above and then
the core developer document that would document all the core back-end
functions (everything in utils/).

Of course there would be a way to overwrite these methods so that
developers can still create non-entity based modules (webmails,
calendar, rss, etc), but it should make life much easier for module
developers who follow the entity structure in vtiger.

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.


Matt