Comments (8)
@shacker Thanks for the suggestion.
I do not see how I can build my feature on signals alone. Maybe you'll have good insight.
As discussed in #69, I'm working on a complex Wagtail workflow, that would go as follow:
- Create a Page with associated todo task "Write the title & keywords". A user will pick the task, then can navigate to the Page in question from the task.
- When the title & keywords have been submitted, a hook could auto-close the title task, and create a new "write the body" task for the same article.
- Similarly, once the writing is completed, the task will be closed and a review task will be open for reviewers to pick. Then we have a client check, and finally the publication.
As you can see, I need a ManyToOne relationship (foreignkey) between a Task and a Page (in the next release, we'll handle similar workflow with different models, which is why I wrote the contentype generic relation in the example).
How would you be able to close the proper related task when submitting a page with signals alone?
from django-todo.
You can do anything from your custom signals. I've created a sample pull request demonstrating how the system could be used. This is very bare bones but demonstrates that the flexibility is unlimited:
I really think this is the way to go. Less invasive, more flexible, more extensible, more portable to other use cases.
In fact... I need to think about this a bit more, but I'm not even sure django-todo needs to provide anything in this department. Any project can define its own signal handlers and receivers in whatever way makes sense for them. But maybe there is some core stuff (like the complete toggle) we should provide as a reference.
from django-todo.
Your mention of needing "a hook to auto-close the title task" is a good example of a need that's specific to your use case, rather than a general use case. Easily provided by signals.
As to your need for a db relation between Task and Page, that is something you can create from within your project.
from django-todo.
django-todo models shouldn't have relations with external apps.
More specifically, fine to create those relationships, but you should create them from within your own project. Modifying core todo models is a pretty tectonic shift and un-needed by anyone else until now. Django projects take a million different forms. The best goal of this app is to stay vanilla and let people integrate it however they need to.
I could create a table to store tuples of task ids, page ids, and workflow step ids within the wagtail-todo app
Sure. Or just simple FKs or M2Ms between your models and Task or TaskList. Whatever you need!
signals connected to tasks & page actions could do a lookup on that table to figure out what is connected to what.
Absolutely. Then you can always write whatever code you need to do whatever you need without needing to modify any models or migrate anything, or to require migrations in a 3rd-party app!
The optimal design pattern is that each app should limit its scope as much as possible. "Small pieces, loosely joined" (the Unix philosophy). Emphasis on "loosely joined." It's what prevents software from becoming spaghetti.
from django-todo.
@shacker fair enough. Thanks for your support.
from django-todo.
@shacker fyi, since this is a blocker for me, I'll get started on it now.
from django-todo.
@Fandekasp Since the goal here is to trigger task changes when something elsewhere in the project changes, I think a more flexible (and less invasive) solution would be to take advantage of Django's native signals system.
Django includes a “signal dispatcher” which helps allow decoupled applications get notified when actions occur elsewhere in the framework. In a nutshell, signals allow certain senders to notify a set of receivers that some action has taken place. They’re especially useful when many pieces of code may be interested in the same events.
That would give you or others the flexibility to create additional signals handlers (or arguments to a single handler) with limitless flexibility, no need for model changes, and no need for another dependency (I try to keep the number of required dependencies to a minimum).
Then other parts of the app could trigger signals on more than just model changes - they could respond to REST inputs, javascript events, model save() triggers, or anything at all.
Can you make an argument in favor of model changes over using signals? Let me know what you think
from django-todo.
@shacker if I understand properly, your thinking goes as follow:
- django-todo models shouldn't have relations with external apps.
- I could create a table to store tuples of task ids, page ids, and workflow step ids within the wagtail-todo app
- signals connected to tasks & page actions could do a lookup on that table to figure out what is connected to what.
This doesn't sound optimal :( I'll spend more time clarifying my understanding of django signals, wagtail hooks, and Django good patterns.
In any case, great support, thanks a bunch!
from django-todo.
Related Issues (20)
- Social message response HOT 4
- Django HOT 1
- Where do i place the Navigation CSS? HOT 2
- TypeError: view must be a callable or a list/tuple in the case of include(). HOT 2
- Login Loop HOT 2
- Add Task Button not responding HOT 5
- pip install django-todo didn't install bleach HOT 1
- Match registered users sending emails to tracker and add them to "created by" HOT 1
- setup.py imports django, which it shouldnt HOT 6
- Occasional crasher when importing CSVs HOT 7
- Failed migration
- Self Test Fails HOT 1
- Add SECURITY.md HOT 2
- Please do docker-compose HOT 8
- Demo `500: Hard Crash` when entering comments HOT 2
- manage.py is missing HOT 1
- python3 manage.py migrate todo: multiple exception types must be parenthesized HOT 2
- todo/home.html not extending project home.html
- pipenv path and executable path issues HOT 3
- Relate tasks to other objects HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-todo.