You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The initial blocks/layout system was a reasonable first step, and it does an ok job for most cases; different types of content (leaves) have priority ratings, and different priorities based on whether they'll be in the main content area or the sidebar. However, the number of edge-cases created by this system has significantly increased the complexity; there's a special flag indicating whether the current view is the homepage, categories and tags have to have a "content priority" setting that overrides the defaults (which can cause more problems than it solves), and I still have no particularly good way of handling special cases like /photo (which should primarily show an array of all highlighted images, not just the ones in child/descendant categories).
I'm still determining what the ideal solution would look like, but I suspect it will involve replacing the content-priority setting with an option to define custom functions/classes that the category and tag views can include. I want to keep the system flexible enough to be content-agnostic, because the "folders that can contain files of any type" paradigm is very important to me, and the DeerTrees app was created to be something that any project could potentially incorporate.
Regardless, this is in the works, and may involve a rebuild of the DeerTrees app, but it's definitely an area that's not quite where I want it to be, and I feel I can do better.
The text was updated successfully, but these errors were encountered:
…he Blocks system used in the DeerTrees views. Full details here: http://www.lupinia.net/code/projects/django/deertrees.htm This change additionally implements a management command to choose and set a thumbnail for categories that need one.
The initial blocks/layout system was a reasonable first step, and it does an ok job for most cases; different types of content (leaves) have priority ratings, and different priorities based on whether they'll be in the main content area or the sidebar. However, the number of edge-cases created by this system has significantly increased the complexity; there's a special flag indicating whether the current view is the homepage, categories and tags have to have a "content priority" setting that overrides the defaults (which can cause more problems than it solves), and I still have no particularly good way of handling special cases like /photo (which should primarily show an array of all highlighted images, not just the ones in child/descendant categories).
I'm still determining what the ideal solution would look like, but I suspect it will involve replacing the content-priority setting with an option to define custom functions/classes that the category and tag views can include. I want to keep the system flexible enough to be content-agnostic, because the "folders that can contain files of any type" paradigm is very important to me, and the DeerTrees app was created to be something that any project could potentially incorporate.
Regardless, this is in the works, and may involve a rebuild of the DeerTrees app, but it's definitely an area that's not quite where I want it to be, and I feel I can do better.
The text was updated successfully, but these errors were encountered: