I have a question concerning django architecture with multiple applications and combined views.
A View accepts an HttpRequest and returns an HttpResponse. The flow for a view is: HttpRequest in from the visitor -> process -> HttpResponse out to visitor. Assuming my end result is a page on the visitor's browser, the HttpResponse is tightly-coupled to a template. Since a rendered template is going back out with the response, the template is expecting a specific set of dictionary items from the context (which happens in the view's processing). Suppose I have an application "news" and a second application named "ads". Because I'm using good loose coupling principles: * I have a view defined in my news application that will fill the context with news_items and render a template. * I have a view defined in my ads application that will fill the context with page_ads and render a template. What I need is a page that displays "news" and "ads". What I now need to do is create a new application "common" and duplicate the efforts of each application's view functions into a new single view (under common) which will populate a context with both "news_items" and "page_ads"; and render the template. I have a template for my "common" application that expects context variables news_items as well as page_ads. It seems to me that this is against DRY principles. For such a lightweight view, it may not be a "big deal" (See example 2 below). But let's suppose it is a big deal and I don't want to duplicate my efforts. I think the answer up to this stage involves using context processors. I create news/context_processors.py and ads/ context_processors.py. I put context processor functions in each which will return their relative data.. news for news, ads for ads. Now in my "common" application, I can create a view which will get context data from the separate applications by calling the context processors. Now I can render to my common application's news_ads.html template with populated context data. Why I'm second guessing this method is in the following scenario: I have 2 applications, "ads" and "newsletter". I need a newsletter page that also shows "ads". The newsletter application has a Subscription model and a subscribe/ unsubscribe form. I have a large view within the newsletter application (almost 50 lines) that processes the form. It will add or update records, depending on pre-existing data. Should I make a context processor within my newsletter application to handle this processing and call upon it from my common/views.py (newsletter_ads method)? This newsletter context processor (process_form) will check if the request is a POST, see if the form is correct, add the appropriate form to the context, etc. Or should I start making some utility methods eg: newsletter.utilities.unsubscribe(posted_form)? What I do not want to do is write my common/views/newsletter_ads method in my "common" application and copy/paste code from the newsletter/views and ads/views to create my common/views. I'm not seeing good and repeated examples of DRY principles for these multiple-application view processing scenarios in the larger projects I've looked at. Is there a mechanism built into django for this architecture or any good conventions? Are context processors the answer and should I feel ok with using them to process forms? Are generic python utility methods a better use? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
