plgVmOnUpdateOrderShipment removal in future version of vm ??

[whisky]

While securing my code against, future upgrade to virtuemart code, I discovered that it sound like the plgVmOnUpdateOrderShipment seems to be considered as 'obsoleting' ??

In VirtueMartModelOrders::updateStatusForOneOrder method i see in the trunk that the trigger call to plgVmOnUpdateOrderShipment is being commented out.

current behavior is :

   JPluginHelper::importPlugin('vmpayment');
   JPluginHelper::importPlugin('vmcalculation');
   JPluginHelper::importPlugin('vmcustom');
   $_dispatcher = JDispatcher::getInstance();                                 //Should we add this? $inputOrder
   $_returnValues = $_dispatcher->trigger('plgVmOnUpdateOrderPayment',array(&$data,$old_order_status));

  ...

  JPluginHelper::importPlugin('vmshipment');
  $_dispatcher = JDispatcher::getInstance();                                 //Should we add this? $inputOrder
  $_returnValues = $_dispatcher->trigger('plgVmOnUpdateOrderShipment',array(&$data,$old_order_status));

trunk is :

   JPluginHelper::importPlugin('vmcustom');
   JPluginHelper::importPlugin('vmcalculation');
   JPluginHelper::importPlugin('vmshipment');
   JPluginHelper::importPlugin('vmpayment');
   $_dispatcher = JEventDispatcher::getInstance();                                 //Should we add this? $inputOrder
   $_returnValues = $_dispatcher->trigger('plgVmOnUpdateOrderPayment',array(&$data,$old_order_status));

   //we need only one trigger for this whole thing.
  /*JPluginHelper::importPlugin('vmshipment');
         $_dispatcher = JEventDispatcher::getInstance();                                 //Should we add this? $inputOrder
         $_returnValues = $_dispatcher->trigger('plgVmOnUpdateOrderShipment',array(&$data,$old_order_status));
  */

  which means that

1) code for shipement plug-in would have to change to accomodate for plgVmOnUpdateOrderShipment to plgVmOnUpdateOrderPayment
     no big deal

2) the order of trigger call is not the same (i.e the workflow of events call change) and this is more difficult to assert on future changes

  The point is, that if you have a concerted set of plugins (because certains call back are called on certain plugins type and not for other --- best example is addToCart which is only available for custom type plugin) that expect to operate in certain call order (the virtuemart call-flow), then this could change in future update and break a site until custom/customer code is changed to adapt. This could lead to regression, while the end-user is making what seems an update.

It could be good to either better document the call-flow of the different triggers/plugin type and stick to it,
or allow a uniform callback set of functions for a range of plugins type and document call order in the call-flow.

This would make the code stable with its eco-system.

note : I was making the check as I verified if the call to plgVmOnUpdateSingleItem is back again as said in an other post in the forum, but I still see :

/*
//       JPluginHelper::importPlugin('vmcustom');
//       $_dispatcher = JDispatcher::getInstance();
//       $_returnValues = $_dispatcher->trigger('plgVmOnUpdateSingleItem',array($table,&$orderdata));
*/

[Milbo]

Mainly right.

We remove the 3 triggers and just do one trigger for it... the name will be just plgVmOnUpdateOrder. Exactly for the reason to write a download plugin with serials (what I am going todo also). Triggers take a lot time and I think the new system is easier, faster and even more flexible

[whisky]

Mainly right.

We remove the 3 triggers and just do one trigger for it... the name will be just plgVmOnUpdateOrder. Exactly for the reason to write a download plugin with serials (what I am going todo also). Triggers take a lot time and I think the new system is easier, faster and even more flexible

fair enough if the name change and the upgrade is just some kind of proxy call to old code, not a big deal.

But is there is any garantee that plug-ins are called by their type, in the order of plug-in import ?

Is there is any big picture overview of the difference plug-ins call-flow ?

I admit I learned it, by re-enabling a lot of vmdebug statements and patch on vmdebug itself, so to have a nicely formatted output on different calls, a better documentation could help in this area from the engine designer(s).