Re: Feature request: Template tag like stateless component in JSX React

[Aztec Rabbit]

Curtis - This is nested block right? what i want is like tag include (can 
be called more than once) but with children.

Jure - I've read the documentation, can you give me a sample code? I am 
confused

Hmmm, but i think this feature is very useful (for card, container, 
wrapper, and anythink with different content) and each component can be 
included in other components, thats awesome. I think this feature should be 
in django core, but, yes, I understand.

On Friday, January 29, 2021 at 11:27:26 AM UTC+7 jure.er...@gmail.com wrote:

> 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 included showing
> most of the functionality.
>
> As far as I understood the feature wasn't perceived as something that
> would improve Django as a whole. There is that thing we need to be
> wary of - feature creep. Generally added features are preferred to be
> provided as third party libraries. Easier to maintain, easier to find
> that exact match you're looking for. Just look: Curtis also pointed
> you to his own version, a bit different that ours, but maybe it would
> suit you more?
>
> LP,
> Jure
>
> On Thu, Jan 28, 2021 at 6:52 PM Aztec Rabbit  wrote:
> >
> > 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 "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 to only pull one block from your extended template 
> ("block" parameter) or define any of the blocks in it using "block" nested 
> blocks.
> >>
> >> LP,
> >> Jure
> >>
> >> On 28. 01. 21 07:33, Aztec Rabbit wrote:
> >>
> >> 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 developers (Contributions to Django itself)" group.
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-develop...@googlegroups.com.
> >> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%40googlegroups.com
> .
> >
> > --
> > 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-develop...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/0cb2a1f6-9070-4875-90e2-eb6da241ea82n%40googlegroups.com
> .
>

-- 
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/109df365-750f-483d-8043-cf8c7c360c5en%40googlegroups.com.

Re: Feature request: Template tag like stateless component in JSX React

[Jure Erznožnik]

Aztec,

Just look in the dynamicforms/templates folder: all templates for input 
fields are built using this tag in its various forms. There's plenty of 
examples there. And yes, it's exactly what you asked for.


LP,
Jure

On 29. 01. 21 09:18, Aztec Rabbit wrote:
Curtis - This is nested block right? what i want is like tag 
include (can be called more than once) but with children.


Jure - I've read the documentation, can you give me a sample code? I 
am confused


Hmmm, but i think this feature is very useful (for card, container, 
wrapper, and anythink with different content) and each component can 
be included in other components, thats awesome. I think this feature 
should be in django core, but, yes, I understand.


On Friday, January 29, 2021 at 11:27:26 AM UTC+7 jure.er...@gmail.com 
wrote:


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 included showing
most of the functionality.

As far as I understood the feature wasn't perceived as something that
would improve Django as a whole. There is that thing we need to be
wary of - feature creep. Generally added features are preferred to be
provided as third party libraries. Easier to maintain, easier to find
that exact match you're looking for. Just look: Curtis also pointed
you to his own version, a bit different that ours, but maybe it would
suit you more?

LP,
Jure

On Thu, Jan 28, 2021 at 6:52 PM Aztec Rabbit 
wrote:
>
> 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 "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 to only pull one block from your extended
template ("block" parameter) or define any of the blocks in it
using "block" nested blocks.
>>
>> LP,
>> Jure
>>
>> On 28. 01. 21 07:33, Aztec Rabbit wrote:
>>
>> 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 developers (Contributions to Django itself)"
group.
>> To unsubscribe from this group and stop receiving emails from
it, send an email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%40googlegroups.com

.

>
> --
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/0cb2a1f6-9070-4875-90e2-eb6da241ea82n%40googlegroups.com

.


--
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/109df365-750f-483d-8043-cf8c7c360c5en%40googlegroups.com 
.


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

Re: Increase default integer keys to 64 bits

[charettes]

As Tom said Django 3.2 supports swapping the default primary key of models 
so the integer exhaustion part of your suggestion should be addressed

Regarding identity columns support there's already a ticket opened about it 
on Trac[0] where you might want to chime in.

Even #30511 if doesn't land in the near future it shouldn't be too hard to 
write a field class that uses "GENERATED BY DEFAULT AS IDENTITY" and point 
DEFAULT_AUTO_FIELD 
to it.

> At some point in the future, deprecate AutoField and AutoBigField. 

That would have a large impact on most Django project so unless we can find 
a really smooth upgrade path (e.g. for migrations) we should avoid doing 
that.

Cheers,
Simon

[0] https://code.djangoproject.com/ticket/30511

Le jeudi 28 janvier 2021 à 21:37:14 UTC-5, t...@tomforb.es a écrit :

> 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 Maloney  wrote:
>
> 
>
> 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 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 not that many anymore, and by the time the developers 
> realize this and need to move to a 64 bit integer key, it's too late to do 
> so conveniently, because expanding the field is very painful (in 
> PostgreSQL, at least).
>
> While models.AutoBigField exists, it's barely mentioned in examples, and 
> is often overlooked.
>
> Changing AutoField to 64 bits would result in all kinds of breakage; at 
> best, a lot of very unplanned and expensive migrations.
>
> My proposal is:
>
> 1. Create two new field types to represent auto-incrementing primary 
> keys.  I'd suggest IdentityField and SmallIdentityField for int64 and 
> int32, respectively.
>
> 2. Change all examples to use SerialField instead of AutoField.
>
> 3. As a side note, switch the PostgreSQL backend to use the standard 
> "GENERATED BY DEFAULT AS IDENTITY" syntax.  This became available in 
> PostgreSQL version 10, but the previous version (9.6) reaches EOL in 
> November 2021.
>
> 4. At some point in the future, deprecate AutoField and AutoBigField.
>
> This would result in new projects getting 64 bit primary keys by default.  
> I think that's a positive.  For small tables, the size difference hardly 
> matters; for big tables, we have saved a major foot-gun of either integer 
> exhaustion or a very expensive data migration problem.
>
> --
>
> Comments?
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> -- 
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/F4A50AB6-8CC1-4B6E-BD1B-B865F53A645A%40thebuild.com
> .
>
>
> -- 
> 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-develop...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/50ec245f-21a4-4ab9-ac51-55be2c969310%40www.fastmail.com
>  
> 
> .
>
>

-- 
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/c8ede818-2899-4056-a523-c2cb4488a7f7n%40googlegroups.com.

Re: Increase default integer keys to 64 bits

[Christophe Pettus]

> On Jan 29, 2021, at 07:40, charettes  wrote:
> 
> As Tom said Django 3.2 supports swapping the default primary key of models so 
> the integer exhaustion part of your suggestion should be addressed

That's not particularly related.  The issue isn't that there isn't any way to 
get a 64 bit key; there is, of course, using AutoBigField.  It's that the 
default, based on all of the documentation and code samples available, is to 
get a 32 bit key using AutoField, and that's a foot-gun with a long-delayed 
firing time.

The essence of the proposal is to make the public default for new projects 64 
bit keys; we're doing developers a disservice by making the default path 32 bit 
keys.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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/C0092F9E-71ED-463D-A0A8-4F00D8F00889%40thebuild.com.

Re: Increase default integer keys to 64 bits

[Adam Johnson]

64 bits is the default for new projects. See the 3.2 release notes:
https://docs.djangoproject.com/en/dev/releases/3.2/

On Fri, 29 Jan 2021 at 17:23, Christophe Pettus  wrote:

>
>
> > On Jan 29, 2021, at 07:40, charettes  wrote:
> >
> > As Tom said Django 3.2 supports swapping the default primary key of
> models so the integer exhaustion part of your suggestion should be addressed
>
> That's not particularly related.  The issue isn't that there isn't any way
> to get a 64 bit key; there is, of course, using AutoBigField.  It's that
> the default, based on all of the documentation and code samples available,
> is to get a 32 bit key using AutoField, and that's a foot-gun with a
> long-delayed firing time.
>
> The essence of the proposal is to make the public default for new projects
> 64 bit keys; we're doing developers a disservice by making the default path
> 32 bit keys.
>
> --
> -- Christophe Pettus
>x...@thebuild.com
>
> --
> 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/C0092F9E-71ED-463D-A0A8-4F00D8F00889%40thebuild.com
> .
>


-- 
Adam

-- 
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/CAMyDDM2t7PO20ARuJoVh5ZijzNWwicK_YwQOuKk6Ov0nW4yG%2Bg%40mail.gmail.com.

Another approach to ticket373:Add support for multiple-column primary keys

[Arisophy]

Hi, django developers.

Is anyone still interested in ticket373?

https://code.djangoproject.com/ticket/373

I'm gradually migrating legacy systems built with Ruby On Rails to Django.
So made an extended Model class that supports composite primary keys.

https://github.com/Arisophy/django-compositepk-model

It worked nicely with a small amount of code.

FYI

Arisophy

-- 
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/CA%2B2LtkDBof5M9aG-QjgeUTa9EbXRCtnNEOCqqt2aT%3DeexN4DGA%40mail.gmail.com.

Re: Feature request: Template tag like stateless component in JSX React

[Curtis Maloney]

On Fri, 29 Jan 2021, at 19:18, Aztec Rabbit wrote:
> Curtis - This is nested block right? what i want is like tag include (can be 
> called more than once) but with children.

Correct. And that's more or less what nested block does;

The difference from include is sniplates takes a template and rips the blocks 
from it, each of which then becomes a macro of sorts.

> 
> Jure - I've read the documentation, can you give me a sample code? I am 
> confused
> 
> Hmmm, but i think this feature is very useful (for card, container, wrapper, 
> and anythink with different content) and each component can be included in 
> other components, thats awesome. I think this feature should be in django 
> core, but, yes, I understand.

I agree that it could be quite useful.

I would suggest first making a sample implementation. This would involve taking 
`do_include` from django/templates/loader_tags.py and making a version that's 
an enclosing block tag (like block)... then exposing the nodelist in the 
context.

--
Curtis

-- 
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/a33eb617-6171-4a7d-826a-7ff6a9c1e077%40www.fastmail.com.