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 <tblanch...@mac.com> 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 <tonightslasts...@gmail.com> 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 <tblanch...@mac.com> 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 <tblanch...@mac.com> 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 <tblanch...@mac.com> 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 django-us...@googlegroups.com.
>>>>>>>> To unsubscribe from this group, send email to
>>>>>>>> django-users+unsubscr...@googlegroups.com.
>>>>>>>> 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 django-us...@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to
>>>>>> django-users+unsubscr...@googlegroups.com.
>>>>>> 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 django-us...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-users+unsubscr...@googlegroups.com.
>>> 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 django-us...@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.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
