Thanks a lot for the kind answers. *But perhaps the default copy-paste messages the fellows use could have a little more empathy towards those who are unfamiliar. The majority of Trac users are only around for one ticket, or a few.*
I agree with you Adam, my emotional perception of the messages I received may boil down to conciseness and formalism of the copy/paste (almost automatic) answer. However I totally understand the overwhelming load of tickets on the Trac team and the need to process them efficiently. I don't know Trac under the hood, but maybe longer "automatic" answers can be written down somewhere, that explain things more thoroughly and gently, especially to newcomers. Your rewording suggestion sounds like a good start. If you are willing to discuss the topic I'd be happy to suggest longer versions (if technically possible to implement). *Sébastien - on your original post: you didn't provide any useful title or ticket links in your post. That may have stopped readers engaging on the list. No one knows ticket numbers, but some people will be interested when they see a post on "the admin autocomplete". Links would make it easy to catch up. More context makes it easy to engage.* You're totally right. I feel stupid for not thinking of that in the first place. That will serve as a lesson for my future posts to this board, sorry. ---- Now about the issue itself. I think I understand the underlying point here, being: the admin is not meant to please every possible user, and thus should not be bloated with every possible feature. I definitely understand the need for the admin (and Django itself for that matter) to stay generic and encourage overriding. My understanding of this argument stops early though, as I do not understand why the $.fn.djangoAdminSelect2 function would accept an options parameter *at all* then. This options parameter is never used in Django's own code, as far as I can tell. The very presence of this parameter led me to think that I (as a regular Django user) could use the $.fn.djangoAdminSelect2 function when extending the admin for my own needs. Using it made me feel that I got my back covered since I used Django's implementation of Select2 and would then benefit future code evolution, which would avoid breaking of my own code. This is why I suggested that, since this parameter exists, it should be fully and correctly implemented. In its current state, it allows to provide *any* Select2 option *except* those nested under the ajax key. If Django calls to $.fn.djangoAdminSelect2 were to evolve in future versions, and provided, say, the Select2 tags option, it could break my own calls to $.fn.djangoAdminSelect2 that provided the tags option. The current situation seems totally counter-intuitive to me. I would expect options to be either absent (telling me that, if I want to instantiate autocomplete widgets for my own needs then I'm on my own) OR, if present, to be fully usable (meaning that I could really provide it any Select2 option, since Johannes Maron suggested it should respect Select2 API). Additionally, I do not see how this would add complexity to the code and/or the API. The API would remain strictly the same ( $.fn.djangoAdminSelect2(options)) and the code itself needs only an additional ~5 lines. Overrides of back-end autocomplete views, though useful, do not solve the same usecases. Thanks again for your answers. Best regards, Sébastien Gélis Le mardi 8 juin 2021 à 13:15:11 UTC+2, Adam Johnson a écrit : > Sébastien - on your original post: you didn't provide any useful title or > ticket links in your post. That may have stopped readers engaging on the > list. No one knows ticket numbers, but some people will be interested when > they see a post on "the admin autocomplete". Links would make it easy to > catch up. More context makes it easy to engage. > > >> Carlton: Sorry you feel hard done by here. I think that's perhaps >> unfamiliarity with the workflow. >> > > I agree here that it can be down to unfamiliarity. But perhaps the default > copy-paste messages the fellows use could have a little more empathy > towards those who are unfamiliar. The majority of Trac users are only > around for one ticket, or a few. > > Mariusz wrote: "Please follow triaging guidelines with regards to wontfix > tickets." The conciseness *can* be read as curt. > > I suggest a reword to something like "I appreciate you'd like to reopen > the ticket, but please *follow the triaging guidelines with regards to > wontfix tickets* and take this to the django-developers mailing list." > > >> Carlton: The admin's role is not to be a general application development >> platform > > > 💯 agree here. My gut reaction is the same. Most organizations who try to > build their "back office" within the admin end up digging themselves into a > bit of a hole with their customizations. Building your own pieces is > normally a better approach when you need a certain level of customization. > > Just yesterday I was advising a client who wanted some different > autocomplete customizations. I also recommended trying django-select2, as > Johannes wrote on the ticket ( > https://code.djangoproject.com/ticket/32628#comment:5 ). > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b8f6e528-dbd7-4c82-b3f8-4739eb1a4d41n%40googlegroups.com.
