managing javascript and css resources
I've been thinking about this ever since I learned that django's admin
was going to be using jQuery, but I admit I didn't really consider it
that important until recently (building sites against 1.2-beta).
I know now is not a fantastic time to be talking about features, but
this is something I'd enjoy working on (personally), and I am just
hoping to get a little feedback regarding the design, and how it might
fit in with everything else going on in django's guts
(philosophically). I also understand that this isn't something for near
versions of django, but rather the distant future.
Here's where the pin dropped:
* The jQuery used by the admin site is conjured using the no conflict
option and is relegated/isolated to it's own namespace (excellent).
* There are many projects/apps out there that also rely on jQuery - they
also "bundle" the framework, but may not be quite so quick to play nice.
In my case, I noticed that when I added a few jQuery-enhanced form
widgets to a form in my admin site, it resulted in 3 instances of the
framework being sourced in the document head. Although, this is
actually ok for the most part in terms of operation (so long as the
scripted events that come with each widget are bound to the dom before
the plugin of origin gets wiped by the next sourcing of jQuery), it's
far from ideal.
There are a myriad of ways to skin this cat, be it a simple
recommendation to adopt the use of django's jQuery and a template tag
to provide access to the appropriate script tag, or something more
structured/engineered/formal
My goal would be to provide app developers with scaffolding to add
javascript/css resources to the rendered view in a non-competitive way.
I'm thinking in terms of a template tag that works along the lines of {%
include %}, but for script and link tags, allowing folks to add scripts
with an optional way to influence the position in the "stack". A
similar interface would also be provided for form media, and perhaps
some kind of helper or shortcut for ease the addition of these scripts
from our view functions.
I understand that Django has historically been
anti-javascript-framework-blessing, and I'm wondering if opening this
can of worms would mean having to incorporate some kind of a pluggable
backend system (for working with different frameworks, or multiple
frameworks at a time) - something I've briefly considered, but started
foaming at the mouth as a result.
I've also considered the fact that the reaction here might be, "just
don't - leave it all in the individual's hands".
In closing... don't hit me!
Regards,
Owen Nelson
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: managing javascript and css resources
Jacob Kaplan-Moss wrote: > If you'd like to look into it, a good place to start would be by > looking at the existing static asset management tools in the ecosystem... > I most certainly would like to. I'll prepare a "report" with my findings. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: managing javascript and css resources
I've read hpws, but not the sequel. I suppose following that train of thought, there should be the option for using 2 separate stacks - one for the head of the document, and one for the tail (stylesheets at the top and scripts at the bottom!) > "These aren't something we could easily incorporate. Just automating > JS and CSS bundling and compression would be a big help. This is a > good place to start on that:" Yes, I suppose it is. Keeping track of an ordered "set" of resources referenced by a particular view would mean we have a strong place from which to handle that kind of transformation. I wasn't actually planning on bringing that up since at least initially my priority would be to work on ways to keep our frontend code DRY -- just like our python code :) > Also I don't like how some of the available libraries encourage > concatenization of js/css files that shouldn't be concatenated (that > should all be done by hand for best results IMO). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: managing javascript and css resources
Yeah, I'm still working through my growing list of projects: https://www.google.com/bookmarks/l#!threadID=G6K-d-kjbHKA%2FBDSEyZAoQ09_aj4Il I'm trying to examine each one in terms of features, as well as checking the source to see how they are working. Nothing I've seen so far solves, or even addresses the original need for _not_ sourcing the same script numerous times (thanks to widgets with their own media). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: managing javascript and css resources
Kevin Howerton wrote: > The widget and admin media system needs to be re-evaluated IMO > none of these solutions are going to address the flaws you are > referring to. > "Flaws", sounds a bit harsh :P Let's alias that as "room for improvement". I'd agree that wrangling hashes and compressing assets at run-time is undesirable, and that a management command is preferable. There's a bit of conflict between what I crave, and the compress-everything-ahead-of-time tactic though. Actually... I take that back - following Gabriel's train of though, we could probably have it both ways. Since my goals are somewhat smaller (in some ways), I've started thinking about ways to implement what I want (some kind of "global" stack of client-side resources) that won't require sticking my fingers in the django source. At least not yet. Here's kind of what I'm thinking about: http://dpaste.org/Pjk5/ (Sorry, the naming is all a bit clunky - that was just off the top of my head) Extending something simple like that with some template tags, and stringing it all together with some middleware. This would give us a way to pool scripts together under one framework instance, also allowing us to dynamically add (from views and templates) them to the framework container throughout the life cycle of a request and response. I think I might be able to run some tests in a custom app - then start experimenting with the admin site. Once I've got all that setup, it should be a snap to add compression/concatenation somewhere along the pipeline, either at runtime or via a management command. Obviously, this is all very jQuery specific (where most of my javascript experience lies). I'd love to hear from someone on team dojo, prototype, yui, or extjs to learn about what doesn't fit with this model. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: managing javascript and css resources
In this case you're compressing at runtime... or am I missing something? I think I'm just going to burrow for a little while and prototype some helpers. I've got a project coming up shortly with some room for R&D on this front, so hopefully I'll be able to put them into production for a while before I bug anyone again. I'll be back (at some point) when I've got something I think will benefit the community. Thanks for all the interest in the topic though - I think that proves we are all hungering for *something* even if we're not exactly sure as to what it is. Silvio wrote: > Consider taking a look at an app I wrote, > http://www.sgawebsites.com/projects/django-aggregator/. > > It aggregates all JS and CSS files using a very simple syntax. It can > also pipe the content through YUI Compressor before saving the > aggregate. > My aim was to make it extremely easy to use. It's not an asset manager > though; I've yet to see or come up with a great solution. > > Regards, > > Silvio > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
I the first time I went through the trouble of refactoring a large set of models into a package I couldn't figure out why my models were "missing". Took me a while to trawl through a number of blog posts to come across the app_label requirement/mechanism. At the time, I don't think it was documented, but it certainly is now. I don't see the difficulty in extending the base model class one time for your app and currying all your models by extending that subclass. I've never tried, but it seems like it should work depending on the level of introspection done during discovery. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Document direct API usage of FileField and ImageField
I'd love to pitch in on updating the docs for file handling :)
Even though this kind of talk is better suited over on django-users, here's
one way to skin a cat.
I had a view that displayed a model form (one of the fields was a
FileField). I needed to alter the resolution of the uploaded image to make
sure it wasn't HUGE.
http://dpaste.org/oN2J/
In my case, I was resizing the original image *after* it had been stored
according to the file field's upload_to settings.
The 'image' I got from the form is basically a file object (
http://docs.djangoproject.com/en/dev/ref/files/file/) which is what I
tripped up on at first when putting this together. You have to make sure
whatever you pass to ImageField as "contents" is an object that implements
that "File" interface, so to speak. In the case of the upload from the
form, this was done for us, but if you have some random file on the
filesystem, you'd do something like this:
from django.core.files import File
tmpfile = File(open('/tmp/some-pic.jpg','rb'))
object.image.save('pic.jpg', tmpfile, save=True) # copy the image to
it's proper location and save the model instance when done.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Document direct API usage of FileField and ImageField
Actually, I'm not sure what way to go with this. All the info is there, it's just spread around in a number of topics: http://docs.djangoproject.com/en/dev/ref/files/file/ <http://docs.djangoproject.com/en/dev/ref/files/file/> http://docs.djangoproject.com/en/dev/topics/http/file-uploads/ <http://docs.djangoproject.com/en/dev/topics/http/file-uploads/> http://docs.djangoproject.com/en/dev/topics/files/ <http://docs.djangoproject.com/en/dev/topics/files/> http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField I'd almost say the best way to explore file handling would be to add an "extra credit" tutorial -- an extension of the poll app that serves as django's HelloWorld. Tricky thing is that there are a lot of moving parts... the storage system, upload_to, serving static files (if using ./manage.py runserver), upload handlers, the concepts around the File wrapper... It's all a bit much for a newcomer to the project. On Fri, Sep 17, 2010 at 2:11 PM, Owen Nelson wrote: > I'd love to pitch in on updating the docs for file handling :) > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
django.contrib.comments is judging me
So, I've been using django for about 2 years now. Last week was my first time using django.contrib.comments. Needless to say, I was shocked when it asked me to clean up my language during a late night coding binge (there may have been drink involved). I searched the docs, unaware there was ever a PROFANITIES_LIST setting, or that the concept of filtering foul language was ever the responsibility of the framework. Digging deeper, I found the (undocumented) setting that drives this behavior in the comments app. I was about to open a ticket with a patch to document it, but found it was left undocumented on purpose: http://code.djangoproject.com/ticket/9530 <http://code.djangoproject.com/ticket/9530>Moving forward, I'll be skipping the comment-specific setting and simply setting PROFANITIES_LIST to (). Any chance we'll see the setting removed in the near future? Best Regards, Owen Nelson -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django.contrib.comments is judging me
On Wed, Oct 6, 2010 at 11:30 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > Strictly, it needs to be put on a deprecation path, because it *is* > documented, in ref/settings.txt. So the earliest we can truly remove > it is in 1.5, after a PendingDeprecationWarning in 1.3 and a full > Warning in 1.4. > Sounds good to me. I've got *my* workaround until 1.5... in the mean time, would a separate ticket for the deprecation be in order so it doesn't get lost in the shuffle, or do you have another way of keeping track of this sort of thing? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django.contrib.comments is judging me
Well dang! "Magic" just happened. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
