Hi Robin,
On Tue, 2009-03-10 at 10:33 +0000, Robin Becker wrote:
> We're trying to write some re-usable apps, but face some problems when it
> comes
> to configuring various bits of the application to run together.
>
> First off it seems reasonable to allow apps to locate their resources using
> settings.py. However, in one instance we're not able to do this.
I'm not quite sure how this relates to your question about placing stuff
in the templates. This bit doesn't seem to have a connection to what
follows. I suspect you've abstracted away the details to such an extent
that the problem has been lost in the mist. Can you bring back a couple
of the specifics? An example perhaps?
>
> Specifically when widgets are created the Media subclass doesn't allow for
> any
> kind of initialization of the included javascript. So my colleague then has
> to
> force the app to load resources from a fixed location say /media/myapp/.....
>
> In other places we're able to configure the javascript using a script tag eg
>
> <script ...>var myapp_url_prefix='/notmedia/myapp';</script>
>
> Would it not be a good idea to allow widgets to enter things other than js
> and
> css in the head section. If 'script' were allowed as an attribute then
> widgets
> could also be configured relatively simply.
You can already load arbitrary Javascript files. They are executed as
they are loaded. Why can't you include whatever Javascript you want
executed in there?
You can also use your own subclass, or even a complete replacement, of
the forms.widgets.Media class on any Widget class. It looks like setting
the "media" attribute on the Widget class does the trick. All of this is
from reading the code in django/forms/widgets.py, in particular the
Media and MediaDefiningClass -- it's not particularly complicated.
> There are also other bits of
> configuration which widgets could request eg onload/onunload etc etc.
Well, that's kind of a deliberate design. Rather than directly write
onload handlers on the HTML elements, but to do progressive enhancement
if Javascript is supported. It also prevents us needing to have an
attribute for every possible HTML attribute (both legal and illegal but
common) on the widgets.
Still, almost all widgets take an "attrs" attribute that is a dictionary
of things included on the widget. So you could pass in something like
attrs = {'onload': ...}
and end up with onload="..." in the widget itself. The exception to this
rule are the inner elements for things like select elements (the option
elements).
> For most apps there's no real problem in having a fixed resource location,
> but I
> can see cases when proper configuration is desirable.
It all looks to be already possible from reading the code (I'm not
meaning that as a knock on you asking the question, rather as a guide as
to where to look).
Based on what I've mentioned above about "media" and "attrs" is there
anything you can't do that you'd like to in these exceptional cases?
With some more details, I suspect they are solvable in the existing
code.
I suspect I'm missing something about your question, because it looks
like you start off talking about settings.py and then take a 180° turn.
Assuming you know what you're talking, I fear I'm missing the point, so
feel free to clue-bat away.
Cheers,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
