On Oct 5, 9:58 pm, davisd <davisd.dav...@gmail.com> wrote: > 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?
Seems to me that template tags are a better fit here. -- DR. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
