tagging feature

[bbelderbos]

I have it like this:

class Tag(models.Model):
    name = models.CharField(max_length=128)

    def __str__(self):
        return self.name

On Tune model:

    tags = models.ManyToManyField(Tag, related_name='tags')

[bbelderbos]

Then in admin:

class YourAdmin(admin.ModelAdmin):
    ...
    autocomplete_fields = ('tags')

But I want to investigate how to get this niceness on the front-end ...

[bbelderbos]

desired front-end = like django admin m2m:

[bbelderbos]

@jwjacobson seems not natively doable with htmx so I am happy to play with this gpt suggestion to offload this from you:

[bbelderbos]

@jwjacobson can you spec out the feature a bit?

• should there be a set of fixed tags? In that case superuser can manage that in admin
• should users add tags? if so, in the same create tune form or in a separate view?
• the create tune form already yields tags, but it did not seem to work, let me check this now ...

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?

[bbelderbos]

Update create tune view only renders tags added by admin first (the save/linking did not work but I logged and fixed that here: https://github.com/jwjacobson/jazz_repertoire/issues/184)

[bbelderbos]

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 ...

[jwjacobson]

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

[bbelderbos]

Thanks for clarifying, no need for tag ownership then. An autocomplete to retrieve + add tags would be really convenient then, let me check again ... yesterday I found a bunch of jquery but not sure if it would be good to bring that into this project ...

[bbelderbos]

Going to try this out tomorrow:

https://django-autocomplete-light.readthedocs.io/en/master/index.html

Feature included:

Creating choices that don’t exist in the autocomplete

[bbelderbos]

Did this:

Seems exactly what we need!