Archive pour octobre 2010

driver.product la class de gestion des produit du front

mercredi 27 octobre 2010

et voila, afin de rendre plus souple le fonctionnement sans avoir à intervenir sur le core, 2 nouvelles methodes sont apparu dans le driver.

Ces 2 methodes sont static et appelé directement a tarvers la class product.

Soit :

product::get_adjust_price()

et

product::get_option_data()

La methode get_adjust_price est utilisé dans le panier, pour prendre en charge la modification des prix d’un produit par les module de type Aca (type product)
il est absoluement necessaire de definir une var nommé price pour que cette methode soit active
ex:

//! flag price
$this->price = true;

Elle prend en arguement un tableau qui lui fournis le pris de base, l’id produit et la quantité

La methode get_option_data n’ a vocation à étre appelé , elle est gerer directement dans la function stament_query, qui permet la mise en forme de l’object produit retourné.

Les module utilisant cette methode permettent donc de recuperer dans l’object premier leur propre element.

Apercu de la definition d’un module ACA utilisant ces methodes

/**
Add data in driver.product
*/
public function get_option_data($product_array){
$product_array[‘price_break’]=$this->load_db_values($product_array[‘products_id’]);
return $product_array;
}

/**
fonction ajustement price en fonction quantité
*/
public function adjust_price($product_array){
$pid = tep_get_prid($product_array[‘products_id’]);
$res=product::get_item($pid);

if(count($res->price_break)>0){
foreach($res->price_break as $qt=>$pr)
if($product_array[‘products_quantity’]>=$qt)$result=$pr;
}

return (isset($result)?$result : $product_array[‘products_price’]);
}

enregsirement des commandes / gestion des moduel de paiement

mardi 26 octobre 2010

la gestion des paiements, avec leur lots de différence entre les mode bancaire, et le fait de quitter la shop, pour y revenir ensuite, posent quelques question, quant à la transmission des information, et l’enregistrement des commandes.

L’osCSS 2 contient sur ce sujet 2  series de tables jummelle , les orders et les holding_orders.

Les holding order servaient a présent uniquement a recupérer les commande « perdu » ou non validés.

L’evolution qui devrait apparaitre, va changer quelques peu la procedure des enregistrement des orders.

La table orders, reste donc la table des comment dûment validé et confirmé, et les tables holding_orders, passe donc, de leur usage de commande perdues à un usage de pre-commande.

Cette transition permettra donc, de pre-enregsitré toutes les commandes, avant affichage et ainsi generé un numero unique de reference pour cette commande.

Ce numero pourra donc facielment être transmis au different module bancaire, comme Id unique, et utilisé lors des retour bancaire comme reference.

Dans le cas d’une confimation bancaire, arrivant sur la shop, avant le retour du client sur la page checkout, la page response du module prendra donc en charge la convertion des table holding_orders, vers order; et aussi la prise en charge de l’update du status en fonction de la reponse.

Dans le cas ou le client revient sur la boutique via la page process, c’est cette derbière qui prendra en charge la bascule de holding vers orders.
La page response dans ce cas ne prendra en charge que l’update du status.

Concretement, ces modification vont ce traduire par:

  • Ajout d’un champs dans la table orders, qui conservera l’historique de l’id de la table holding l’ayany generé
  • Evolution de la class process pour prendre en charge les holding et les orders
  • Ajout d’un methode dans la class process pou rmigrer une pre-commande en commande, et suppression de la pre-commande


il n’y a pus qu’a. :)