views:

58

answers:

1

I'm open to persuasion that this is a bad idea. But if not, here's the general draw:

  1. Web interface to maintain data (django.contrib.admin).
  2. Web interface to create pages (django.contrib.flatpages)
  3. Web interface to create templates (dbtemplates)
  4. Where is the web interface to create queries and define context? (contexts?)

EDIT


Here's the normal situation for Django site development. You have a new page to make, figure out the url for it, figure out what data is needed to support the page, then create the appropriate templates so the data is presented the way you intend.

What I'd like is to be able to do is define what data is needed to support the page from the admin interface; essentially what you put into a views.py file.

I imagine there being a wrapper view that handles auth, but receives all of its context from a model (table).

from dbcontext import DBContext  # this is fictitious  

def db_context_view(request, **args, **kwargs):
  # ...some code to handle auth
  context = DBContext.objects.get_context_for_request(request, **args, **kwargs)
  return render_to_response('mydbtemplates/example.html', context)

I would be happy to still edit the urls.py file to ensure enough gets passed to the view so that the DBContext manager can locate the appropriate context record, perform the desired queries (satisfying any query parameters), and return the appropriate dictionary for the template to succeed.

A: 

I believe you're looking for the contenttypes framework. With the contenttypes framework, you would be able to do something like this:

def db_context_view(request, *args, **kwargs):
    # ...some code to handle auth
    ct = ContentType.objects.get_for_id(kwargs['content_type_id'])
    obj = ct.get_object_for_this_type(pk=kwargs['object_id'])

Using this approach, you could build the view you desire.

slypete