Release v0.5.0 (#149)

Author: thibaudcolas

CHANGELOG.md

@@ -2,9 +2,19 @@
 
 ## [Unreleased]
 
+## [0.5.0] - 2021-06-04
+
 ### Added
 
-- Added support for 'context modifiers' - A way to modify template contexts with Python [#141](https://github.com/torchbox/django-pattern-library/pull/141)
+Added support for '[context modifiers](https://torchbox.github.io/django-pattern-library/guides/defining-template-context/#modifying-template-contexts-with-python)' - A way to modify template contexts with Python ([#141](https://github.com/torchbox/django-pattern-library/pull/141), [#147](https://github.com/torchbox/django-pattern-library/pull/147), [#106](https://github.com/torchbox/django-pattern-library/issues/106)).
+
+This addresses the following limitations of the pattern library:
+
+- [#10 No way to specify objects that have attributes and support iteration](https://github.com/torchbox/django-pattern-library/issues/10)
+- [#113 Django form fields not well supported](https://github.com/torchbox/django-pattern-library/issues/113)
+- [#135 Competing tag/context config for image provides inconsistent result](https://github.com/torchbox/django-pattern-library/issues/135)
+
+View the [documentation](https://torchbox.github.io/django-pattern-library/guides/defining-template-context/#modifying-template-contexts-with-python), as well as demos leveraging the new capability: [forms](https://torchbox.github.io/django-pattern-library/demo/pattern-library/pattern/patterns/pages/forms/example_form.html) (see [forms and fields recipe](https://torchbox.github.io/django-pattern-library/recipes/forms-and-fields/)), and [pagination](https://torchbox.github.io/django-pattern-library/demo/pattern-library/pattern/patterns/pages/search/search.html) (see [pagination recipe](https://torchbox.github.io/django-pattern-library/recipes/pagination/)).
 
 ## [0.4.0] - 2021-05-20
 
@@ -38,24 +48,29 @@ We have a new documentation website! Check out [torchbox.github.io/django-patter
 ## [0.2.9] - 2020-07-29
 
 ### Added
+
 - Atomic design no longer enforced and pattern templates can be from several locations, rather than a single location.
   These changes are currently undocumented, see the tests for examples.
 
 ### Fixed
+
 - Templates that are not explicitly part of the pattern library can no longer be rendered by the pattern library
 
 ## [0.2.8] - 2020-03-13
 
 ### Added
+
 - Moved to github and open sourced
 - Support for Django 3.0
 - Support for Python 3.8
 
 ### Removed
+
 - webpack-dev-server
 - references to old name of 'Mikalab'
 
 ### Fixed
+
 - Documentation links and improved documentation
 - Accessibility issues with pattern library chrome
 - JavaScript in IE11 (added polyfills)
@@ -65,17 +80,20 @@ We have a new documentation website! Check out [torchbox.github.io/django-patter
 ## [0.2.5] - 2019-11-01
 
 ### Added
+
 - Switch to Poetry for dependency management
 - Documentation tab for each pattern that will display a markdown file if it is stored along with the html and yaml files
 - Extra yaml examples in the README
 - Merge request template
 
 ### Changed
+
 - Improve documentation for developers
 
 ## [0.2.4] - 2019-06-11
 
 ### Added
+
 - Compatibility with Django 2.2
 
 [0.2.9]: https://github.com/torchbox/django-pattern-library/releases/tag/v0.2.9

docs/reference/known-issues.md

@@ -2,38 +2,10 @@
 
 django-pattern-library has a few known limitations due to its design, which are worth knowing about when authoring templates or attempting to document them in the pattern library.
 
-## No way to specify objects that have attributes and support iteration
-
-See [#10](https://github.com/torchbox/django-pattern-library/issues/10). It’s impossible to mock the context when a variable needs to support iteration _and_ attributes. Here is an example of this impossible case:
-
-```django
-{% for result in search_results %}
-{# […] #}
-{% if search_results.paginator.count %}
-```
-
 ## Overriding filters is not supported
 
 See [#114](https://github.com/torchbox/django-pattern-library/issues/114). PRs welcome!
 
-## Django form fields are not well supported
-
-See [#113](https://github.com/torchbox/django-pattern-library/issues/113). If a template contains `{% for field in form %}` or even `{% if form %}`, then it's easy enough to render in django-pattern-library so long as we force the form to be null in the YAML context, and are happy not to have the form.
-
-If the form is rendered explicitly by field names, then it requires a lot more work, which can quickly become too much of a maintenance burden – for example creating deeply nested structures for form fields:
-
-```yaml
-  form:
-    email:
-      bound_field:
-        field:
-          widget:
-            class:
-              __name__: char_field
-```
-
-While this is in theory possible, it’s not a very desirable prospect.
-
 ## Can’t override context in a child template
 
 See [#8](https://github.com/torchbox/django-pattern-library/issues/8).
@@ -67,7 +39,7 @@ This can be worked around by creating pattern-library-only templates, see [Multi
 
 ## Can’t mock each use of a template tag with different attributes
 
-For example, with a template that uses the same tag many times like:
+See [#138](https://github.com/torchbox/django-pattern-library/issues/138). For example, with a template that uses the same tag many times like:
 
 ```django
 {% load wagtailcore_tags %}
@@ -90,8 +62,50 @@ For example, with a template that uses the same tag many times like:
 
 This can’t be mocked for all usage of `include_block`.
 
+## Past limitations
+
+### No way to specify objects that have attributes and support iteration
+
+🎉 This is now addressed as of v0.5.0, with the [context modifiers in Python](../guides/defining-template-context.md#modifying-template-contexts-with-python) API. View our [pagination](../recipes/pagination.md) recipe.
+
+---
+
+See [#10](https://github.com/torchbox/django-pattern-library/issues/10). It’s impossible to mock the context when a variable needs to support iteration _and_ attributes. Here is an example of this impossible case:
+
+```django
+{% for result in search_results %}
+{# […] #}
+{% if search_results.paginator.count %}
+```
+
+## Django form fields are not well supported
+
+🎉 This is now addressed as of v0.5.0, with the [context modifiers in Python](../guides/defining-template-context.md#modifying-template-contexts-with-python) API. View our [forms and fields](../recipes/forms-and-fields.md) recipe.
+
+---
+
+See [#113](https://github.com/torchbox/django-pattern-library/issues/113). If a template contains `{% for field in form %}` or even `{% if form %}`, then it's easy enough to render in django-pattern-library so long as we force the form to be null in the YAML context, and are happy not to have the form.
+
+If the form is rendered explicitly by field names, then it requires a lot more work, which can quickly become too much of a maintenance burden – for example creating deeply nested structures for form fields:
+
+```yaml
+form:
+  email:
+    bound_field:
+      field:
+        widget:
+          class:
+            __name__: char_field
+```
+
+While this is in theory possible, it’s not a very desirable prospect.
+
 ## Can’t mock objects comparison by reference
 
+🎉 This is now addressed as of v0.5.0, with the [context modifiers in Python](../guides/defining-template-context.md#modifying-template-contexts-with-python) API.
+
+---
+
 With instances of models, the following works fine in vanilla Django, due to `item` and `page` being the same object:
 
 ```django

pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "django-pattern-library"
-version = "0.4.0"
+version = "0.5.0"
 description = "A module for Django that allows to build pattern libraries for your projects."
 authors = [
     "Ben Dickinson <[email protected]>"