Re: Vendoring Select2
Hi all, In our experience, it would be worth removing noConflict, but we need Django to have a recent jQuery release, it's wasn't always the case but now it's good. I don't know who relies on that except grappeli, but they would probably be happy to get rid of their double jquery loading because that's been the source of many user issues, at least in DAL's repo. Another library that would be worth proposing is jquery-autocomplete-light (disclamer: I'm the author), particularely because it is built to let the server render the suggestions box, and because it's pretty light by essence (does nothing on selection but trigger an event, it's up to the developer to implement the callback). But I should do some crowdfunding or something to cover it with JS unit tests, currently it's abandoned except by most django-autocomplete-light < 3.0 users, some v3 users are using it already even thought it's not been officially released / supported, because I was maintaining it with selenium tests and that was too much of a pain of course to have no unit tests. If you need generic form widgets, I think we've got ok ones in django-autocomplete-light v3. Again what's missing for developer experience is just the ability to override the default form, without having to subclass the world just to pass it: when you need an autocomplete on a field, you most likely need it everywhere, ie. because the select would load too many options to be usable. We'd be very happy to see noConflict removed, and try to all rely on the latest jQuery, rather than all try to load our own and deal with different variables names for jQuery. Perhaps I should try this in a fork, even if that means DAL will require extra steps for users not on that specific Django fork, at least we'd figure out if removing noConflict had unseen drawbacks. Best -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/43f81fe5-6999-4400-90a7-68585ca51c49%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vendoring Select2
Hi! I didn't get your name, but this address the latest post. I think we made some good progress in the regarding this issue. The inclusion of select2 is at a stage where I wouldn't want to jump to a different library. Especially considering that now one acted at this ticket for seven years and it took me 2 years to work on the issue and it still isn't merged. That being said, the major question remaining is whether or not to disable `noConflict(true)`. I don't mind, I made it work without it. But maintenance wise, it's simpler to just disable it. I would love to see some feedback from the core team here. I really like to get this resolved. Cheers -Johannes On Tuesday, June 6, 2017 at 9:36:04 AM UTC+2, is_null wrote: > > Hi all, > > In our experience, it would be worth removing noConflict, but we need > Django to have a recent jQuery release, it's wasn't always the case but now > it's good. I don't know who relies on that except grappeli, but they would > probably be happy to get rid of their double jquery loading because that's > been the source of many user issues, at least in DAL's repo. > > Another library that would be worth proposing is jquery-autocomplete-light > (disclamer: I'm the author), particularely because it is built to let the > server render the suggestions box, and because it's pretty light by essence > (does nothing on selection but trigger an event, it's up to the developer > to implement the callback). But I should do some crowdfunding or something > to cover it with JS unit tests, currently it's abandoned except by most > django-autocomplete-light < 3.0 users, some v3 users are using it already > even thought it's not been officially released / supported, because I was > maintaining it with selenium tests and that was too much of a pain of > course to have no unit tests. > > If you need generic form widgets, I think we've got ok ones in > django-autocomplete-light v3. Again what's missing for developer experience > is just the ability to override the default form, without having to > subclass the world just to pass it: when you need an autocomplete on a > field, you most likely need it everywhere, ie. because the select would > load too many options to be usable. > > We'd be very happy to see noConflict removed, and try to all rely on the > latest jQuery, rather than all try to load our own and deal with different > variables names for jQuery. Perhaps I should try this in a fork, even if > that means DAL will require extra steps for users not on that specific > Django fork, at least we'd figure out if removing noConflict had unseen > drawbacks. > > Best > -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/076f436b-1c02-49c7-b174-d400b3b1ec9e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vendoring Select2
Thanks for asking, my name is ∞, but you've known my as James Pic / YourLabs. Nice to speak with you again <3 I think it would make sense for a core dev to advocate against this change, because we'd be breaking BC before having enough information to know if this is going to have a generally more positive than negative impact, I wouldn't be able to tell without trying it myself with a community for a couple of years, and have the opportunity to try it out with a bunch of app/widget combinations, because the Django ecosystem (at least, the part I rely on and love) is so huge :D Best <3 -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op1_AjF8xMnbi7ym8Ceu45oDeiR8woaN-0K_4PZmzYT0CrQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
NUMERIC with unlimited precision not supported (#24920)
Currently, the DecimalField does not support unlimited precision numeric fields that are available in db backends. As in the ticket's description and comments https://code.djangoproject.com/ticket/24920 , there were two solution proposed: new field, or an update to DecimalField's behavior. I wanted to start contributing to Django, and thought that adding this feature could be a great way of getting to know Django's code. I was also thinking about a way of solving this - perhaps allowing DecimalField's max_digits and decimal_places to be None. If so, the field translates to an unlimited-precision NUMERIC field. Does it sound like a way to go? Best, Maciej -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6ec512c0-9a4d-4af3-a09d-76350a081b90%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vendoring Select2
On Tuesday, June 6, 2017 at 11:54:16 AM UTC+2, Johannes Hoppe wrote: > > I think we made some good progress in the regarding this issue. The > inclusion of select2 is at a stage where I wouldn't want to jump to a > different library. Especially considering that now one acted at this ticket > for seven years and it took me 2 years to work on the issue and it still > isn't merged. > Absolutely, changing select2 to something different is a nogo. -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b99de1b4-82e3-42f3-9bbd-6f2fb2594f1d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vendoring Select2
I was just thinking that changing the js widget would not require to rewrite the python code, barely the js widget support. I'm not trying to push it, just make sure we are taking the right facts into consideration, but I'm happy with select2 myself. -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op19phT4US3Un0uQP3_2nnqzM7msizV7LfzBEYfizNqYdtA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Makemigrations hooks for third-party apps?
Hi there I'm in the early stages of developing a third party app which makes heavy use of postgres extensions. The app provides an abstract model, so I won't have direct control of user's models or migrations. I'm having trouble getting it to generate sensible migrations for users. At present the migration process for users is going to be "copy and paste my migration file template into your project, and change the model names to match your app". As far as I can tell there is no way to generate migrations with anything custom. The operations I need to generate are: - CreateExtension() - RunSQL() - (to create slightly non-standard constraints) e.g. perhaps my model could supply a couple of methods: - Model.Meta.pre_creation_operations() - returns a list of operations to apply before the auto-detected model operations, e.g. creating extensions etc - Model.Meta.post_creation_operations() - the same but applied after the auto-detected operations, e.g. adding constraints/indexes. I'm envisaging that the operations returned from both methods would be deconstructed and copied into migration files when makemigrations is run. Has there been any discussion about this previously? I haven't found any. Thanks Craig de Stigter -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANv5zmWUsfEWpqUWh6He0mMgnt3Pen-oKq%3Dw0wghPzwwtgWWyA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Makemigrations hooks for third-party apps?
Hello Craig, There's unfortunately no way to hook into the migration auto-detector to specify additional operations to be added. What I suggest you do instead is dynamically inject operations in the plan that is about to be run by connecting a pre_migrate signal. When you detect CreateModel operations for subclasses of your AbtractModel you could insert operations to be performed before and after them. This is pattern we use internally to perform ContentType rename on RenameModel operations[0]. As for the makemigrations hooks I think it would require a lot of thought and efforts to get right. Right now the auto-detector is a black box that deals with dependencies and model state deltas resolution. In an ideal world model/fields objects would be able to generate the list of operations they require to move from state A to B as a public API and the auto-detector would simply iterate over the existing migrations state models and compare them against the current state of the project. Best, Simon [0] https://github.com/django/django/blob/525dc283a68c0d47f5eb2192cc4a20111d561ae0/django/contrib/contenttypes/management/__init__.py#L45-L84 Le mardi 6 juin 2017 16:45:05 UTC-4, Craig de Stigter a écrit : > > Hi there > > I'm in the early stages of developing a third party app which makes heavy > use of postgres extensions. The app provides an abstract model, so I won't > have direct control of user's models or migrations. I'm having trouble > getting it to generate sensible migrations for users. > > At present the migration process for users is going to be "copy and paste > my migration file template into your project, and change the model names to > match your app". As far as I can tell there is no way to generate > migrations with anything custom. > > The operations I need to generate are: > >- CreateExtension() >- RunSQL() - (to create slightly non-standard constraints) > > e.g. perhaps my model could supply a couple of methods: > >- Model.Meta.pre_creation_operations() - returns a list of operations >to apply before the auto-detected model operations, e.g. creating >extensions etc >- Model.Meta.post_creation_operations() - the same but applied after >the auto-detected operations, e.g. adding constraints/indexes. > > I'm envisaging that the operations returned from both methods would be > deconstructed and copied into migration files when makemigrations is run. > > Has there been any discussion about this previously? I haven't found any. > > Thanks > Craig de Stigter > -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a152a3df-5bac-4aaa-8103-fb85194e78c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
