I was going to work on an extension to add the ability to integrate with Payment gateways in a nice decoupled application agnostic sort of way. My thought was to start with PayPal and adapt the code in here: http://github.com/johnboxall/django-paypal Migrating from Django ORM to SQLAlchemy and using the Flask-SQLAlchemy Extension and possibly the signals if they are needed. Does this seem like a reasonable extension to Flask? Is anyone doing anything like this already? Does anyone have any other thoughts / observations / wants to join in? Thanks, Jim.
On 07/31/2010 05:49 AM, JimG wrote: > I was going to work on an extension to add the ability to integrate with > Payment gateways in a nice decoupled application agnostic sort of way. > > My thought was to start with PayPal and adapt the code in here: > http://github.com/johnboxall/django-paypal Migrating from Django ORM to > SQLAlchemy and using the Flask-SQLAlchemy Extension and possibly the > signals if they are needed. > > Does this seem like a reasonable extension to Flask? Is anyone doing > anything like this already? Does anyone have any other thoughts / > observations / wants to join in? I have never done any e-commerce myself, but having infrastructure to support this kind of thing does sound like a good idea. A few suggestions: 1. I wouldn't port directly from the Django library. You'll probably get good code from it, but I would start from scratch and only consult the Django library when you need help doing a particular thing rather than starting from Django and trying to Flaskify it. (New word I just made up.) 2. Try to avoid coupling to a particular database layer if you can. SQLAlchemy seems to be in the lead right now, but it would be better if you could write it without binding to the database. 3. Flask-Cash doesn't do quite as good a job of explaining it as Flask-Payment or Flask-PayPal would. It also sounds too much like cache, which could confuse people if I release Flask-Cache. -- Regards, Matthew "LeafStorm" Frazier http://leafstorm.us/
> > 2. Try to avoid coupling to a particular database layer if you can. > SQLAlchemy seems to be in the lead right now, but it would be better if > you could write it without binding to the database. This raises a good general point about extensions. To what extent should there be cross-dependencies between various extensions ? For example, many extensions may benefit from Flask-Babel, but is it a good idea to make Flask-Babel the "official" way to do i18n in Flask ? Perhaps yes, for convenience, but then it becomes more and more a core part of the framework. This is the problem with Django - you can use lots of 3rd party apps, but many depend on contrib.auth, which enforces one way of authentication that simply doesn't suit a lot of projects.
Hi, I think this strongly depends on the kind of extension. For example hard depending on Flask-Sqlalchemy for an extension is a bad idea because people might have different data stores. If however someone writes a Flask-Storage extension that provides abstract interfaces for concrete storage backends (Sqlalchemy, CouchDB etc.) and ways for other extensions to hook into that, I have no problem for an extension to depend on that obviously. Regarding Babel the question is if there are other modules with similar feautes that people might want to use or if Babel can be seen as defacto standard. Regards, Armin (sent from a handheld device) On 31.07.2010, at 18:01, Dan Jacob <danjac354@gmail.com> wrote: >> >> 2. Try to avoid coupling to a particular database layer if you can. >> SQLAlchemy seems to be in the lead right now, but it would be better if >> you could write it without binding to the database. > > This raises a good general point about extensions. To what extent > should there be cross-dependencies between various extensions ? > > For example, many extensions may benefit from Flask-Babel, but is it a > good idea to make Flask-Babel the "official" way to do i18n in Flask ? > Perhaps yes, for convenience, but then it becomes more and more a core > part of the framework. This is the problem with Django - you can use > lots of 3rd party apps, but many depend on contrib.auth, which > enforces one way of authentication that simply doesn't suit a lot of > projects.
> I think this strongly depends on the kind of extension. For example hard depending on Flask-Sqlalchemy for an extension is a bad idea because people might have different data stores. > > If however someone writes a Flask-Storage extension that provides abstract interfaces for concrete storage backends (Sqlalchemy, CouchDB etc.) and ways for other extensions to hook into that, I have no problem for an extension to depend on that obviously. Is such an abstract interface practical ? Different storage backends require different opimization and design strategies, and trying to abstract over that can lead to very inefficient solutions. For an extension like Flask-Payment it would be better to just pass the relevant data back to the application and let the app deal with the storage it's own way. For example, Flask-OpenID just takes care of fetching the correct identity information, it doesn't care if you store that data in your session or MySQL or Couch.
On 31 July 2010 17:50, Dan Jacob <danjac354@gmail.com> wrote: >> I think this strongly depends on the kind of extension. For example hard depending on Flask-Sqlalchemy for an extension is a bad idea because people might have different data stores. >> >> If however someone writes a Flask-Storage extension that provides abstract interfaces for concrete storage backends (Sqlalchemy, CouchDB etc.) and ways for other extensions to hook into that, I have no problem for an extension to depend on that obviously. > > Is such an abstract interface practical ? Different storage backends > require different opimization and design strategies, and trying to > abstract over that can lead to very inefficient solutions. Traditionally this is true, but I would expect Flask-Storage would be used for smallish use-cases like the Payment processor, rather than for full-blown application data access. For the smaller cases, an inefficient and dumb "lowest common denominator" might be enough. The benefits of such a system are obvious, any extension which depended on a storage system could depend on any storage system.
On 31 July 2010 17:54, Ali Afshar <aafshar@gmail.com> wrote: > On 31 July 2010 17:50, Dan Jacob <danjac354@gmail.com> wrote: >>> I think this strongly depends on the kind of extension. For example hard depending on Flask-Sqlalchemy for an extension is a bad idea because people might have different data stores. >>> >>> If however someone writes a Flask-Storage extension that provides abstract interfaces for concrete storage backends (Sqlalchemy, CouchDB etc.) and ways for other extensions to hook into that, I have no problem for an extension to depend on that obviously. >> >> Is such an abstract interface practical ? Different storage backends >> require different opimization and design strategies, and trying to >> abstract over that can lead to very inefficient solutions. > > Traditionally this is true, but I would expect Flask-Storage would be > used for smallish use-cases like the Payment processor, rather than > for full-blown application data access. For the smaller cases, an > inefficient and dumb "lowest common denominator" might be enough. The > benefits of such a system are obvious, any extension which depended on > a storage system could depend on any storage system. > Sorry to answer my own post, but Flask-Storage could just be an interface that all storage extensions should provide. Something like dbapi but at a higher level.
>> Traditionally this is true, but I would expect Flask-Storage would be >> used for smallish use-cases like the Payment processor, rather than >> for full-blown application data access. For the smaller cases, an >> inefficient and dumb "lowest common denominator" might be enough. The >> benefits of such a system are obvious, any extension which depended on >> a storage system could depend on any storage system. >> I agree that would be handy, the problem is that once you have a Flask-Storage it will not be used for it's intended purpose - developers will say "look, you can run the same code in SQLAlchemy, GAE, and MongoDB! Just change this one setting !" > > Sorry to answer my own post, but Flask-Storage could just be an > interface that all storage extensions should provide. Something like > dbapi but at a higher level. > That might work, but only for very simple cases. Problem is when dealing with slightly more complicated cases like relationships, which are handled in completely different ways by different backends - RDBMS foreign keys, MongoDB embedded documents and so on. Going back to Flask-Payment, what I'd prefer to see is a library that takes the pain out of calling Paypal (or Google or whatever), takes some inputs, calls whatever web services, and returns some outputs - such as success/reason for failure/subscription period/etc, which my app then stores in whatever backend model I'm using. It shouldn't need to store anything itself.
http://code.google.com/p/gchecky/ ??? -- Thadeus On Sat, Jul 31, 2010 at 12:11 PM, Dan Jacob <danjac354@gmail.com> wrote: >>> Traditionally this is true, but I would expect Flask-Storage would be >>> used for smallish use-cases like the Payment processor, rather than >>> for full-blown application data access. For the smaller cases, an >>> inefficient and dumb "lowest common denominator" might be enough. The >>> benefits of such a system are obvious, any extension which depended on >>> a storage system could depend on any storage system. >>> > I agree that would be handy, the problem is that once you have a > Flask-Storage it will not be used for it's intended purpose - > developers will say "look, you can run the same code in SQLAlchemy, > GAE, and MongoDB! Just change this one setting !" > >> >> Sorry to answer my own post, but Flask-Storage could just be an >> interface that all storage extensions should provide. Something like >> dbapi but at a higher level. >> > > That might work, but only for very simple cases. Problem is when > dealing with slightly more complicated cases like relationships, which > are handled in completely different ways by different backends - RDBMS > foreign keys, MongoDB embedded documents and so on. > > Going back to Flask-Payment, what I'd prefer to see is a library that > takes the pain out of calling Paypal (or Google or whatever), takes > some inputs, calls whatever web services, and returns some outputs - > such as success/reason for failure/subscription period/etc, which my > app then stores in whatever backend model I'm using. It shouldn't need > to store anything itself. >
I've created http://github.com/LeonigMig/flask-payment and I'm going to start researching today by - reading the Flask docs on extensions again - looking at the source of existing Flask Modules. - looking at the source of existing Python payment gateway integrations. Will post to the Flask group if I get anywhere. Any additional guidance gratefully received - this is new territory for me! Cheers, Jim. On 31 July 2010 19:35, Thadeus Burgess <thadeusb@thadeusb.com> wrote: > http://code.google.com/p/gchecky/ ??? > > -- > Thadeus > > > > > > On Sat, Jul 31, 2010 at 12:11 PM, Dan Jacob <danjac354@gmail.com> wrote: > >>> Traditionally this is true, but I would expect Flask-Storage would be > >>> used for smallish use-cases like the Payment processor, rather than > >>> for full-blown application data access. For the smaller cases, an > >>> inefficient and dumb "lowest common denominator" might be enough. The > >>> benefits of such a system are obvious, any extension which depended on > >>> a storage system could depend on any storage system. > >>> > > I agree that would be handy, the problem is that once you have a > > Flask-Storage it will not be used for it's intended purpose - > > developers will say "look, you can run the same code in SQLAlchemy, > > GAE, and MongoDB! Just change this one setting !" > > > >> > >> Sorry to answer my own post, but Flask-Storage could just be an > >> interface that all storage extensions should provide. Something like > >> dbapi but at a higher level. > >> > > > > That might work, but only for very simple cases. Problem is when > > dealing with slightly more complicated cases like relationships, which > > are handled in completely different ways by different backends - RDBMS > > foreign keys, MongoDB embedded documents and so on. > > > > Going back to Flask-Payment, what I'd prefer to see is a library that > > takes the pain out of calling Paypal (or Google or whatever), takes > > some inputs, calls whatever web services, and returns some outputs - > > such as success/reason for failure/subscription period/etc, which my > > app then stores in whatever backend model I'm using. It shouldn't need > > to store anything itself. > > >
Jim, I noticed that inside the paypal class there was a ton of hard coded strings. Have you though of extracting them out in the `yourpaypal.settings.sample` and passing them to the paypal class? On Sun, Aug 1, 2010 at 7:10 AM, JimG <j.gumbley@gmail.com> wrote: > I've created http://github.com/LeonigMig/flask-payment and I'm going to > start researching today by > - reading the Flask docs on extensions again > - looking at the source of existing Flask Modules. > - looking at the source of existing Python payment gateway integrations. > Will post to the Flask group if I get anywhere. Any additional guidance > gratefully received - this is new territory for me! > Cheers, Jim. > On 31 July 2010 19:35, Thadeus Burgess <thadeusb@thadeusb.com> wrote: >> >> http://code.google.com/p/gchecky/ ??? >> >> -- >> Thadeus >> >> >> >> >> >> On Sat, Jul 31, 2010 at 12:11 PM, Dan Jacob <danjac354@gmail.com> wrote: >> >>> Traditionally this is true, but I would expect Flask-Storage would be >> >>> used for smallish use-cases like the Payment processor, rather than >> >>> for full-blown application data access. For the smaller cases, an >> >>> inefficient and dumb "lowest common denominator" might be enough. The >> >>> benefits of such a system are obvious, any extension which depended on >> >>> a storage system could depend on any storage system. >> >>> >> > I agree that would be handy, the problem is that once you have a >> > Flask-Storage it will not be used for it's intended purpose - >> > developers will say "look, you can run the same code in SQLAlchemy, >> > GAE, and MongoDB! Just change this one setting !" >> > >> >> >> >> Sorry to answer my own post, but Flask-Storage could just be an >> >> interface that all storage extensions should provide. Something like >> >> dbapi but at a higher level. >> >> >> > >> > That might work, but only for very simple cases. Problem is when >> > dealing with slightly more complicated cases like relationships, which >> > are handled in completely different ways by different backends - RDBMS >> > foreign keys, MongoDB embedded documents and so on. >> > >> > Going back to Flask-Payment, what I'd prefer to see is a library that >> > takes the pain out of calling Paypal (or Google or whatever), takes >> > some inputs, calls whatever web services, and returns some outputs - >> > such as success/reason for failure/subscription period/etc, which my >> > app then stores in whatever backend model I'm using. It shouldn't need >> > to store anything itself. >> > > >
Hi, Thanks for taking a look. That will be my plan - passing all that stuff through from the controller classes or the Flask config object- unless it really is something that is static (such as the Paypal API which that class supports). That PayPal class is a direct copy paste from : http://djangosnippets.org/snippets/1181/ in a very rough form, I need to do more work. Similarly there is a lot of copy paste from Flask Mail, who's API I want to imitate. At the moment I'm puzzling over how to deal with that PayPal class - whether it belongs in the Payment module or I should use a package. Cheers, Jim. <http://djangosnippets.org/snippets/1181/> On 4 August 2010 14:29, Silas Baronda <silas.baronda@gmail.com> wrote: > Jim, > > I noticed that inside the paypal class there was a ton of hard coded > strings. Have you though of extracting them out in the > `yourpaypal.settings.sample` and passing them to the paypal class? > > On Sun, Aug 1, 2010 at 7:10 AM, JimG <j.gumbley@gmail.com> wrote: > > I've created http://github.com/LeonigMig/flask-payment and I'm going to > > start researching today by > > - reading the Flask docs on extensions again > > - looking at the source of existing Flask Modules. > > - looking at the source of existing Python payment gateway integrations. > > Will post to the Flask group if I get anywhere. Any additional guidance > > gratefully received - this is new territory for me! > > Cheers, Jim. > > On 31 July 2010 19:35, Thadeus Burgess <thadeusb@thadeusb.com> wrote: > >> > >> http://code.google.com/p/gchecky/ ??? > >> > >> -- > >> Thadeus > >> > >> > >> > >> > >> > >> On Sat, Jul 31, 2010 at 12:11 PM, Dan Jacob <danjac354@gmail.com> > wrote: > >> >>> Traditionally this is true, but I would expect Flask-Storage would > be > >> >>> used for smallish use-cases like the Payment processor, rather than > >> >>> for full-blown application data access. For the smaller cases, an > >> >>> inefficient and dumb "lowest common denominator" might be enough. > The > >> >>> benefits of such a system are obvious, any extension which depended > on > >> >>> a storage system could depend on any storage system. > >> >>> > >> > I agree that would be handy, the problem is that once you have a > >> > Flask-Storage it will not be used for it's intended purpose - > >> > developers will say "look, you can run the same code in SQLAlchemy, > >> > GAE, and MongoDB! Just change this one setting !" > >> > > >> >> > >> >> Sorry to answer my own post, but Flask-Storage could just be an > >> >> interface that all storage extensions should provide. Something like > >> >> dbapi but at a higher level. > >> >> > >> > > >> > That might work, but only for very simple cases. Problem is when > >> > dealing with slightly more complicated cases like relationships, which > >> > are handled in completely different ways by different backends - RDBMS > >> > foreign keys, MongoDB embedded documents and so on. > >> > > >> > Going back to Flask-Payment, what I'd prefer to see is a library that > >> > takes the pain out of calling Paypal (or Google or whatever), takes > >> > some inputs, calls whatever web services, and returns some outputs - > >> > such as success/reason for failure/subscription period/etc, which my > >> > app then stores in whatever backend model I'm using. It shouldn't need > >> > to store anything itself. > >> > > > > > >
Thanks - yes to be honest if django paypal wasn't so bound to the Django ORM it would be practically no work to port it, I'm happy to try and persue making it persistence agnostic. I thought about the name too, "Flask-Cache" ambiguity is one issue - the other is it doesn't sound very Flaskified name- however I do want to try and build a general payment gateway rather than Paypal specific. How about "Flask-Purse" or "Flask-Wallet"? Although you'd need a large pocket to fit them both in! I suppose with Flask-Payment at least it "does what it says on the tin". Perhaps then it could have a funky line drawing of a Purse or a Wallet? Cheers, Jim. On 31 July 2010 16:48, LeafStorm <leafstormrush@gmail.com> wrote: > On 07/31/2010 05:49 AM, JimG wrote: > > I was going to work on an extension to add the ability to integrate with > > Payment gateways in a nice decoupled application agnostic sort of way. > > > > My thought was to start with PayPal and adapt the code in here: > > http://github.com/johnboxall/django-paypal Migrating from Django ORM to > > SQLAlchemy and using the Flask-SQLAlchemy Extension and possibly the > > signals if they are needed. > > > > Does this seem like a reasonable extension to Flask? Is anyone doing > > anything like this already? Does anyone have any other thoughts / > > observations / wants to join in? > > I have never done any e-commerce myself, but having infrastructure to > support this kind of thing does sound like a good idea. A few suggestions: > > 1. I wouldn't port directly from the Django library. You'll probably get > good code from it, but I would start from scratch and only consult the > Django library when you need help doing a particular thing rather than > starting from Django and trying to Flaskify it. (New word I just made up.) > > 2. Try to avoid coupling to a particular database layer if you can. > SQLAlchemy seems to be in the lead right now, but it would be better if > you could write it without binding to the database. > > 3. Flask-Cash doesn't do quite as good a job of explaining it as > Flask-Payment or Flask-PayPal would. It also sounds too much like cache, > which could confuse people if I release Flask-Cache. > -- > Regards, Matthew "LeafStorm" Frazier > http://leafstorm.us/ >