Proposal: Deprecate PlaceholderMediaMiddleware/plugins_media in favor of django-sekizai
138 views
Skip to first unread message
Jonas Obrist
Feb 1, 2011, 8:46:00 AM2/1/11
to django-cms...@googlegroups.com
I propose deprecating the hacky and buggy PlaceholderMediaMiddleware (and plugins_media) template tag in 2.2 in favor of django-sekizai and removing it in 2.3.
In 2.2, all core plugins should be changed to use django-sekizai (using 'js' and 'css' sekizai namespaces as convention), the plugins should internally all fall back to populate the 'cmsplugins-media' sekizai namespace using the existing python APIs to add media, plugins_media should then be a de-facto alias for 'render_block "cmsplugins-media"'.
Jonas
Martin
Feb 1, 2011, 10:05:53 AM2/1/11
to django-cms...@googlegroups.com
Do I understand correctly that this enables us to write a CMSPlugin and tell the plugin that it should add some special CSS / JS files to the <head> of the page, if it is getting rendered on this page? At the moment I add super hacky <script> tags to the .html template of the plugin.
If so, big +1 !!
How does this play together with django-css (https://github.com/dziegler/django-css) and all the other media combiners / compressors?
Best regards,
Martin
Jonas Obrist
Feb 1, 2011, 10:43:37 AM2/1/11
to django-cms...@googlegroups.com
This would mean you can:
* Define your css/js/whatever needs in the templates, as opposed to your python code. Your frontend engineers will love it!
* Add css to the TOP of the page (eg: head)
* Add js to the BOTTOM of the page (eg: before </body>)
* Add stuff wherever you want
* Be sure that your scripts and stylesheets will only be there once! (sekizai bits are always unique!)
For more info see http://django-sekizai.readthedocs.org/en/latest/index.html
Jonas
benzkji
Feb 1, 2011, 4:45:51 PM2/1/11
to django-cms...@googlegroups.com
+1
after having a quick look, this should work perfect with media combiners/compressors.
ben
after having a quick look, this should work perfect with media combiners/compressors.
ben
Jonas Obrist
Feb 1, 2011, 4:54:35 PM2/1/11
to django-cms...@googlegroups.com
I will most certainly consider re-enabling 'filters/postprocessors' for sekizai-namespaces. There used to be such a feature, but it was overcomplicated and unsuable.
This might be slightly OT, but my idea is to allow something like this: "{% render_block mynamespace firstfilter secondfilter %}" where those two are filters registered somewhere (where?) and postprocess the contents. Those could be used for example to compress javascript.
benzkji
Feb 1, 2011, 5:01:41 PM2/1/11
to django-cms...@googlegroups.com
so this would do the same (more or less) as
{% load compress %}
{% compress js %}
<script src="/media/js/one.js" type="text/javascript" charset="utf-8"></script>
<script type="text/javascript" charset="utf-8">obj.value = "value";</script>
{% endcompress %}
when using this:
https://github.com/dziegler/django-css#readme
or have you something more advanced in your mind (beside the fact that your template's way shorter...)?
Øyvind Saltvik
Feb 1, 2011, 6:07:25 PM2/1/11
to django-cms-developers
I am all for switching to sekizai, but have a few issues. Say you have
two plugins using the same js lib/css how can you avoid loading them
twice. Only a whitespace difference or having a different order of
script tags is enough for getting it included twice. So needs to
document best practices when using common libs, maybe add some
templates that can be included for jquery/jquery ui.
two plugins using the same js lib/css how can you avoid loading them
twice. Only a whitespace difference or having a different order of
script tags is enough for getting it included twice. So needs to
document best practices when using common libs, maybe add some
templates that can be included for jquery/jquery ui.
Jonas Obrist
Feb 2, 2011, 12:28:57 PM2/2/11
to django-cms...@googlegroups.com
sekizai is *not* a compressor.
It's "asymetrical template rendering". Meaning you can access data from the bottom of the page from a tag at the top of the page and vice versa. This is especially useful for CMS Plugins, as you can insert your CSS into the top of the page and add your javascript at the bottom of the page from your plugin's template. Also you can be sure that if you use a library in your plugin that it's only loaded once, no matter how many times you put the plugin on your page.
I do however consider adding support for 'filters', which could be used to for example compress javascript.
Jonas Obrist
Feb 2, 2011, 12:29:48 PM2/2/11
to django-cms...@googlegroups.com
Yes you're right, we need to document best practices for CMS Plugins. I hope this is a good start: http://django-sekizai.readthedocs.org/en/latest/usage.html#sekizai-data-is-unique
benzkji
Feb 2, 2011, 1:49:10 PM2/2/11
to django-cms...@googlegroups.com
sure, got this one. I asked wether the filters would do more or less the same as the common compress tools that are already available - benefits/drawbacks?
Jannis Leidel
Feb 2, 2011, 1:51:39 PM2/2/11
to django-cms...@googlegroups.com
I'd like to encourage you to try out django_compressor for filtering purposes (the 0.6a10 from Github which is slated for release soon [1]).
http://django_compressor.rtfd.org/
Jannis
Jonas Obrist
Feb 2, 2011, 1:53:35 PM2/2/11
to django-cms...@googlegroups.com
I'm currently thinking about something along the lines of:
{% render_block "js" "mymodule.myfilterfunction" %}
So you basically give 'import paths' as additional (optional) argument(s) to render block.
I don't plan on shipping any filters actually.
Jonas Obrist
Feb 2, 2011, 1:54:02 PM2/2/11
to django-cms...@googlegroups.com
Absolutely, I don't plan on re-implementing that functionality
Øyvind Saltvik
Feb 2, 2011, 9:56:38 PM2/2/11
to django-cms-developers
Ah. :)
Got my +1
On Feb 2, 6:29 pm, Jonas Obrist <ojiido...@gmail.com> wrote:
> Yes you're right, we need to document best practices for CMS Plugins. I hope
> this is a good start:http://django-sekizai.readthedocs.org/en/latest/usage.html#sekizai-da...
Got my +1
On Feb 2, 6:29 pm, Jonas Obrist <ojiido...@gmail.com> wrote:
> Yes you're right, we need to document best practices for CMS Plugins. I hope
Angelo Dini
Feb 4, 2011, 3:36:24 AM2/4/11
to django-cms...@googlegroups.com
+1 how can fronteers work without it!
Jonas Obrist
Feb 4, 2011, 5:53:39 PM2/4/11
to django-cms...@googlegroups.com
Looking at the desolate and inconsistent state the current plugins media framework is right now and how most plugins either dont use it or use it improperly, i propose a non-backwards compatible change to happen in 2.2, rather than 2.3, by dropping the existing media framework now.
My proposed sekizai implementation would require users to provide at least the "js" and "css" sekizai-namespaces. This would of course be thoroughly documented.
Thoughts?
Tribaal
Feb 5, 2011, 6:05:27 AM2/5/11
to django-cms...@googlegroups.com
I don't like the idea of having to define stuff in your templates for the cms to work at all, butI see how useful it is: I guess it requires at least extremely good error messages ("you don't have a css block defined, please define one as per <link to docs>"...).
Do we have a way to check templates for correctness on server startup for instance? Just throwing ideas here, even if it sounds impractical.
---
Sent from my Android mobile
Jonas Obrist
Feb 5, 2011, 9:23:59 AM2/5/11
to django-cms...@googlegroups.com
Well you already now need to define stuff in your templates for the CMS to work properly ({% placeholder ...%}).
I so far have no way to make sure that a certain namespace is used in a template, due to the way sekizai works. The only way I see is something similar to placeholder-detecting, where we lex the template and check the nodes.
The issue is: The way we do it now (injecting from a middleware or hacking something together in a template tag) simply does not work. The cms-placeholder rendering even does it different than placeholder rendering and on top of that, most core plugins don't even use that old way anymore and just have their javascript files in their templates.
Jonas
Jannis Leidel
Feb 7, 2011, 5:13:08 AM2/7/11
to django-cms-developers
Jonas Obrist schrieb:
to provide those blocks. In doubt you could only raise a UserWarning
instead of throwing an exception if the block isn't found.
Jannis
> Looking at the desolate and inconsistent state the current plugins media
> framework is right now and how most plugins either dont use it or use it
> improperly, i propose a non-backwards compatible change to happen in 2.2,
> rather than 2.3, by dropping the existing media framework now.
>
> My proposed sekizai implementation would require users to provide at least
> the "js" and "css" sekizai-namespaces. This would of course be thoroughly
> documented.
>
> Thoughts?
+1 It's a good idea and totally reasonable to ask CMS template authors
> framework is right now and how most plugins either dont use it or use it
> improperly, i propose a non-backwards compatible change to happen in 2.2,
> rather than 2.3, by dropping the existing media framework now.
>
> My proposed sekizai implementation would require users to provide at least
> the "js" and "css" sekizai-namespaces. This would of course be thoroughly
> documented.
>
> Thoughts?
to provide those blocks. In doubt you could only raise a UserWarning
instead of throwing an exception if the block isn't found.
Jannis
Jonas Obrist
Feb 19, 2011, 8:55:13 AM2/19/11
to django-cms...@googlegroups.com
I've got the backend part of it pretty far now and would welcome anyone to review my patch:
Reply all
Reply to author
Forward
0 new messages