Re: Interesting code abstraction Challenge
Thanks for the thoughts Preston! > I think a base class with subclasses is the best approach. > > Define as much common behavior as possible, set up defaults for those > fields needed by your outbound API Indeed, thanks for the confirmation. I think it's time for experimentation! > How are you handling the branching lookup of what subclass to use? > You might name the subclasses in some way that they can be derived > from the partner URL - or some other way that intelligently selects > the subclass for you Incoming requests for processing would have associations with specific backend partners defined in the database and processed as part of the request, so the branching will be tied into this. > I assume you've looked at django-piston I had not seen it, so thank you for pointing me in this direction! ~Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Interesting code abstraction Challenge
I think a base class with subclasses is the best approach. Define as much common behavior as possible, set up defaults for those fields needed by your outbound API How are you handling the branching lookup of what subclass to use? You might name the subclasses in some way that they can be derived from the partner URL - or some other way that intelligently selects the subclass for you I assume you've looked at django-piston -Preston On Oct 24, 7:43 am, Jason Beaudoin wrote: > Anyone else have thoughts on this, with respect to design > considerations, implementing in python versus using some of django's > tools.. ? > > > > On Fri, Oct 23, 2009 at 8:22 AM, Jason Beaudoin > wrote: > > 2009/10/23 kmike : > > >> Maybe you don't have enough information to make an abstraction right > >> now. If so I suggest to actually implement several API's in a dumb > >> way. After that it'll be clear what are the differences and what are > >> the common parts so making a good abstraction will be easier. > > > I've implemented each of the APIs enough (standalone) to know a lot of > > the differences. Where I'm struggling is envisioning the proper > > abstraction and implementation with python / django code to tie it all > > together. > > > My current idea is to setup a Request class, then create specific > > subclasses of this, overriding the default methods, writing conversion > > methods, and defining additional fields. But "seeing" the python code > > around this has yet to come. > > > As I've never really implemented this type of abstraction (and I > > imagine others have), I'm really interested in what has been done / > > known solutions to the general problem / do I have the right idea / > > any source folks can suggest / etc.. > > > Thanks for taking the time to read about my situation! > > > ~Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Interesting code abstraction Challenge
Anyone else have thoughts on this, with respect to design considerations, implementing in python versus using some of django's tools.. ? On Fri, Oct 23, 2009 at 8:22 AM, Jason Beaudoin wrote: > 2009/10/23 kmike : >> >> Maybe you don't have enough information to make an abstraction right >> now. If so I suggest to actually implement several API's in a dumb >> way. After that it'll be clear what are the differences and what are >> the common parts so making a good abstraction will be easier. > > I've implemented each of the APIs enough (standalone) to know a lot of > the differences. Where I'm struggling is envisioning the proper > abstraction and implementation with python / django code to tie it all > together. > > My current idea is to setup a Request class, then create specific > subclasses of this, overriding the default methods, writing conversion > methods, and defining additional fields. But "seeing" the python code > around this has yet to come. > > As I've never really implemented this type of abstraction (and I > imagine others have), I'm really interested in what has been done / > known solutions to the general problem / do I have the right idea / > any source folks can suggest / etc.. > > Thanks for taking the time to read about my situation! > > ~Jason > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Interesting code abstraction Challenge
2009/10/23 kmike : > > Maybe you don't have enough information to make an abstraction right > now. If so I suggest to actually implement several API's in a dumb > way. After that it'll be clear what are the differences and what are > the common parts so making a good abstraction will be easier. I've implemented each of the APIs enough (standalone) to know a lot of the differences. Where I'm struggling is envisioning the proper abstraction and implementation with python / django code to tie it all together. My current idea is to setup a Request class, then create specific subclasses of this, overriding the default methods, writing conversion methods, and defining additional fields. But "seeing" the python code around this has yet to come. As I've never really implemented this type of abstraction (and I imagine others have), I'm really interested in what has been done / known solutions to the general problem / do I have the right idea / any source folks can suggest / etc.. Thanks for taking the time to read about my situation! ~Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Interesting code abstraction Challenge
Maybe you don't have enough information to make an abstraction right now. If so I suggest to actually implement several API's in a dumb way. After that it'll be clear what are the differences and what are the common parts so making a good abstraction will be easier. On 23 окт, 11:06, Jason Beaudoin wrote: > Why hello there, > > I have been thinking over this system design for quite a while now, > and I'm still a bit unsure of the sensible way to properly (and > sufficiently) abstract the system - the django-way, so to speak. I am > very interested in what other folks have to say - maybe I have been > thinking about this too much, maybe I haven't crossed paths with the > techniques you would use, but I imagine that while a little > challenging, this is still a common situation. > > Please share your crazy, genius ideas, reading tips, code snippets, etc : ) > > Here is the general setup: > > Client Servers <---> The Application in Question <---> Partner Applications > > The main role of the webapp is to serve as a proxy application to many > other partner web applications - we receive requests from client > servers, work out the processing with one or more of our partner > applications, and return the results to the client server. All data > communication is done via predefined APIs, and each API is different.. > we define the API our client servers use to send/receive requests to > us, we follow the APIs as defined by our partners to communicate with > their applications. In this way, our client servers are connected to > many similar applications through our one webapp. > > Several baseline "rules", if you will: > > - The application receives specially formatted requests for > processing (via POSTs). > - As stated, all requests are formatted as defined by our, or our > partner, APIs. > - All incoming requests will need to be re-formatted before passing > on, as each API is different. > - Some communication is handled via passing XML around, others aren't. > - A few situations require additional user interaction > > The Challenge, or Where I'm caught up: > > The end points are easy, as the APIs need to be followed. > Re-formatting a request from our API to a partner's - and vice versa - > isn't really a problem either.. (if I wanted to do this the crappy > way, this could be written out for each conversion, but there are 10 - > 20 conversions). The challenge I am trying to figure out is how to > abstract the re-formatting process to eliminate code duplication, as > our API and each partner API will be similar (in an abstract way). > > What's difficult is that each API is different enough that it isn't a > straight up a --> b field name translation, the conversion mechanism > has to be pretty dynamic. To put specifics on it, differing field > names are one thing, but the APIs differ in the information they > require (field types, so to speak) - for example: additional fields > for some APIs, or a field in one API may be a combination of others in > another API, etc. > > What I have in mind so far: > > - For each partner, define the list of fields required > - Define translations for each field, with 3 parts: our field name > (or data source), the partner's field name, and a translation function > (with the appropriate conversion algorithm if necessary). > - When a partner has a field that doesn't have an equivalent in our > system, define a function for generating the field's value. > - Once we've converted the information, format the data as either XML > or ready for a URLencode to POST > > Questions: > > Am I on the right track here? > Should I be thinking about this differently? > How do I tie these translations into a generic process, with generic > code, leaving the specifics to these translation functions? > How the hell would you set this up? Even if I'm on the right path > here, I'm having difficulty envisioning the python code behind all of > this.. > > All ideas, feedback, input, comments, etc welcome!! > > Regards, > > ~Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Interesting code abstraction Challenge
Why hello there, I have been thinking over this system design for quite a while now, and I'm still a bit unsure of the sensible way to properly (and sufficiently) abstract the system - the django-way, so to speak. I am very interested in what other folks have to say - maybe I have been thinking about this too much, maybe I haven't crossed paths with the techniques you would use, but I imagine that while a little challenging, this is still a common situation. Please share your crazy, genius ideas, reading tips, code snippets, etc : ) Here is the general setup: Client Servers <---> The Application in Question <---> Partner Applications The main role of the webapp is to serve as a proxy application to many other partner web applications - we receive requests from client servers, work out the processing with one or more of our partner applications, and return the results to the client server. All data communication is done via predefined APIs, and each API is different.. we define the API our client servers use to send/receive requests to us, we follow the APIs as defined by our partners to communicate with their applications. In this way, our client servers are connected to many similar applications through our one webapp. Several baseline "rules", if you will: - The application receives specially formatted requests for processing (via POSTs). - As stated, all requests are formatted as defined by our, or our partner, APIs. - All incoming requests will need to be re-formatted before passing on, as each API is different. - Some communication is handled via passing XML around, others aren't. - A few situations require additional user interaction The Challenge, or Where I'm caught up: The end points are easy, as the APIs need to be followed. Re-formatting a request from our API to a partner's - and vice versa - isn't really a problem either.. (if I wanted to do this the crappy way, this could be written out for each conversion, but there are 10 - 20 conversions). The challenge I am trying to figure out is how to abstract the re-formatting process to eliminate code duplication, as our API and each partner API will be similar (in an abstract way). What's difficult is that each API is different enough that it isn't a straight up a --> b field name translation, the conversion mechanism has to be pretty dynamic. To put specifics on it, differing field names are one thing, but the APIs differ in the information they require (field types, so to speak) - for example: additional fields for some APIs, or a field in one API may be a combination of others in another API, etc. What I have in mind so far: - For each partner, define the list of fields required - Define translations for each field, with 3 parts: our field name (or data source), the partner's field name, and a translation function (with the appropriate conversion algorithm if necessary). - When a partner has a field that doesn't have an equivalent in our system, define a function for generating the field's value. - Once we've converted the information, format the data as either XML or ready for a URLencode to POST Questions: Am I on the right track here? Should I be thinking about this differently? How do I tie these translations into a generic process, with generic code, leaving the specifics to these translation functions? How the hell would you set this up? Even if I'm on the right path here, I'm having difficulty envisioning the python code behind all of this.. All ideas, feedback, input, comments, etc welcome!! Regards, ~Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
