eZ CyberMut discussions

Next topic

Author	Message
Pascal Specht	Tuesday 27 November 2007 4:47:30 am This is the place to share technical details or questions concerning the eZ CyberMut extension. (see http://ez.no/community/contribs/workflow/ezcybermut)
Pascal Specht	Monday 03 December 2007 9:42:24 am The error messages in the checker can be corrected this way to get more information about why a paiement was rejected: $this->logger->writeTimedString('eZCyberMut : Post parameters were: '.$Verified_Result);
H-Works Agency	Wednesday 05 December 2007 10:06:03 am Great Pascal ! I am gonna use this module right away. EZP is Great
Pascal Specht	Wednesday 12 December 2007 12:34:02 pm Hey Martin, no news = good news? On our side the gateway is now in production since first of december, and we didn't have any problem so far, now with more than a hundred transactions... Cheers, </Pascal>
Guillaume HH	Saturday 05 April 2008 1:59:34 am Hi! I'm looking for a "Société Générale" solution. Do you think I can upgrade your extension or I must to develop one "from scratch" ? Thanks Guillaume
Pascal Specht	Saturday 05 April 2008 10:47:04 am Hi Guillaume, Société Générale is part of the SIPS/ATOS solution. Martin's ezSIPS extension will therefore fit your needs. eZCyberMut will not work. </Pascal>
Guillaume HH	Tuesday 08 April 2008 3:29:07 am Ok! Thanks for the correct extension's name! ++ Guillaume
H-Works Agency	Friday 11 April 2008 4:13:01 am Hi Pascal, Don't you think we should use the "serialize" function to store our datas into "data_text_1" and "data_text_2" instead of the painful xml dom ? I see only advantage with this technique : - It use 2 lines of code to store & retrieve (serialize($array) \| unserialize($field)) instead of tens of lines of codes and complexe functions for XML. - It make our extension ezp 4.0 compatible by avoiding XML use. - Its way more flexible as "serialize" can handle any kind of var type. What do you think ? EZP is Great
Pascal Specht	Friday 11 April 2008 4:59:38 am Hi Martin, that would be definitively a smarter way to store data, I agree. In my case though I have many other places now where I rely on parsing a DOM inside the order's data_text fields, when building the invoice, tracking the shipping number, keeping track of downloads etc. Now that everything is in XML, I will have a hard time to unroll this. The other (small) advantage of having XML here is the human readeable format in logs and debug sessions. I will have to look into this issue, but for the moment I did not decide to switch to version 4: I've seen too many issues with the new version to rely on it for production servers for the moment. So in one word: People who don't rely on the XML storage should feel free to modify the extension's code to use the binary storage, it should work without problems. If I find some time I can also update the extension here to use your code. </Pascal>