Interested in GSoC idea "Replace Form Media Class"

201 views
Skip to first unread message

Varun Sharma

unread,
Feb 23, 2015, 10:31:34 PM2/23/15
to django-d...@googlegroups.com
Hi everyone,

I've been pondering over the django codebase and GSoC ideas for some time now. I find the idea of replacing Media class really interesting. As mentioned in the ticket #22298 discussion, it will be really usefull to replace the Media class with some sort of combination of django-pipeline and django-compressor as a new Static class. I would love to add this feature to django in this summer and I would like to discuss this idea further to help me get the best implementation for this idea.

Thanks
Varun

Tim Graham

unread,
Feb 24, 2015, 6:30:04 AM2/24/15
to django-d...@googlegroups.com
Hi Varun,

Thanks for your interest. If you want feedback, you'll need to describe your ideas in more detail.

Tim

Varun Sharma

unread,
Mar 13, 2015, 5:37:44 PM3/13/15
to django-d...@googlegroups.com
Hi Tim,

Sorry for such a late response, I was caught up in the midterms.
The project idea is like this:

Right now we have a Media class which is used to fetch the form assets but is not very popular. In order to replace it with a new preprocessor, I see two viable solutions:

1. Creating a new app 'static' in django.contrib with glean best practices from django-pipeline and django-compressor.

In this option, all the assets need to be declared in STATIC_CSS and STATIC_JS dicts in the settings for the different apps/scenarios just like they have it in django-pipeline and these assets can be loaded in templates as per requirements.

We can provide support for all the major js and css compressors/compilers like CoffeeScript, LiveScript, Closure, JsMin, Slimit, UglifyJS and YUI compressor for Javascript and CssMIN and CSSTidy minifier for CSS by installing these compilers in advance.
All the files that need to be minified can be mentioned in source_filenames and the minified version will be generated as STATIC_JS['output_filename'] after compilation during collectstatic.

For eg:

STATIC_JS = {
    'main': {
        'source_filenames': (
            'coffee/app.coffee',
            'js/*'
        ),
        'output_filename': 'min.js',
    },
}

STATIC_CSS = {
    'main': {
        'source_filenames': (
            'stylus/main.styl',
            'css/*',
        ),
        'output_filename': 'main.css',
    }
}


2. Creating a new 'Static' class in django.contrib.staticfiles and integrating it with the current implementation to add preprocessing.

Another option is that, we can have a permanent solution without any future need of any ad-hoc based solution for the problem of static resource optimisation. But it will require a lot of changes in the entire structure of staticfiles, mostly in staticfile handlers and storage. Placement of compiler support files in contib.staticfiles might also be a concern in this case.

I am still discovering and learning new things about django and preprocessing. I'd really appreciate if I'll be able to get feedback on this from django community, so that I can draft a better proposal for this project.


Thanks
Varun


--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/512d302f-bcb5-446c-afb6-a72dce93e7e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tim Graham

unread,
Mar 14, 2015, 7:01:53 PM3/14/15
to django-d...@googlegroups.com
Jannis Leidel, who's worked a fair bit on django-compressor, said this: "I’m not convinced that this is feasible in the way the OP proposed it. Porting over pipeline or compressor will just bring all of their downsides into Django’s code. And besides, the frontend tech world is currently in a state of reinvention so I’d rather not have us support a pattern that may work now but won’t in the mid and longterm. All in all I think it would be a hard project outside gsoc, to find a api that is flexible enough for potential future use cases, for a gsoc it seems like a bad idea tbh."

Varun Sharma

unread,
Mar 16, 2015, 1:47:55 PM3/16/15
to django-d...@googlegroups.com
Thanks Tim for letting me know. I think I should better work on "Test framework cleanup" idea :)
Reply all
Reply to author
Forward
0 new messages