The 'media' attribute on forms are actually python proterties Sent from my iPod; pardon any typos and poor grammar!
On Nov 24, 2009, at 5:02 PM, Todd Blanchard <[email protected]> wrote: > Thanks, I feel like I'm making progress. > > Widgets define media too. I'm really fuzzy about how widgets get > loaded and how their media declarations get collected into the media > object list. (I'm using contrib.gis which has nifty map widgets and > it "just works" in the admin but now I'm building my own UI). > > In fact, I'm pretty fuzzy in general about how code like widgets > gets "found" and loaded. > > -Todd Blanchard > > > On Nov 24, 2009, at 3:52 PM, Tim Valenta wrote: > >> Sorry-- I got out of sync with the replies. >> >>> Or am I missing something. Seems like I am getting very much NON- >>> DRY here. >> >> How many pages do you have dozens of forms on? If ever, I find that >> I've got a single form on the page. If you're writing an app complex >> enough to need such amazingly complicated nested forms.... should you >> use the admin, and let it do all that for you? >> >> We're not really working with specifics here, so I'm unsure of what >> you're trying to accomplish. >> >> How would you propose we get around this problem? You've got a >> python >> list of form objects. How on earth is Django supposed to know what >> variable you've got your forms in? By forcing you to put all your >> forms in a single variable, it would make Django dictate too strongly >> "the one and only variable which can hold forms". That exactly what >> it's trying not to do. >> >> Just set up a template, perhaps "base.html". Make it something like >> this: >> >> <html> >> <head> >> <title>blah</title> >> {% block my_media %} >> {{ media }} >> {% endblock %} >> </head> >> <body> >> {% content %}{% endcontent %} >> </body> >> </html> >> >> >> Then, in your views, you'll render the actual template you want to >> use >> (as in, don't render "base.html", render the one that you'd normally >> render), but make sure it extends base: >> {# mytemplate.html #} >> {% extends "base.html" %} >> >> {% block content %} >> my content goes here... >> <form> >> {% for form in forms %} >> {{ form.as_p }} >> {% endfor %} >> </form> >> {% endblock %} >> >> >> The idea is that the 'base.html' template will *always* try to grab >> the context variable "media" and render it. That means that all you >> ever have to do is make sure that the context variable "media" >> contains the cumulative media of what you want to include. Note, >> though, that when you want to use this "extends" approach, you become >> required to work in those blocks. that's why I put a "content" block >> in the base template, and override it in the extended one. Stuff >> outside of blocks in mytemplate.html won't get displayed. This is a >> very common approach, though, so don't feel like you're getting >> cheated. >> >> Then, if you ever want to for whatever reason add more media beyond >> the form media, you can either slap it into the 'media' context var >> in >> your view, or you can do that block override I kept using the first >> examples: >> >> {# mytemplate.html #} >> {% block my_media %} >> {{ block.super }} >> <script type="text/javascript" src="blahblah/my.js" /> >> {% endblock %} >> >> {% block content %} >> {# continue as usual #} >> {% endblock %} >> >> >> >> I hope I'm not spouting nonsense that you are already familiar with. >> Feel free to ask anything more, if you've got specifics that you're >> trying to nail down, design-wise. >> >> Tim >> >> On Nov 24, 4:36 pm, Todd Blanchard <[email protected]> wrote: >>> No no no, I really really appreciate the help. >>> >>> But I'm definitely beginning to feel like my app is 80% boilerplate. >>> >>> On Nov 24, 2009, at 3:35 PM, Tim Valenta wrote: >>> >>> >>> >>>> PS -- I hope I don't sound like I'm insulting your >>>> intelligence--- I'm >>>> not. I've often felt like there aren't enough policies in Django, >>>> myself. But pick your battles. This is an easy one. I prefer >>>> Django >>>> over Rails, when it comes down to it. Feel fortunate that Django >>>> has >>>> practically the best documentation on the planet. I hate more open >>>> source docs, because it was written by a guy who don't know how >>>> to use >>>> proper english! >>> >>>> I'm just trying to drive home the point that this isn't the worst >>>> thing that you could be stuck on. >>> >>>> Sincerely hoping it helps, >>>> Tim >>> >>>> On Nov 24, 4:28 pm, Tim Valenta <[email protected]> wrote: >>>>> Sorry it's not working out for you, but I'd disagree about the >>>>> comparison to X-Windows :) I'd be defending Django, and not X- >>>>> windows, when I say that. >>> >>>>> I'm serious. Just add them together. I'm not sure you're >>>>> appreciating the slick objects that have been crafted for this >>>>> very >>>>> purpose. >>> >>>>> Your view: >>>>> cumulative_media = form.media for form in forms >>>>> return render_to_response('mytemplate.html', {'media': >>>>> cumulative_media}) >>> >>>>> Your template: >>>>> {% block my_media_block %} >>>>> {{ block.super }} >>>>> {{ media }} >>>>> {% endblock %} >>> >>>>> I fail to see what is so hard about this. >>> >>>>> Tim >>> >>>>> On Nov 24, 4:13 pm, Todd Blanchard <[email protected]> wrote: >>> >>>>>> You know what, this is absolutely too much BS. Why would one >>>>>> bother to use the media declaration stuff at all if there is no >>>>>> mechanism to properly consume it (a built in template tag for >>>>>> instance). >>> >>>>>> I think I will just hardcode them in the head in the base >>>>>> template. They seldom change and browser caching being what it >>>>>> is having them never change is just fine. >>> >>>>>> After three weeks of seriously trying to get traction with >>>>>> django, my conclusion is it has all of the elegance of X- >>>>>> windows. It can do anything but out of the box it does nothing >>>>>> except present a zillion confusing parts to the programmer and >>>>>> it has too many mechanisms but no policies. >>> >>>>>> I'm beginning to very much pine for rails. At least it does >>>>>> something out of the box. >>> >>>>>> Very frustrated today - still haven't got a single record/entry >>>>>> form working. Too many little files and indirection to keep it >>>>>> all straight in my head. >>> >>>>>> -Todd Blanchard >>> >>>>>> On Nov 24, 2009, at 2:05 PM, Tim Valenta wrote: >>> >>>>>>> The idea is along the lines of what you initially guessed. >>> >>>>>>> The admin accomplishes the non-duplicate effect in django/ >>>>>>> django/ >>>>>>> contrib/admin/options.py, starting at line 770. It loops over >>>>>>> the >>>>>>> forms and combines the existing media with the media on each >>>>>>> form >>>>>>> object. It ends up using a series of objects to do it, >>>>>>> including a >>>>>>> Media class, but it's not doing anything too special. When an >>>>>>> item >>>>>>> gets added, it checks to make sure that the path doesn't >>>>>>> already exist >>>>>>> in the list. >>> >>>>>>> So, short story: loop over your forms and add the media >>>>>>> attributes >>>>>>> together. The underlying Media class ought to be dropping >>>>>>> duplicates. >>> >>>>>>> Then just save a context variable with the result, and do the >>>>>>> following in your template: >>> >>>>>>> {% block extrahead %} {# or whatever you call your header >>>>>>> block #} >>>>>>> {{ block.super }} >>>>>>> {{ cumulative_media }} >>>>>>> {% endblock %} >>> >>>>>>> Tim >>> >>>>>>> On Nov 24, 12:30 pm, Todd Blanchard <[email protected]> wrote: >>>>>>>> What about de-duping? >>>>>>>> If two forms want the same js file, will it get included twice? >>>>>>>> It seems like this is the kind of thing that the framework >>>>>>>> should handle and the current "solution" is kind of half baked. >>> >>>>>>>> -Todd >>> >>>>>>>> On Nov 23, 2009, at 2:40 PM, Mark (Nosrednakram) wrote: >>> >>>>>>>>> Hello, >>> >>>>>>>>> I have something like the following in my generic >>>>>>>>> genericform.html. I >>>>>>>>> think this is what you're looking for if not hope you find a >>>>>>>>> better >>>>>>>>> answer. The extramedia block is back in my base.html >>>>>>>>> template and my >>>>>>>>> form template extends it. I'm not sure if it's in the admin >>>>>>>>> base.html >>>>>>>>> but you can take a look at if for there media blocks I >>>>>>>>> believe are >>>>>>>>> something like extrastyle etc... >>> >>>>>>>>> {% block extramedia %} >>>>>>>>> {% if forms %} >>>>>>>>> {% for form in forms %} >>>>>>>>> {{ form.media }} >>>>>>>>> {% endfor %} >>>>>>>>> {% else %} >>>>>>>>> {{ form.media }} >>>>>>>>> {% endif %} >>> >>>>>>>>> Mark >>> >>>>>>>>> On Nov 23, 1:31 pm, Todd Blanchard <[email protected]> wrote: >>>>>>>>>> I've read this: >>> >>>>>>>>>> http://docs.djangoproject.com/en/dev/topics/forms/media/ >>> >>>>>>>>>> Nifty. >>> >>>>>>>>>> Now, how exactly do I make sure that the media urls get >>>>>>>>>> spewed properly into the head section of the page? This is >>>>>>>>>> apparently omitted everywhere I've looked. The admin >>>>>>>>>> template seems to pull it off properly but I cannot figure >>>>>>>>>> out how. Seems like I should be able to do something like >>> >>>>>>>>>> <html> >>>>>>>>>> <head> >>>>>>>>>> {{ media }} >>>>>>>>>> </head> >>> >>>>>>>>>> but I cannot figure out exactly how to properly aggregate >>>>>>>>>> all the forms' media's and get them spewed into the >>>>>>>>>> templates properly. >>> >>>>>>>>>> -Todd >>> >>>>>>>>> -- >>> >>>>>>>>> You received this message because you are subscribed to the >>>>>>>>> Google Groups "Django users" group. >>>>>>>>> To post to this group, send email to [email protected] >>>>>>>>> . >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> [email protected] >>>>>>>>> . >>>>>>>>> For more options, visit this group athttp:// >>>>>>>>> groups.google.com/group/django-users?hl=. >>> >>>>>>> -- >>> >>>>>>> You received this message because you are subscribed to the >>>>>>> Google Groups "Django users" group. >>>>>>> To post to this group, send email to [email protected] >>>>>>> . >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected] >>>>>>> . >>>>>>> For more options, visit this group athttp://groups.google.com/ >>>>>>> group/django-users?hl=en. >>> >>>> -- >>> >>>> You received this message because you are subscribed to the >>>> Google Groups "Django users" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> . >>>> For more options, visit this group athttp://groups.google.com/ >>>> group/django-users?hl=en. >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups "Django users" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected] >> . >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en >> . >> >> > > -- > > You received this message because you are subscribed to the Google > Groups "Django users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
