Help with implementing calculated fields (#28822)
Hi, a while back there has been a discussion about calculated model fields: https://groups.google.com/g/django-developers/c/ADSuUUuZp3Q/m/5o02Lp_jCwAJ The main benefit would be that these would be available in cases where annotations are currently not available, e.g. related queries or admin lists (see #14336). Note that the topic of fields that have both a DB and python implementation was discussed and the consensus was that the python equivalents could be added by a separate library, if required. So I am only talking about the database part here. The linked discussion was mainly about *what* is desired, not *how* it could be done. I also noticed that the fellows did not participate in that discussion. I would like to have a shot at this topic. So I am interested in: - Do you think this is even possible/worth the effort? - How could this be implemented and what would be potential challenges? - Is it possible to implement this in a third party library or does it require changes to django itself? I would probably start with a non-editable, non-concrete model field (similar to GenericForeignKey or ForeignObjRel). But I have no clue yet how to integrate that with QuerySet/Query. thanks tobias -- 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/caa86f1c-7838-20fb-5934-448a804299d5%40posteo.de.
Separate context and rendering in forms
I've been working on packages that generate HTML based on Django forms for
a while. I find myself duplicating certain parts of Django code, because
there is no clear separation of the context (as in template context) that
is being generated, and the HTML output. A small example of this is the
code that renders the HTML for a label.
https://github.com/django/django/blob/76c0b32f826469320c59709d31e2f2126dd7c505/django/forms/boundfield.py#L133
This code takes arguments for and then generates contents (based on actual
contents and a suffix) and attrs and then generates HTML. It doe snot
always generate a label tag, which I find weird but is besides the point
of this issue.
My suggestion would be to split these kind of functions into a context
generator
{{{
def get_label_tag_context(self, contents=None, attrs=None,
label_suffix=None):
...
return {
"contents": ...,
"suffix": ...,
"attrs": ...,
}
}}}
And the actual rendering of the tag
{{{
def get_label_tag(self, contents=None, attrs=None, label_suffix=None):
context = self.get_label_tag_context(contents=contents, attrs=attrs,
label_suffix=label_suffix)
attrs = flatatt(context["attrs"]) if context["attrs"] else ""
return format_html('{}', attrs, context["contents"])
}}}
Now, if I want to write my own label renderer, I can get the exact same
context that Django uses.
For widgets, I would like to see the same solution. The context for a
widget is now part of the rendering process, and contains code that cannot
be rached unless you use Django rendering. If you want to apply different
rendering to a widget on a per widget basis, you have to duplicate code or
hack the generated HTML.
https://github.com/django/django/blob/76c0b32f826469320c59709d31e2f2126dd7c505/django/forms/boundfield.py#L80
Here, a split in generating context and rendering the context would also
help third party form packages to work with the same data Django has.
I'm creating this ticket to get feedback on the idea, and to see if a PR
separating context and rendering in the forms section of Django would be
welcome. I'd be willing to work on this.
P.S. This is a copy/paste from https://code.djangoproject.com/ticket/32541,
I got the suggestion to check here.
--
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/73e586b8-4d66-4a43-b63a-2c8a5edf1e6cn%40googlegroups.com.
Re: Help with implementing calculated fields (#28822)
Hi Tobias. I've done a bit of stuff on this, and found there were actually limited changes that need to be made to django to got this to work. https://schinckel.net/2020/09/15/django-properties-from-expressions%2C-or-computedfield-part-2/ I haven't touched it much since then (although I'm keen to revisit it, actually), but it's actually possible that we can do it without any changes to Django. https://github.com/schinckel/django-shared-property Matt. On Sunday, March 14, 2021 at 11:46:15 PM UTC+10:30 Tobias Bengfort wrote: > Hi, > > a while back there has been a discussion about calculated model fields: > > https://groups.google.com/g/django-developers/c/ADSuUUuZp3Q/m/5o02Lp_jCwAJ > > The main benefit would be that these would be available in cases where > annotations are currently not available, e.g. related queries or admin > lists (see #14336). > > Note that the topic of fields that have both a DB and python > implementation was discussed and the consensus was that the python > equivalents could be added by a separate library, if required. So I am > only talking about the database part here. > > The linked discussion was mainly about *what* is desired, not *how* it > could be done. I also noticed that the fellows did not participate in > that discussion. > > I would like to have a shot at this topic. So I am interested in: > > - Do you think this is even possible/worth the effort? > - How could this be implemented and what would be potential challenges? > - Is it possible to implement this in a third party library or does it > require changes to django itself? > > I would probably start with a non-editable, non-concrete model field > (similar to GenericForeignKey or ForeignObjRel). But I have no clue yet > how to integrate that with QuerySet/Query. > > thanks > tobias > -- 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/8d325f4e-9c20-4268-9c46-6f682911ac5dn%40googlegroups.com.
