Daniel, Thanks for your reply. I believe template tags are part of the answer, namely in the example I gave below about the "Ads". They can grab some context right from the template, call functions from the app, etc. But they can't "pass data" to themselves... And the tag has to be hard-coded within the template.
But suppose I need to process data from two applications with my "common (third application)" view. This could be for passing into the template, for for some other processing. Let's say this for the "newsletter" application and also something equally as robust. Would it be safe to call upon each individual application's context processors to process forms, etc? Is there a better way of mixing applications? -David On Oct 5, 4:41 pm, Daniel Roseman <dan...@roseman.org.uk> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
