Remove of $app->redirect

[stAn99]

Hello,
before releasing new stable VM2.0.1 into public, i'd be extremely glad if you removed private function declarations from VM especially in /components/com_virtuemart/helpers/cart.php as i'd like to call them with my extension and at 2.0.0 there is no other way to call them then to copy and modify them.  The same for many other functions in VM - this way the external developement will be much harder, especially when adding new features to VM, but still want to provide full compatibility. Sometimes is better to call parent::function then create a full class override.

Another recommendation:

In general i'd remove $mainframe->redirect from all the important handlers and rather wrap them with returning a structural data such as

$return['valid'] = false;
$return['command'] = redirect ...
$return['param0'] = url ...
$return['param1'] = msg ...
return $return;

or simmilar

These redirects should not be in any non-UI classes.

I believe Joomla success is based on it's extensibility and if we make Virtuemart as much extensible as Joomla it will be a very solid base for everyday ecommerce.

Best Regards,
Stan

[osp]

Hello,
before releasing new stable VM2.0.1 into public, i'd be extremely glad if you removed private function declarations from VM especially in /components/com_virtuemart/helpers/cart.php as i'd like to call them with my extension and at 2.0.0 there is no other way to call them then to copy and modify them.  The same for many other functions in VM - this way the external developement will be much harder, especially when adding new features to VM, but still want to provide full compatibility. Sometimes is better to call parent::function then create a full class override.

Another recommendation:

In general i'd remove $mainframe->redirect from all the important handlers and rather wrap them with returning a structural data such as

$return['valid'] = false;
$return['command'] = redirect ...
$return['param0'] = url ...
$return['param1'] = msg ...
return $return;

or simmilar

These redirects should not be in any non-UI classes.

I believe Joomla success is based on it's extensibility and if we make Virtuemart as much extensible as Joomla it will be a very solid base for everyday ecommerce.

Best Regards,
Stan

Hello,

I very vote for removing redirects from cart controller.
I implemented direct payment and shipmet selection in cart I had to modify controller. Next time new version will be out I'll have to do it again.

[Milbo]

I do not understand this suggestion. Why do you need to modify the controller? The plugins handle it. So you may need another trigger.

The function stay private for security reasons. So do you write a payment/shipment plugin? Or what you try to achieve?

http://www.joomlager.de/
http://www.joomlager.de/joomla-17/3-joomla-17-rewrite-jrouter
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26942

[osp]

I do not understand this suggestion. Why do you need to modify the controller? The plugins handle it. So you may need another trigger.

The function stay private for security reasons. So do you write a payment/shipment plugin? Or what you try to achieve?

http://www.joomlager.de/
http://www.joomlager.de/joomla-17/3-joomla-17-rewrite-jrouter
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26942

Ok Milbo, maybe I'm doing things wrong. Maybe you'll have a tip how to achieve this behaviour in better way.
What I need is selection of the payment and shipment directly in the very first step of the cart. See snapshot in attachment how it looks.
What I did is parametrisation of setShipment and setPayment to enable avoid of redirects. Then I modified checkout to simply enable shipment and payment selection in the very first step of the cart.
Then view was modified to setup shipment/payment directly.

Thx in advance.

Code Select Expand


//CONTROLLER cart.php
public function setshipment($noredir = false) {
...

function setpayment($noredir=false) {
...

public function checkout() {
  $cart = VirtueMartCart::getCart();
  $this->setshipment(true);
  $this->setpayment(true);


// VIEW - cart/view.html.php
} else if ($layoutName == 'default') {
$this->lSelectShipment();
$this->lSelectPayment();

$cart->prepareCartViewData();
        ...


[Studio 42]

My think where to add a setter in config.

"See payment and shipment in default view"

PaymentShipmentInCartDefault as Config value and test for it automatical on config setting.

Please provide the complet files(or Patch) that we can examin your changes and why not add it to the core files.

[osp]

My think where to add a setter in config.

"See payment and shipment in default view"

PaymentShipmentInCartDefault as Config value and test for it automatical on config setting.

Please provide the complet files(or Patch) that we can examin your changes and why not add it to the core files.

Global setting would be accurate for this case.
See attachments.
Changes are commented with OSP mark...


[attachment cleanup by admin]

[bunglehaze]

ondrejspilka, I have not tried your solution but this is something I have mentioned a few times (or something similar) to try and streamline the checkout system, I think the checkbox system works really well and reduces page loads so when I have made a copy of my site I will give it a try.

If the checkout page is laid out like your image I think it will be an improvement on the current system which IMHO is very clunky

[osp]

ondrejspilka, I have not tried your solution but this is something I have mentioned a few times (or something similar) to try and streamline the checkout system, I think the checkbox system works really well and reduces page loads so when I have made a copy of my site I will give it a try.

If the checkout page is laid out like your image I think it will be an improvement on the current system which IMHO is very clunky

Hi bunglehaze,

we will see, I think Electrocity's suggestion is fine for everyone.

[Milbo]

In fact, when you have a single page checkout,... I just would not use the whole mechanic which leads you through the views to enter the stuff. And a config setting is not needed. You just must do it with js so, that people dont come into the checkout process.

[osp]

In fact, when you have a single page checkout,... I just would not use the whole mechanic which leads you through the views to enter the stuff. And a config setting is not needed. You just must do it with js so, that people dont come into the checkout process.

Yea, this is also obvious. But I don't see any easy way how to achieve this in VM2. The simplest solution was to slightly modify basket logic and it works.

BTW, the basket logic is not a property of the shop engine itself. It depends on customer needs always, it's a rule.
In company, where I'm developmnet chief, we implemented tens of completely customized shops (ASP.NET / this one shop is not this case, elspeedo.bmesoft.cz is shop for friends from paragliding school where I learned to fly ).
Each of them has a bit different basket, shipment a payment logic. Thus, customization of stepped/wizarded basket logic will VM2 need, in near or later future.

So Milbo, what is your idea? Write separate controller basket task? Why not, but what is a correct way without need of modifying controller?

[stAn99]

Hello Milbo, yes i am developing single page checkout as well. I will show you what sort of modifications i needed within the core files of VM2, so you you have a better view of this.

First of all i had to create my own controller (option=com_virtuemart&view=opc) which causes a fatal error on joomal1.5 because of calling
Line 91 in Virtuemart 2.0.3H (and all the other versions) in /components/com_virtuemart/virtuemart.php

Code Select Expand

$dispatcher->trigger('onVmSiteController', $_controller);
even when i am loading the controller from the system plugin.

The correct format of this line should be

Code Select Expand

$dispatcher->trigger('onVmSiteController', array($_controller ));

Hence loading the checkout from my own controller and view i had to do this modification on all j1.5 installs. (other versions of joomla ignore this bug)

The modifications in the overrided cart controller currently include
- support for registration with already existing email account
- redirects changed to cart page instead of BT edit or other edit pages
- possible modification of the databases where the order is saved and others
- address modifications (such as when required by installments companies)
- special userfields handling on checkout (EU-VAT, upload, etc...)

I also had to override the vmplugin wrapper class to be able to load payment and shipping plugins several times per one page load due to different totals combination. (so i don't have to make 25 javascript calls per 5 payment method and 5 shipping methods)

Code Select Expand


protected function getVmPluginMethod($int){

// i must have commented this line to be able to call specific functions more than once per page load
                //if($this->_vmpCtable===0){
$db = JFactory::getDBO();

if(!class_exists($this->_configTableClassName))require(JPATH_VM_ADMINISTRATOR.DS.'tables'.DS.$this->_configTableFileName.'.php');
$this->_vmpCtable = new $this->_configTableClassName($db);
if($this->_xParams!==0){

// some plugins are missing some of the params:
//echo $this->_xParams.'<br />';
//echo var_export($this->_varsToPushParam, true);
if ($this->_xParams == 'payment_params')
{
  if (empty($this->_varsToPushParam['payment_logos']))
   {
     $this->_varsToPushParam['payment_logos'] = array('', 'char');
   }
}
                                // stAn: always refresh parameters
$this->_vmpCtable->setParameterable($this->_xParams,$this->_varsToPushParam);
}
else
{
  //die('here getVmPluginmethod');
}

// $this->_vmpCtable = $this->createPluginTableObject($this->_tablename,$this->tableFields,$this->_loggable);
//}
//else
{
//echo $this->_vmpCtable; die();
}
// stAn: always load it
return $this->_vmpCtable->load($int);
}


All of the overrides are loaded with joomla framework and as far as some 3rd party extension don't include the original VM files directly with require or require_once they all work well.

Best Regards,
Stan