|
There are no translations available.
Improving Virtuemart's extensibility
While Joomla itself, is a shining example of extensibility, Virtuemart (VM) is definitely not.
We currently can extend VM with:
- payment method plugins
- shipping method plugins
- currency conversion plugins
However, this is not enough at all!
At the very least, we would also need:
- cart extension plugins
- order status change plugins
- subcomponents
Let's clamour for them again: We need these hooks!
The Virtuemart core team needs to deal with Brook's Law urgently
No core software team in the world is immune from the harsh consequences of Brook's Law. The only known working method to fend of Brook's consequences and even a total standstill in a software project, is to provide extensibility hooks, so that outside programmers can provide features without the need to co-ordinate extensively with the core team.
Identifying and providing extension hooks, should always be the main strategy and main focus of every core software team.
The correct matra is therefore: Deal with Brook now!
The Virtuemart core team is still not dealing with Brook's Law ...
Short of criticizing their otherwise commendable efforts, we can see that the VM core team is not focused on Brook.
They have still not understood Brook's importance. Outside programmers are continuously faced with the unavoidable need to modify the VM core sources, and complain to the VM core team about it. The solution would be simple though:
Add the hooks to VIrtuemart that outside programmers need!
The Virtuemart core team is not heeding Brook's warning
The core VM team regularly complain that their progress is slow, because they would not have enough volunteers to help out. With more manpower, they would be able to go faster, they claim.
The claim is not true.
The current resources are being overwhelmed, because the core team is doing too much by themselves in the first place. They should not be adding features, but hooks, so that external programmers can add the features instead of them.
What's more, instead of improving the situation, adding developers to the VM core team will only make the problem worse; and progress even slower. Brook warns for this.
Given the fact that the VM source code has become increasingly monolithic, touching things in one place, often affects apparently unrelated things in other places. New volunteers, especially inexperienced ones, would therefore introduce substantially more bugs, than they would introduce interesting improvements.
Therefore, the initial efforts of source code reform, that is, refactoring, must be done by the existing team alone, before it can invite outsiders to work on it.
As Brook famously said:
Nine women can't make a baby in one month.
VM subcomponents: refactoring the VM source code
Each subcomponent, that is, each typical backend use case already corresponds with a menu group in the VM backend:
|
VM Component |
J1.6 obsolete |
Has sub. |
Remarks |
| 1 |
Admin & store configuration |
N |
N |
Multi-vendor has never really been finished. Therefore, the separation between admin & store configuration is not very useful at this point. |
| 2 |
Users, user groups, and shopper groups, "Modules" (meaning: permissions or ACL)
|
mostly |
N |
The J1.6 ACL system will make this vm subcomponent mostly obsolete. |
| 3 |
User fields
|
probably |
N |
Not only the user table needs custom fields. Every table should be able to have custom fields. The concept is excellent, but should be generalized across all tables. J1.6 may introduce the same system through custom content types (CCK) |
| 4 |
Countries, currencies
|
N |
N |
Should morph into the VM "Code table" subcomponent. It should be possible to add code tables on the fly. This generalized principle, along with generalized custom fields, will make the product attribute system obsolete. The product attribute system does not work properly anyway. |
| 5 |
Manufacturers ("brands") |
N |
N |
Core specialized VM function. |
| 6 |
Payment methods |
N |
N |
Core specialized VM function. |
| 7 |
Shipping methods (+standard shipping) |
N |
Y |
The standard shipping method shows that a shipping method could have it's own configuration system. Therefore, there is a need for a Shipping method subsubcomponent system. |
| 8 |
Category tree |
probably |
N |
The new J1.6 category system will make this vm subcomponent mostly obsolete. |
| 9 |
Products, product discounts, customer reviews
|
probably |
N |
The new J1.6 content type plugin system may make this vm subcomponent obsolete. |
| 10 |
Tax rates
|
N |
N |
Core specialized VM function. |
| 11 |
Coupons |
N |
N |
Core specialized VM function. |
| 12 |
Orders (and order status types)
|
N |
N |
Orders are a core specialized VM function. Order status types should be managed by a generalized VM "Code table" subcomponent.
|
| 13 |
Product types (unusable), Export modules (unused), vendors (unused) |
|
|
Should be dropped. |
| 14 |
Reports (+inventory reporting)
|
N |
Y |
Each report should be a separate subsubcomponent. |
Therefore, the current status of the VM project looks like this:
| Status |
Components |
# |
% |
| Core VM business |
- config
- code tables
- manufacturers
- payment methods
- shipping methods
- tax rates
- coupons
- orders
- reports
|
9/16 |
56% |
| Core J1.6 business |
- user management
- custom table fields
- category tree
- product custom content type + commenting system
|
4/16 |
25% |
| Failed stuff |
- product types
- export modules
- vendors
|
3/16 |
19% |
Another reason why the VM core team is too quick to complain about their shortage of resources, is the fact that they only spend 56% of their effort on their core business. Anybody would be short of resources in those circumstances!
First refactoring proposed
The VM source code is organized into two main folders in the back end:
| folder |
purpose |
| administrator/components/com_virtuemart/html |
backend pages |
|
administrator/components/com_virtuemart/classes
|
generally shared logic |
Step 1: move the html pages in groups to their subcomponent/subcomponentname/html folder
This should be not much of an issue. VM would have a problem in figuring out in what subcomponent folder to look for what page.
However, this can be solved by registering each page in vm_subcomponent_pages table.
Even though the way VM organizes its routing will eventually need to be changed and reflect the new subcomponent system, we do not need to do this immediately.
Legacy subcomponents must register their pages, while new subcomponents may directly use the new routing system. This should be something similar to:
option=com_virtuemart&suboption=com_config&page=configpage
Step 2: move the non-shared logic in classes to their subcomponents/subcomponentname/classes folder
If an existing method is used nowhere else than in a particular subcomponent, it should be moved to that subcomponent and out of the core. In such case, the subcomponent should have its own class that extends the core VM class.
This effort should be organized by listing every core class with their methods, and the number of subcomponents in which the method is used. The methods with count=1, should move.
It is possible to produce the list of core class methods automatically, by loading every script file in the classes folder, figure out how many classes are implemented in it, instantiate each of them, and dump their methods.
By searching for the occurrence of "$classname" in the subcomponentname/html folders, it is possible to figure out mostly automatically, if a particular subcomponent depends on it.
Step 3: create an installer/uninstaller for subcomponent zip files
The installer subcomponent should probably work very much like the joomla installer component, and register the subcomponent menugroups and menuitems in the VM menu.
VM subcomponents: advantages
It will be possible for outside developers to add new subcomponents and help extending VM.
Adding the hooks for cart and order status change plugins
VM needs to use two new Joomla plugin groups: vmcart and vmorderstatus. Plugins in those groups should respond to the following events:
| cart |
onCartProductAdded($cartRow)
onCartProductRemoved($cartRow) |
| order status |
onOrderStatusChanged($order) |
Along with the component system, adding these hooks will be sufficient to alleviate 90% of the current needs to modify VM core source code. It will make VM massively more extensible.
What is the VM core team doing instead?
Instead of dealing with Brook, the core VM team has embarked on a complete rewrite of the core sources, to make them MVC-compliant.
Of course, MVC is commendable. MVC will make the source more readable, more predictable, and will therefore help to stamp out bugs and increase the overall quality of the source code. However, MVC in itself does little to address the main issue in any software engineering project: Brook's Law.
Most of the benefits needed by the VM community can be attained almost entirely without rewriting the existing source code. Furthermore, rewriting the existing code will do nothing to solve the existing problems in the VM community, which are the consequence of Brook's Law.
Worst of all, 44% of their current source code rewriting effort will become obsolete, probably before April 2010, when Joomla 1.6 is scheduled to hit the shelves.
The problem with Virtuemart is therefore not a technical problem, but a political one.
Someone needs to convince the core team to change their strategy, and finally acknowledge that fact that Brook is right and they are wrong. In addition to that, instead of continuously clamouring for more resources, the VM core team should, first of all, reduce their wasteful need for resources!
So, I repeat, as I said before: I am indeed interested in joining the VM core team, but not in order to waste my days on a time-consuming but mostly ineffective rewrite. Thanks, but no thanks.
|
