Oops. I configured a small downstream project with powercrud without requiring ASYNC_ENABLED (actually without even settings.POWERCRUD_SETTINGS which is an bigger fail gievn it didn't report that was the issue). The system crashed on load because it tries to load django_q and requires settings.Q_CLUSTER even when not required.
We need to put some guards in to m ake the system robust. I got too caught up in my current dev environment with a very sophisticated setup for powercrud and forgot about the basic use cases. Oops.
This is a plan to refactor configuration by consolidating all parameter resolution methods into a new ConfigMixin.config method, to make it easier to reason about and maintain configuration rules.
When there is a M2M field, we get a multiple select element that makes the row taller. I dont want that. I want the element to stay single row height (like with regular dropdowns) but allow picking multiple options from a dropdown list. This post looks at 2 options: (a) roll your own; and (b) use Tom Select.
I had a think about possible enhancements. I think the top priorities might be:
- the template pack system (to formalize UI extensibility),
- related-model HTMX editing, and
- richer async orchestration with live feedback.
The bootstrap5 templates are very out of date because all of the development has gone into daisyUI templates. The continuing presence of the bootstrap5 templates creates confusion. I have in mind a future simplification and modularisation of the template system (something along the lines of template packs like crispy-forms does) but that won't be for a while. So in the meantime, it's better to just remove bootstrap5 completely. This is the plan to do that.
Need to implement dependabot or renovate for automatically bumping versions to take account of dependency version increments. Also need to consider how to keep docker images and python versions updated.
This is about implementing a testing matrix approach for running all tests for a matrix of say python vs django versions. I considered using uv insteas of tox for this.
I need to implement a full test suite for powercrud. At least pytest covering every module (to say >= 80% on coverage) and even some sleected playwright front end tests.
merge --squash looked clean on paper but kept biting me with detached histories, lost commit metadata, and surprise conflicts that were hard to replay. The workflow that finally stuck is even simpler: fast-forward main, soft-reset the feature branch to that point, and create the single commit I actually want.
I implemented a dashboard but the steps in the downstream project to wire everything up are a bit clunky. This post outlines a possible reusable subclass to allow easier setup of the dashboard.
In a current downstream project that I have, in the save() method of a number of models we have extensive updates (and creates, but that's not relevant to conflict checking) of descendant objects. And I will probably make these run async as part of the save() method. Of course I would want to flag them for conflict detection and management in the same framework.
However if we do this, then if we had a bulk update of a number of objects we would have a problem:
send all objects to be updated async. We do not know about the descendant objects from within powercrud so only have parent id's.
call save() for object
then within save() try to call async task for descendant updates
the async sub-tasks all appear to complete immediately and our parent task ends, even though subtasks are continuing (perhaps for quite a while)
So what we want is a kwarg in the save() method - let's say skip_async. And if that's the case then we do not raise the descendant update as a new async task, however what we do is add all those descendant objects to the conflict store.
Exploring how powercrud's existing table components can be reused for parent/child relationship editing within forms, if we already had inline editing for the main list.
The Idea
I'm thinking of a feature to make it easy to edit parent and child objects on the same object_form, because this is a very common requirement. We could use inline formsets, which is feasible. But a different pattern could be to have an editable htmx-enabled table of the child objects under the parent form. This article explores how much re-use we could achieve from existing powercrud elements.
This document explains how Neapolitan currently handles roles, how to add custom roles today, and a design for a new package that preserves ergonomics while making extensibility first-class.
Note
Yep, this was generated by an AI in a chat. I want to keep it for future reference.
By introducing async processing we introduce potential conflicts. Also want to allow downstream project developers to use the same base mechanism for conflict detection, in case they want to run async processes independent of powercrud (eg save() method that updates child and descendant objects) but want overall conflict detection.
I was thinking about the difference between opinionated and non-opinionated packages, and what principles might guide the design of opinionated extensions like this one so they don't become so narrow that they're unusable.
When attempting to submit the bulk edit form within the modal, an htmx:targetError is encountered in the browser console. This error indicates that the HTMX target element, <div id="powercrudModalContent"></div>, is missing from the Document Object Model (DOM) at the time of the form submission.