Hey Developers! Some fields should be inside models.User e.g. image,
phone_number. Some developers don't want to extend the auth model. Yes i
know there are some ways to extends the auth model. But i think these
fields should come with models.User
--
You received this message because you are s
Hi,
I think template tag like in JSX is very useful, for example:
> card.html
{{ title }}
{{ component.children }}
> index.html
{% component './card.html' with title='Foo' %}
Bar
{% endcomponent %}
--
You received this message because you are subscribed to the Google Groups
"Django
We have just created a tag like that in our dynamicforms library. It's
called "extendtemplateblock". Feel free to use or copy, but it doesn't
look like it's going to be accepted in Django itself.
We tried to keep API similar to the "include" tag, so it should be easy
to use.
You can choose t
No they should not!
Django provides an easy way to extend (or replace) the built-in User model.
There are far too many fields people might want to add and it would be a
complete mess, if we would fulfill all of these requests.
Please refer to the docs
at
https://docs.djangoproject.com/en/3.1/t
I can see where you might think that, but I actually believe it should
go in the other direction - that the User model should be the absolute
_minimum_ of an entity.
1. The User model is retrieved with every authenticated request. The
more fields in the model, the more data is being handled un
Is there a link to the documentation or source code to the library you
created? And can i know why it is not accepted?
On Thursday, January 28, 2021 at 9:34:03 PM UTC+7 jure.er...@gmail.com
wrote:
> We have just created a tag like that in our dynamicforms library. It's
> called "extendtemplate
I did something like this in django-sniplates
https://sniplates.readthedocs.io/en/latest/tags.html#the-nested-widget-tag
--
C
On Thu, 28 Jan 2021, at 17:33, Aztec Rabbit wrote:
> Hi,
>
> I think template tag like in JSX is very useful, for example:
>
> > card.html
>
>
> {{ title }}
> {{
I second this; I would have moved to having auth.User be abstract, and force
projects to create their own _always_, except (a) it breaks a lot of history,
and (b) it breaks the "ready to go out of the box" nature.
It's a small cost at the start of your project, that avoids problems for a
sizabl
tl;dr: Introduce new field types to handle auto-incremented ID fields, change
the PostgreSQL backend to use the preferred syntax
--
One of the most common issues my company runs into on Django sites is that
models.AutoField defaults to a 32-bit integer (int32). 2^31-1 possible entries
is just
I recall a discussion some time about about adding a setting to control which
field to use for the default PK... seems there's some overlap here.
--
C
On Fri, 29 Jan 2021, at 12:42, Christophe Pettus wrote:
> tl;dr: Introduce new field types to handle auto-incremented ID fields, change
> the P
Better than that: 3.2 is the first step to changing the default. See
“customising the type of primary keys” in the release notes
(https://docs.djangoproject.com/en/dev/releases/3.2/).
“GENERATED BY DEFAULT AS IDENTITY” would be a nice improvement though.
Tom
> On 29 Jan 2021, at 01:58, Curtis
Source is here
(https://github.com/velis74/DynamicForms/blob/master/dynamicforms/templatetags/dynamicforms.py
- see at end of file), documentation will follow shortly as we near
1.0 release (right now it's pretty pathetic, but it is there at
readthedocs), but there are examples & unit tests includ
12 matches
Mail list logo
