Thats great! I checked github repository and found it empty. I really like your approach sounds very similar to what I have, I wat to see and see if my code is up to plugin standards!!!
All best, Pablo On 7/10/09, Marijn <[email protected]> wrote: > > On Jul 9, 11:56 pm, Gandalf <[email protected]> wrote: >> Hello, >> >> Whats the status, a lot of noise and .....?? >> >> -Pablo > > Hi Pablo, I'm currently still in the process of splitting my old code > into this plugin. This isn't the only item in my agenda, hence it's > moving a bit slow. Anyway, I'm hoping to finish of some stuff by the > end of next week. > > - Marijn > >> >> On 6/29/09, Marijn <[email protected]> wrote: >> >> >> >> >> >> > I just put some of my code in the 1.2-marijn branch. I've got some >> > splitting out to do as most of it is related to the actual >> > implementation of the service provider that I use. I guess I need to >> > create a repo for that as well... >> >> > I'll post some of my thoughts on github later on this week. >> >> > On Jun 29, 11:31 pm, Marijn <[email protected]> wrote: >> >> On Jun 29, 8:44 am, Antoine Leclercq <[email protected]> >> >> wrote: >> >> >> > Hi, >> >> > @Marijn : >> >> > - I gave you access to the plugin repository. Tell me if it works >> >> > for >> >> > you. >> >> >> It's working. I just pushed a commit with the basic repo layout and >> >> plugin structure. If I find the time later on this week I'll create a >> >> branch for myself and commit my current code. >> >> >> > - About GitHub, it allows a more visual approach than symfony trac, >> >> > bugs >> >> > (issues) can be referenced and managed in a better way >> >> > (http://github.com/letscod/sfPaymentPlugin/issues) and the community >> >> > aspect >> >> > is really present throughout the dev process (rating, stats, >> >> > watchers...) so >> >> > I think we should have a go. We'll check in a few weeks how it's >> >> > going. >> >> > As >> >> > long as we refer explicitly on symfony's wiki that we use GitHub... I >> >> > don't >> >> > see any problem. >> >> >> > About the standard interface for payment, I am reviewing payment >> >> > methods >> >> > in >> >> > different languages and I think we should get some inspiration from >> >> > successful solutions. I still need some time to dig, but if you are >> >> > using >> >> > any smart and flexible online solution, feel free to share it. >> >> >> > Regards, >> >> >> > Antoine >> >> > LetsCod >> >> >> > On Sun, Jun 28, 2009 at 5:56 PM, Marijn >> >> > <[email protected]>wrote: >> >> >> > > On Jun 26, 5:08 pm, Antoine Leclercq <[email protected]> >> >> > > wrote: >> >> > > > Alright, >> >> >> > > > I'm preparing the project tools so that we can start working >> >> > > > together and >> >> > > > continue discussing in a more structured way. >> >> > > > You'll find a new plugin (hopefully it won't be another empty >> >> > > > shell) >> >> > > > on >> >> > > > *http://www.symfony-project.org/plugins/sfPaymentPlugin >> >> >> > > Could you provide me with access to it? I would love to create a >> >> > > branch of my existing code and send it out there. >> >> >> > > > The GitHub page is available on >> >> > > > *http://wiki.github.com/letscod/sfPaymentPlugin >> >> >> > > As much as I love github shouldn't we keep it in the trac wiki. >> >> > > That >> >> > > will also ease the process of filing bugs and referencing to wiki >> >> > > entries... >> >> >> > > > Following this thread, I think it's pretty obvious that we have >> >> > > > to >> >> > > > start >> >> > > > building an interface class as well as a dispatcher class (as >> >> > > > @Lee >> >> > > > suggested). I think they can be both located in a single plugin >> >> > > > sfPaymentPlugin. >> >> > > > The specific processing needed by the various payment options >> >> > > > will >> >> > > > then >> >> > > be >> >> > > > taken care of in individual plugins (sfPaymentPayPalPlugin, >> >> > > > sfPaymentAmazonPlugin, sfPaymentGoogleCheckoutPlugin, >> >> > > > sfPaymentPayboxPlugin...) in which the main class will be >> >> > > > implementing >> >> > > the >> >> > > > interface defined earlier. >> >> >> > > I currently use a very generic interface for that. The problem is >> >> > > that >> >> > > not all payment providers have a similar transaction process. >> >> >> > > > IMHO, if we want to strengthen the payment solution on Symfony, >> >> > > > and >> >> > > > eventually start developing a open source online shop solution >> >> > > > (that >> >> > > > was >> >> > > my >> >> > > > dream this morning), existing payment plugins (i.e. >> >> > > > sfAtosPaymentPlugin, >> >> > > > sfPaymentSIPSPlugin) should be reviewed and updated to work using >> >> > > > the >> >> > > same >> >> > > > system, therefore we can define a standard for online payment >> >> > > > under >> >> > > Symfony, >> >> > > > but this might well get pretty unmanageable... I haven't had time >> >> > > > yet to >> >> > > > review them in detail... +1 item to todo list. >> >> >> > > > Regards, >> >> >> > > > Antoine >> >> > > > LetsCod >> >> >> > > > On Fri, Jun 26, 2009 at 3:45 AM, [email protected] >> >> > > > <[email protected] >> >> > > >wrote: >> >> >> > > > > I think Simon Cast has a point, >> >> > > > > a)Paypalis crucial, but Amazon Payments is building traction, >> >> > > > > (it’s >> >> > > > > a solid affordable solution for many vendors) >> >> > > > > b) Support reoccuring payments. [I am thinking through the >> >> > > > > adapter >> >> > > > > pattern as each provider that supports it will have a different >> >> > > > > implementation. >> >> >> > > > > I would like to contribute to this project, [Just not as the >> >> > > > > lead, >> >> > > > > as >> >> > > > > I don't have the dedication at the mo] But I could definitely >> >> > > > > contribute as I have some good ecomm experience, and symfony >> >> > > > > really >> >> > > > > needs this (as it can boast about so much other stuff at the >> >> > > > > moment) >> >> >> > > > > Be sure to sign me up when this project gets kicked off. >> >> >> > > > > On Jun 24, 5:48 pm, Marijn <[email protected]> >> >> > > > > wrote: >> >> > > > > > On Jun 19, 7:43 am, Antoine Leclercq >> >> > > > > > <[email protected]> >> >> > > > > > wrote: >> >> >> > > > > > > Hi back, >> >> > > > > > > Alright, I'm back to Beirut and ready for real stuff. >> >> > > > > > > Symfony >> >> > > > > > > Live >> >> > > > > > > conferences were awesome and there were lots of nice level >> >> > > > > > > talks. >> >> >> > > > > > > @Marijn : Nice approach. We'll definitely go for wider >> >> > > > > > > solution in >> >> > > > > order to >> >> > > > > > > provide a standard way to process transactions. I need to >> >> > > > > > > dig >> >> > > > > > > a bit >> >> > > > > more on >> >> > > > > > > existing online payment solution before starting, hopefully >> >> > > > > > > next >> >> > > week. >> >> > > > > Let >> >> > > > > > > me know when you publish your code. It could be a start. >> >> >> > > > > > I just returned from my holiday and have a ton of things to >> >> > > > > > do. >> >> > > > > > I >> >> > > > > > guess this will take a little longer but maybe I'll just put >> >> > > > > > the >> >> > > > > > current stuff online as is. Send me a message if you're >> >> > > > > > interested in >> >> > > > > > having a look. >> >> >> > > > > > > @AJStoneham : That's exactly what we are trying to do. I >> >> > > > > > > think >> >> > > > > > > we >> >> > > all >> >> > > > > had >> >> > > > > > > the same feeling when trying to find a decent online >> >> > > > > > > payment >> >> > > solution >> >> > > > > for >> >> > > > > > > Symfony... >> >> >> > > > > > > Alright, if we want to move to a solid, active and >> >> > > > > > > maintainable >> >> > > > > development, >> >> > > > > > > I suggest we follow these practices : >> >> > > > > > > - Public Roadmap >> >> > > > > > > - Repository hosted properly (github.com seems a good >> >> > > > > > > solution >> >> > > for >> >> > > > > open >> >> > > > > > > source projects) >> >> > > > > > > - Unit and functional tests OK on every commit (use sismo >> >> > > > > > > when >> >> > > > > available, >> >> > > > > > > integrate doc-test?) >> >> > > > > > > - Updated documentation >> >> >> > > > > > > I'll take some more documentation on online payment methods >> >> > > > > > > and >> >> > > > > existing >> >> > > > > > > solutions certainly next week. >> >> > > > > > > Feel free to share links or snippets of code here. >> >> >> > > > > > > See you guys later, >> >> >> > > > > > > Antoine >> >> >> > > > > > > On Wed, Jun 10, 2009 at 7:39 PM, Marijn < >> >> > > [email protected] >> >> > > > > >wrote: >> >> >> > > > > > > > On Jun 10, 4:47 pm, AJStoneham <[email protected]> >> >> > > > > > > > wrote: >> >> > > > > > > > > PS, sounds like your using the wrong wheel for api >> >> > > > > > > > > requests. >> >> > > ;-) >> >> >> > > > > > > > What wheel do you suggest? >> >> >> > > > > > > > > On Jun 9, 3:25 pm, Marijn >> >> > > > > > > > > <[email protected]> >> >> > > wrote: >> >> >> > > > > > > > > > P.s. it makes use of sfWebBrowserPlugin to prevent >> >> > > reinventing >> >> > > > > the >> >> > > > > > > > > > wheel for api requests but it can be injected with >> >> > > > > > > > > > any >> >> > > > > > > > > > object >> >> > > > > that >> >> > > > > > > > > > implements a sfWebBrowserInterface >> >> >> > > > > > > > > > On Jun 10, 12:23 am, Marijn >> >> > > > > > > > > > <[email protected]> >> >> > > > > wrote: >> >> >> > > > > > > > > > > Hi everybody, >> >> >> > > > > > > > > > > I currently have a private plugin that manages a >> >> > > > > > > > > > > dutch >> >> > > payment >> >> > > > > > > > > > > service. The approach I took was quite similar, >> >> > > > > > > > > > > using >> >> > > > > interfaces that >> >> > > > > > > > > > > can be implemented by any object to define >> >> > > > > > > > > > > transactions. I >> >> > > > > created a >> >> > > > > > > > > > > global transaction manager that manages the process >> >> > > > > > > > > > > that >> >> > > can be >> >> > > > > > > > > > > injected with any type of payment service adapter. >> >> > > > > > > > > > > This can >> >> > > be >> >> > > > > either >> >> > > > > > > > > > > hooked into the event manager or by extending an >> >> > > > > > > > > > > abstract >> >> > > > > module. >> >> > > > > > > > > > > Currently I also need to create an adapter >> >> > > > > > > > > > > forpaypal >> >> > > payments >> >> > > > > but >> >> > > > > > > > not >> >> > > > > > > > > > > with the genericpaypalstructure but their paypro >> >> > > > > > > > > > > api >> >> > > > > > > > > > > (or >> >> > > > > whatever >> >> > > > > > > > > > > its called). >> >> >> > > > > > > > > > > I would love to share the code if we all agree it's >> >> > > structure >> >> > > > > is >> >> > > > > > > > > > > decent enough:-) >> >> >> > > > > > > > > > > Let me know. >> >> >> > > > > > > > > > > Marijn >> >> >> > > > > > > > > > > On Jun 9, 10:31 am, Antoine Leclercq < >> >> > > > > [email protected]> >> >> > > > > > > > > > > wrote: >> >> >> > > > > > > > > > > > Sorry I haven't replied earlier, I'm kind of busy >> >> > > > > > > > > > > > during >> >> > > my >> >> > > > > trips >> >> > > > > > > > to France. >> >> > > > > > > > > > > > @Russen : Please >> >> ... >> >> read more » > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
