views:

250

answers:

4

Hi, I'm building a rather large project, that basically consists of this:

Server 1: Ice based services. Glacier2 for session handling. Firewall allowing access to Glacier2.

Server 2: Web interface (read, public) for Ice services via Glacier2. Admin interface for Ice services via Glacier 2.

The point I'm concerned with is the web interface. I want to use Django, because it's both written in python and has that incredibly useful automatic admin panel generator.

The web interface doesn't access any database. It connects to an Ice service on Server #1 via the Glacier2 router and uses the API exposed by those services to manipulate data.

And as you probably know, the admin generation in Django depends on the use of Django's ORM; which I'm not using since I have no database to access.

So I need to generate the admin panel, but, instead of having an standard data access like the ORM normally does, I need to intercept any "db-access" calls and transform them into Ice service calls, and then take the service's output (if any), transform it into whatever the ORM normally returns and return control to Django.

Anyone knows how I could do this? what would I need to subclass? Any specific ideas?

Thanks for your time.

A: 

The django ORM has a pluggable backent, which means that you can write a backend for things that aren't RDBMSes. It's probably a rather large task, but a good place to get started is with Malcolm Tredinnick's talk from DjangoCon 2008, Inside the ORM.

Otherwise, you could bypass the ORM altogether, and write the forms manually for the access you need.

jcdyer
+3  A: 

The real power of the contrib.admin is django Forms. In essence, the admin tool is basically auto-generating a Form to match a Model with a little bit of urls.py routing thrown in. In the end it would probably just be easier to use django Forms apart from the admin tool.

T. Stone
+1. He should grab the example code from the URL you provided, get that working, then adapt it to his purposes.
steveha
I'll check the documentation you linked.
A: 

you can "mock" some class so it look like a model but it does proxy to your APIs

f.e.

class QuerysetMock(object):
    def all():
        return call_to_your_api()
    [...]


class MetaMock(object):
     def fields():
         return fields_mock_objects..
     verbose_name = ''
     [...]

class ModelMock(object):
    _meta = MetaMock()
    objects = QuerysetMock()

admin.site.register(ModelMock)

This may work.. but you need to do a lot django.model compatible stuff

Pydev UA
+4  A: 

I think there might be a simpler way than writing custom ORMS to get the admin integration you want. I used it in an app that allows managing Webfaction email accounts via their Control Panel API.

Take a look at models.py, admin.py and urls.py here: django-webfaction

To create an entry on the admin index page use a dummy model that has managed=False

Register that model with the admin.

You can then intercept the admin urls and direct them to your own views.

This makes sense if the add/edit/delete actions the admin provides make sense for your app. Otherwise you are better off overriding the admin index or changelist templates to include your own custom actions

andybak
I downloaded your app, and I like the general implementation.As for what the services actually do, the core ones I've already designed, it comes down to: Accounts (authentication, users, groups, permissions), Settings (for every service, and even the web interface), Log (logs actions by every user, not the same as the admin panel 'Recent Actions'), Jobs (queue for other services) and the actual services that do something interesting, which are yet to be designed.So, 9/10, the add/edit/delete action set holds. For that 1/10, I can always generate my own customized pages like your app does.