-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tagging feature #174
Comments
Then in admin:
But I want to investigate how to get this niceness on the front-end ... |
@jwjacobson seems not natively doable with htmx so I am happy to play with this gpt suggestion to offload this from you: |
@jwjacobson can you spec out the feature a bit?
So the key question is if you want to autocomplete on the tags which involves more JS, not sure if that's really a prio for MVP? |
Update create tune view only renders tags added by admin first (the save/linking did not work but I logged and fixed that here: #184) |
So the question remains do you want to have user add tags at the front-end and if so will you make a new crud for it? In that case you might also want to add a user foreign key column to the tag table to keep track of who owns which tag ... |
I think autocomplete on tags can be a nice to have, and not doing it for now could involve a much simpler implementation The idea for tags is that you can have various bits of information about a tune that don't fit into any of the provided fields and would make tune management too cumbersome if they each had their own field. In its simplest form a tag is just a string of text. Possible tags I'm imagining are "ballad" (if the tune is a ballad), "latin" (if the tune is played in latin style), "rhythm" or "rhythm_changes" (if the tunes uses rhythm changes), etc. Basically little notes on the style or structure of a tune which will all be searchable. The user should be able to add any tags they want, as this would be a space for significant repertoire customization. They might want to add tags for tunes they play with specific people or groups, or really anything. With autocomplete, my thinking was just that a lot of the structural/stylistic tags will end up being common to many users so it makes sense for them to be able to access that pool of common tags. On the other hand it's much more complicated to implement. Do you think it might make sense for now to just have tags as a charfield? This would capture all of the functionality I describe minus autocomplete which isn't a necessity anyway |
Thanks for clarifying, no need for tag ownership then. |
Going to try this out tomorrow: https://django-autocomplete-light.readthedocs.io/en/master/index.html Feature included:
|
Just using little checkboxes for now, works fine. Of course the user can't add their own tags yet... |
I have it like this:
On Tune model:
The text was updated successfully, but these errors were encountered: