2017-09-29 16 views
1

Veuillez noter: Juste pour clarifier '[app_name]' est un espace réservé pour le nom réel de l'application. Pas de code de substitution Django. Imaginez juste qu'il dit «Stuff» au lieu de [app_name], si c'est confus.Django DRY - comment simplifier des vues similaires en utilisant le même template?

Ma question:

  1. Comment puis-je le rendre plus sec?

Il y a beaucoup de répétitions de code, et il doit y avoir un moyen d'unifier certaines d'entre elles. Si vous répondez, je serais vraiment reconnaissant si vous écrivez explicitement quoi et pourquoi. Comme beaucoup de réponses supposent pas mal de connaissances et j'essaie de bonnes habitudes dans le style et la pratique du codage Django. Merci pour votre temps.

[app_name] /urls.py

from django.conf.urls import url 

from . import views 

app_name = 'things' 
urlpatterns = [ 
    url(r'^cars/$', views.CarThingIndexView.as_view(), name='Car_index'), 
    url(r'^trees/$', views.TreeThingIndexView.as_view(), name='Tree_index'), 
    .... 
] 

[app_name] /model.py

from django.db import models  
class Tree(models.Model): 
     """ 
     Tree 
     """ 
     name_text = models.CharField(max_length=200) 

def __str__(self): 
    return self.name_text 

class Car(models.Model): 
     """ 
     Car 
     """ 
     name_text = models.CharField(max_length=200) 

def __str__(self): 
    return self.name_text 

[app_name] /view.py

from django.views import generic 

from inventory.models import Car, Tree 


class CarThingIndexView(generic.ListView): 
    template_name = '[app_name]/index.html' 
    context_object_name = 'thing_list' 

    def get_queryset(self): 
     return Car.objects.values() 


class TreeThingIndexView(generic.ListView): 
    template_name = '[app_name]/index.html' 
    context_object_name = 'thing_list' 

    def get_queryset(self): 
     return Tree.objects.values() 

[APP_NAME]/modèle/[APP_NAME] index.html

{% extends '[app_name]/base.html' %} 
{% block content %} 
    {% if thing_list %} 

     <ul> 
      {% for item in thing_list %} 
       <li> 
        <p> 
         {{ item }} 
        </p> 
       </li> 
      {% endfor %} 
     </ul> 
    {% else %} 
     <!-- I am pretty sure if there are no objects this will not work, please correct me if I am wrong {{ obj | get_class_name }}. I would like it to read "No Tree/Car are available." --> 
     <p>No [class_name] are available.</p> 
    {% endif %} 
{% endblock content %} 

Répondre

2

De mon point de vue tout va bien et il n'y a pas besoin de plus abstrait dans ce cas. À ce stade, il semble que vous pouvez l'optimiser - mais ce que vous avez échafaudé n'inclut aucune logique. Dans les coulisses django vous aide déjà beaucoup pour ne pas vous répéter ici!

Lorsque vous commencez à implémenter des fonctionnalités pour vos voitures et vos arbres, les views, models et templates iront dans des directions différentes. À côté du nom, ils auront des propriétés différentes. Ils agissent différemment et ont été affichés différemment. C'est ce qui se passe généralement dans votre application.

Si vous avez un ensemble de modèles qui partagent beaucoup de propriétés et de représentation django fournit des mécanismes comme abstract base classes pour les propriétés des modèles et méthodes ou les include et extends balises de modèle, si vous avez besoin de partager des représentations. En ce qui concerne la logique de vue qui devrait être partagée, vous pouvez écrire vos propres modules ou même des paquets pour faire ce que vous devez faire et les utiliser dans vos vues.

En l'absence de cas réels, vous ne devriez pas penser à comment ne pas vous répéter à ce stade.