Menu
I want to define a widget something vaguely like this:
{% block css %}
.mywidget {
css: goes_here;
{% endblock %}
{% block widget %}
<div class="mywidget">
<!-- structure goes here -->
</div>
{% endblock %}
{% block script %}
$( ".mywidget" ).addFunctionality(stuff)
{% endblock %}
In other words, a deceleration of what CSS the widget needs, what its contents are (preferably parametrized in some way), and what scripts it requires at the end of the file. Then, I would like to be able to extend a layout template, add widgets to the body (possibly multiple widgets of the same type with different parameters of some kind), and have the CSS and javascript properly added to the top and bottom of the layout template, once per widget type.
This seems like a pretty clean and straightforward design, and coming from a native UI design perspective, I am confused as to why I cannot find any examples of how to do something like this.
983
You have fleshed out part of the design for a widget system, but really have only shown how you would go about designing the widget. The other part is how you would end up USING the widget in Jinja.
For example, you could use Jinja Macros to define the widget. Create a file "mywidget.html" and use...
{% macro css() -%}
.mywidget {
css: goes_here;
}
{% endmacro %}
{% macro widget() -%}
<div class="mywidget">
<!-- structure goes here -->
</div>
{% endmacro %}
{% macro script() -%}
$( ".mywidget" ).addFunctionality(stuff)
{% endmacro %}
Then, in your HTML using this widget, you could do...
{% import 'mywidget.html' as mywidget %}
...
<html>
<head>
<style>
{{ mywidget.css() }}
</style>
<head>
<body>
{{ mywidget.body() }}
<script>
{{ mywidget.script() }}
</script>
</body>
</html>
Of course, the problem here is that you need to manually put all of the widgets into the various areas. Once you get a larger number of widgets, it might be hard to keep track of them, and it would be easy to, for example, have the mywidget.script() code created multiple times, which would cause duplicate event fires.
And, of course, you could always have Python objects as part of the context rendering the final solution. The important thing to note is that Jinja just renders text from templates. The templates don't even have to be HTML template, you could use Jinja to render a plain text e-mail. Therefore, it would be difficult to imagine the authors of the library trying to create these sort of "widget" system and expect everyone to be happy by the result. Why increase the complexity of the library with such a complex feature that they will need to support (especially since Jinja provides people with the tools to build such a framework already)?
189
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
