2010-11-10 7 views
17

Tengo un objeto que quiero usar en admin en lugar de un modelo que hereda models.Model. Si lo hago heredar models.Model, este objeto creará una tabla en la base de datos que no quiero. Solo quiero que este objeto permanezca en la memoria.es posible crear una vista de administrador personalizada sin un modelo detrás de ella

Una solución He venido con la ayuda de la buena gente en el desbordamiento de pila es crear vistas de administrador, registrar estas vistas personalizadas a través de un modeloAdmin (admin.site.register()) en admin.py y utilizar este modelo como objeto como almacenamiento de datos dinámicos (en memoria).

Dado que este modelo como objeto no hereda de models.Model, admin.site.register() (en admin.py) no lo acepta y muestra un error de 'tipo' no es iterable "cuando intento acceda a él en el navegador

+0

Puede conectar vistas adicionales, hasta un modelo en particular (y hacer lo que quiera de ellos, relacionado con el modelo o no; me pueden enviar una respuesta con esta solución si se quiere), pero No conozco ninguna forma de crear una vista de administrador completamente independiente, aparte de hackear la fuente de administración. – eternicode

+0

@eternicode en realidad es perfectamente posible crear vistas de administrador independientes: ver mi respuesta. –

+0

@Daniel Roseman, ah, entonces! Nunca antes había visto esa funcionalidad, aunque TBH nunca la he necesitado todavía. – eternicode

Respuesta

10

hmmm. Gracias por su ayuda a todos. La solución que he llegado (con su ayuda por supuesto :) es el siguiente:

Tengo dos plantillas personalizadas:

my_model_list.html 
    my_model_detail.html 

Bajo views.py:

class MyModel(object): 
    # ... Access other models 
    # ... process/normalise data 
    # ... store data 

@staff_member_required 
def my_model_list_view(request) #show list of all objects 
    #. . . create objects of MyModel . . . 
    #. . . call their processing methods . . . 
    #. . . store in context variable . . . 
    r = render_to_response('admin/myapp/my_model_list.html', context, RequestContext(request)) 
    return HttpResponse(r) 

@staff_member_required 
def my_model_detail_view(request, row_id) # Shows one row (all values in the object) in detail  
    #. . . create object of MyModel . . . 
    #. . . call it's methods . . . 
    #. . . store in context variable . . . 
    r = render_to_response('admin/myapp/my_model_detail.html', context, RequestContext(request)) 
    return HttpResponse(r) 

Bajo el principal Django urls.PY:

urlpatterns = patterns( 
    '', 
    (r'^admin/myapp/mymodel/$', my_model_list_view), 
    (r'^admin/myapp/mymodel/(\d+)/$', my_model_detail_view), 
    (r'^admin/', include(admin.site.urls)) 
) 
+1

Me alegro de que haya descubierto esto por su cuenta. Estaba a punto de comentar lo mismo. Una vista de administrador sin un modelo es básicamente una vista normal de Django que utiliza una plantilla de administrador con una instancia simulada de ModelAdmin, que es básicamente lo que estás haciendo. Lo hice yo mismo para crear algunas páginas personalizadas con temas de administrador. – Cerin

2

Como dice el libro de Django, el administrador es para "Usuarios de confianza que editen contenido estructurado", en este caso el contenido estructurado es un modelo ordenado en jerarquías y configurado a través de settings.py. Más importante aún, si su objeto no es completamente de tipo pato a modelos.Modelo completo con las relaciones esperadas, el administrador probablemente lanzará excepciones por todos lados.

Sin embargo, como el mantra dice: "Es solo python". Puedes anular cualquiera de las páginas en admin. Simplemente cree sus propias plantillas en su proyecto, y pídalas primero en la búsqueda de plantillas. Además, al heredar admin/base.html, mantiene la apariencia & del proyecto de administración.

Escriba su vista administrativa y plantillas para este objeto, como cualquier otra, pero asegúrese de ajustar las vistas en el decorador is_staff para asegurarse de que las vistas estén protegidas del acceso por usuarios no autorizados. Ponlos en la aplicación, tal vez en admin/views.py, con templates/admin/object_list.html y object_form.html.

Una vez que tenga las herramientas administrativas adecuadas para estos objetos que no son de base de datos, puede proporcionar acceso a ellos a través de la página de índice de administración: desea sobrescribir admin/index.html y proporcionar elementos adicionales específicos del proyecto a la página según sea necesario.

He hecho exactamente esto para proporcionar acceso administrativo a API de terceros que almacenan nuestros datos, como el servicio de correo electrónico ConstantContact, y funciona bastante bien.

+0

Gracias por su ayuda Elf. He publicado mi respuesta de solución a continuación, aunque no estoy seguro si he seguido exactamente su consejo. – sysasa

5

Puede agregar sus vistas directamente al objeto AdminSite, en lugar de a cualquier subclase particular ModelAdmin que luego registre.

Se accede a AdminSite por defecto a través de django.contrib.admin.site, que es lo que usted llama registrar y autodetectar. En lugar de usar esto, puede crear su propia subclase y add your own views to it, y luego registrar sus modelos en lugar de la predeterminada.

+0

Interesante; ¿Asumo que estas subclases son recogidas por una llamada 'autodiscover'? ¿O su subclase debe usarse en todas las aplicaciones del sitio para que sea efectiva? (En realidad, siento que no entiendo el concepto correctamente ...) – eternicode

+0

¡Gracias por su ayuda, Daniel! Solución publicada a continuación, aunque no del todo seguro de que esto es lo que quería decir. De todos modos, ¡funciona! :) – sysasa

Cuestiones relacionadas