how to connect Django to objects served over xml-rpc?

[b***@gmail.com]

I want to try out Django for a small project, hoping to discover that
it will be the web framework of my dreams, but I need some advice.

My project group has written an xml-rpc API in front of our database
and password stores. This means that when we want to, say, create a
campus guest account, we call xml-rpc functions like create_guest(),
set_guest_info(), and set_account_password(), and those functions do
all of the database operations (and sometimes operations on other
systems) needed to perform each operation consistently (creating a
guest requires at least six tables to be updated, for example).

This is great in two ways. First, our business logic is all in one
place, where complex operations get written once, correctly. Second,
we wrote it in simple, plain Python that we could all agree upon, so
that now each front-end and client can be written in the favorite
language and framework of the group deploying it (so long as it talks
xml-rpc), avoiding the need for a religious war and everyone being
forced to use One True Platform.

The problem is that Django seems to really, really want to talk to the
database by itself. :-)

At what level, then, would I subvert Django if, say, a Guest were not
a row in a database table, but an entity that I get information about
from an xml-rpc call, and for which some other xml-rpc calls let me
set information? Thanks for any guidance!

I'll be happy to write up my solution for the Django documentation
page, which already discusses connecting to a legacy database - but
not a ... what would one call it? A "legacy non-database."
--
Brandon Craig Rhodes http://www.rhodesmill.org/brandon
Georgia Tech ***@oit.gatech.edu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Oliver Charles]

Hey, seeing as you haven't had any relies yet, I will through my idea down.

What I think you're gonna have to do for the most graceful version is to
create your own database wrapper, that calls xml-rpc, instead of an
actual database. Then Django *should* be free to use. The problem may
occur that Django really does expect to see database like data, so you
may have to reformat your data.

My only other idea is to extend the model base class, and replacement
the save function, etc. This will get messy though, because QuerySet's
also use the db api, so it would require rewriting them too.

I think that option 1 is your best bet, and looking at the SQLite
wrapper should make stuff easier.

Hope this helps
--
Ollie

Post by b***@gmail.com
I want to try out Django for a small project, hoping to discover that
it will be the web framework of my dreams, but I need some advice.
My project group has written an xml-rpc API in front of our database
and password stores. This means that when we want to, say, create a
campus guest account, we call xml-rpc functions like create_guest(),
set_guest_info(), and set_account_password(), and those functions do
all of the database operations (and sometimes operations on other
systems) needed to perform each operation consistently (creating a
guest requires at least six tables to be updated, for example).
This is great in two ways. First, our business logic is all in one
place, where complex operations get written once, correctly. Second,
we wrote it in simple, plain Python that we could all agree upon, so
that now each front-end and client can be written in the favorite
language and framework of the group deploying it (so long as it talks
xml-rpc), avoiding the need for a religious war and everyone being
forced to use One True Platform.
The problem is that Django seems to really, really want to talk to the
database by itself. :-)
At what level, then, would I subvert Django if, say, a Guest were not
a row in a database table, but an entity that I get information about
from an xml-rpc call, and for which some other xml-rpc calls let me
set information? Thanks for any guidance!
I'll be happy to write up my solution for the Django documentation
page, which already discusses connecting to a legacy database - but
not a ... what would one call it? A "legacy non-database."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Forest Bond]

Hi Brandon,

Post by b***@gmail.com
I want to try out Django for a small project, hoping to discover that
it will be the web framework of my dreams, but I need some advice.
My project group has written an xml-rpc API in front of our database
and password stores. This means that when we want to, say, create a
campus guest account, we call xml-rpc functions like create_guest(),
set_guest_info(), and set_account_password(), and those functions do
all of the database operations (and sometimes operations on other
systems) needed to perform each operation consistently (creating a
guest requires at least six tables to be updated, for example).

I think you'll find that Django meets your needs quite well, however, I wouldn't
recommend at all that you try to make Django's database layer wrap your XML-RPC
services. Django's database layer is an ORM, so, unless your XML-RPC services
constitute a thin wrapper around your database, or provide a very database-like
interface, it probably doesn't meet your requirements at a basic, conceptual
model.

One thing you could do is provide a set of read-only thin wrappers to your
database that can live alongside your current XML-RPC implementation. Then, you
could use Django's ORM as an interface to that, and be able to take advantage of
things like generic views and the automatic admin interface. Since the
interface would be read-only, you'd have to make direct XML-RPC calls to
actually make changes to the database, but it sounds like your XML-RPC functions
probably provide some enforcement of data integrity, so that's probably not
very avoidable.

Of course, ultimately, you are getting into a new framework with significant
work to do before you can even get your first app put togther (since you'll need
to implement a custom database layer). That may not be the best way to
introduce yourself to Django :)

If your clever, you may be able to implement a read-only DB layer with only a
little code, but get some advice from some Django experts first (I am not
included in that group).

-Forest

[Joe]

It sounds like you shouldn't be using Django, honestly. You would be
fighting against/hacking around most of the functionality of django
because django is an MVC framework and you guys basically are trying
to re-write the model architecture. If you really really really want
to use django, you should probably just stick to using the controller/
view portion, which would suck because you couldn't use the admin
application.

Post by b***@gmail.com
I want to try out Django for a small project, hoping to discover that
it will be the web framework of my dreams, but I need some advice.
My project group has written an xml-rpc API in front of our database
and password stores. This means that when we want to, say, create a
campus guest account, we call xml-rpc functions like create_guest(),
set_guest_info(), and set_account_password(), and those functions do
all of the database operations (and sometimes operations on other
systems) needed to perform each operation consistently (creating a
guest requires at least six tables to be updated, for example).
This is great in two ways. First, our business logic is all in one
place, where complex operations get written once, correctly. Second,
we wrote it in simple, plain Python that we could all agree upon, so
that now each front-end and client can be written in the favorite
language and framework of the group deploying it (so long as it talks
xml-rpc), avoiding the need for a religious war and everyone being
forced to use One True Platform.
The problem is that Django seems to really, really want to talk to the
database by itself. :-)
At what level, then, would I subvert Django if, say, a Guest were not
a row in a database table, but an entity that I get information about
from an xml-rpc call, and for which some other xml-rpc calls let me
set information? Thanks for any guidance!
I'll be happy to write up my solution for the Django documentation
page, which already discusses connecting to a legacy database - but
not a ... what would one call it? A "legacy non-database."
--
Brandon Craig Rhodes http://www.rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Forest Bond]

Post by Joe
It sounds like you shouldn't be using Django, honestly. You would be
fighting against/hacking around most of the functionality of django
because django is an MVC framework and you guys basically are trying
to re-write the model architecture. If you really really really want
to use django, you should probably just stick to using the controller/
view portion, which would suck because you couldn't use the admin
application.

I don't think this is true. Django's various layers of functionality are
de-coupled relatively well. I would still use Django even if my data access
back-end is pure XML-RPC. I just probably wouldn't use Django's ORM.

Of course, using the ORM does allow you to abstract your web code even further,
but you can probably write wrapper classes around your XML-RPC calls to get som
eof that. (For instance, you might implement a class that, to a limited extent,
emulates the QuerySet class; I think you need this to use generic views, but
correct me if I'm wrong).

-Forest