Re: Developing an SPA version of Django admin

[quest...@gmail.com]

I have project similar to Django admin, implemented with Knockout.js:

https://github.com/Dmitri-Sintsov/django-jinja-knockout

Today probably it would be preferable to use "vanilla ES6" or Svelte, 
because these options would minimize the dependence on third party 
libraries and bundlers, it would produce the cleanest package.

On Saturday, October 16, 2021 at 9:55:02 AM UTC+3 vasant...@gmail.com wrote:

> Hi Warren,
>
> An SPA sound interesting but should be based on React or other SPA 
> frameworks? While I’ve not looked into it very much Webcomponents are part 
> of the Spec since 2012. Vanilla JS can be leveraged to create the admin and 
> the project developers can choose to extend it with the framework of their 
> choice.
>
> I’m relatively a inexperienced  developer but I’d very interested in 
> contributing with a project like this.
>
> On Friday, 15 October 2021 at 18:54:26 UTC+2 warren@gmail.com wrote:
>
>> Hi everyone,
>>
>> I've been contemplating the development of an SPA version of admin either 
>> in Angular, React, Vue or even Flutter... preferably in Angular due to it's 
>> data binding approach.
>>
>> The idea is to serve the SPA from Django, dynamically generating it so 
>> that the great model based apps that one can create with the current admin 
>> site can be dynamically generated in a similar way, but as an SPA.  Why 
>> SPA.. just to enable a better, more powerful user experience without the 
>> round trips and page reloads.   
>>
>> Hoping it will in the same way form a RAD tool for SPA development with a 
>> Django back-end.
>>
>> If we get really smart, we may be able to make it theme-able.
>>
>> I have messaged the django dev group as I have had a look at the work 
>> that may be involved and I believe that if we we're to succeed in making 
>> this a standard addition to django as an admin alternative, we make have to 
>> accommodate it in the code a bit... there may be a bit of refactoring of 
>> the admin code. 
>>
>> Just wondering if anyone would be up for joining me in creating something 
>> like this?... or if you know of an existing project trying to do this?
>>
>> Thanks
>> Warren
>>
>>

-- 
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/f3d1c6c8-f1a7-4470-add7-e7937314c8dcn%40googlegroups.com.

Re: Proposed change in ORM model save logic

[Barry Johnson]

On Friday, October 15, 2021 at 12:39:52 PM UTC-5 pyt...@ian.feete.org wrote:

> You set out a good case, it's much easier to understand the "why" here 
than in the original ticket.

Yes.  It was hard to compress the matter down small enough to reasonably 
fit in a Trac entry, so skipped the vast majority of the rationale. Sorry 
that it took that much writing to make the case, but had to set the 
groundwork first.

On later consideration, the two most compelling points seem to be:
* Internal machinations of Django shouldn't change object relationships 
that the application-level code has set
* save() shouldn't have different effects (-sometimes- uncaching the 
reference) if the parent object is inserted versus updated

> I'd avoid the extra optimisation of accessing __dict__ directly though - 
if __set__ gains extra functionality, I'd prefer not to accidentally miss 
it here.

Agreed!  Not being sure just how widely spread accessing the underlying 
__dict__ is throughout the code, I wasn't sure which way to go.  Although 
it may be a -measurable- improvement in performance, it's miniscule.

baj

-- 
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/14d1a470-4026-4f06-bfde-265bc7d8a667n%40googlegroups.com.

Re: Developing an SPA version of Django admin

[Christian González]

Hello,

my 2 cents here. I've searched for years to find "the right" frontend 
for Django. Tried, React, Angular, Vue, Svelte, and many others, even 
developed GDAPS, a Django plugin system with flexible optional frontend 
integration optionally (Vue only ATM - but the frontend integration is 
stuck, read below why), and almost got crazy. I ended up in forgetting 
all the frontend frameworks altogether as they all are completely 
un-pythonic and un-djangoish, get into your way and force you to 
re-write everything you already had working.You have to write all the 
logic of views again in your frontend of choice, and well, do the 
validation *again* in the backend. So everything gets more complex, with 
the "benefit" of getting a few milliseconds and fewer round trips. It's 
just "cooler".


Oh, and yes, forget Django's template language. In the best case the 
frontend barks at it and you have to define own variable delimiters 
(Vue) if mixed into the templates, or it isn't even possible to use it 
without getting into big trouble. You'll end up defining a separate 
project, and using REST or GraphQL for communication with Django. 
Additionally you have to throw webpack, rollup, parcel, or any other 
bundler of your choice into the mix. Which then won't like your 
non-admin-frontend.


What I ended with, and that has none of those disadvantages, is *HTMX*. 
Keep your views, keep your templates, keep your validations/validators, 
render everything serverside, just salt the html templates with some 
HTMX attrs where needed. Works almost perfectly, and even could be added 
incrementally.


If I would develop a better Django admin, I'd go for HTMX. (and I tried 
Sockpuppet, Unicorn, and many others too.)

If it was for me, I even would add a neat HTMX integration to Django core.

Cheers, Christian


Am 15.10.21 um 08:52 schrieb Warren Havemann:

Hi everyone,

I've been contemplating the development of an SPA version of admin 
either in Angular, React, Vue or even Flutter... preferably in Angular 
due to it's data binding approach.


The idea is to serve the SPA from Django, dynamically generating it so 
that the great model based apps that one can create with the current 
admin site can be dynamically generated in a similar way, but as an 
SPA.  Why SPA.. just to enable a better, more powerful user experience 
without the round trips and page reloads.


Hoping it will in the same way form a RAD tool for SPA development 
with a Django back-end.


If we get really smart, we may be able to make it theme-able.

I have messaged the django dev group as I have had a look at the work 
that may be involved and I believe that if we we're to succeed in 
making this a standard addition to django as an admin alternative, we 
make have to accommodate it in the code a bit... there may be a bit of 
refactoring of the admin code.


Just wondering if anyone would be up for joining me in creating 
something like this?... or if you know of an existing project trying 
to do this?


Thanks
Warren

--
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/c29b745c-21d5-46c8-ab51-312b1a73114dn%40googlegroups.com 
.


--
Dr. Christian González
https://nerdocs.at

--
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/e11b61db-144a-30e3-9a21-b76667a1b921%40nerdocs.at.

Re: Redirect type selection in django.contrib.redirects

[Niccolò Mineo]

I just opened a ticket with the related 
PR: https://code.djangoproject.com/ticket/33206

Il giorno mercoledì 6 ottobre 2021 alle 23:55:51 UTC+2 Adam Johnson ha 
scritto:

> This seems like a reasonable addition to me.
>
> On Fri, 24 Sept 2021 at 08:08, Niccolò Mineo  wrote:
>
>> Hi. The marketing guys at my workplace asked for the ability to customise 
>> the redirect type  (301, 302) when creating redirects in the admin and I 
>> shipped this change a while ago. I believe this could be a nice addition to 
>> Django itself, too. What do you think?
>>
>>
>>
>>
>> -- 
>> 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/0ccdfe91-c97a-4363-9226-518310ceca04n%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/55ac8328-e7b7-42aa-9fc4-abfe20aeb365n%40googlegroups.com.

Re: Developing an SPA version of Django admin

[Asif Saif Uddin]

Hi guys,
the django admin still need to dogfood many new django features. we can 
start with that. for reference you can check django-admin2.

thanks,
Asif

On Sunday, October 17, 2021 at 2:36:16 AM UTC+6 Christian González wrote:

> Hello,
>
> my 2 cents here. I've searched for years to find "the right" frontend for 
> Django. Tried, React, Angular, Vue, Svelte, and many others, even developed 
> GDAPS, a Django plugin system with flexible optional frontend integration 
> optionally (Vue only ATM - but the frontend integration is stuck, read 
> below why), and almost got crazy. I ended up in forgetting all the frontend 
> frameworks altogether as they all are completely un-pythonic and 
> un-djangoish, get into your way and force you to re-write everything you 
> already had working.You have to write all the logic of views again in your 
> frontend of choice, and well, do the validation *again* in the backend. So 
> everything gets more complex, with the "benefit" of getting a few 
> milliseconds and fewer round trips. It's just "cooler". 
>
> Oh, and yes, forget Django's template language. In the best case the 
> frontend barks at it and you have to define own variable delimiters (Vue) 
> if mixed into the templates, or it isn't even possible to use it without 
> getting into big trouble. You'll end up defining a separate project, and 
> using REST or GraphQL for communication with Django. Additionally you have 
> to throw webpack, rollup, parcel, or any other bundler of your choice into 
> the mix. Which then won't like your non-admin-frontend.
>
> What I ended with, and that has none of those disadvantages, is *HTMX*. 
> Keep your views, keep your templates, keep your validations/validators, 
> render everything serverside, just salt the html templates with some HTMX 
> attrs where needed. Works almost perfectly, and even could be added 
> incrementally.
>
> If I would develop a better Django admin, I'd go for HTMX. (and I tried 
> Sockpuppet, Unicorn, and many others too.)
> If it was for me, I even would add a neat HTMX integration to Django core.
>
> Cheers, Christian
>
>
> Am 15.10.21 um 08:52 schrieb Warren Havemann:
>
> Hi everyone,
>
> I've been contemplating the development of an SPA version of admin either 
> in Angular, React, Vue or even Flutter... preferably in Angular due to it's 
> data binding approach.
>
> The idea is to serve the SPA from Django, dynamically generating it so 
> that the great model based apps that one can create with the current admin 
> site can be dynamically generated in a similar way, but as an SPA.  Why 
> SPA.. just to enable a better, more powerful user experience without the 
> round trips and page reloads.   
>
> Hoping it will in the same way form a RAD tool for SPA development with a 
> Django back-end.
>
> If we get really smart, we may be able to make it theme-able.
>
> I have messaged the django dev group as I have had a look at the work that 
> may be involved and I believe that if we we're to succeed in making this a 
> standard addition to django as an admin alternative, we make have to 
> accommodate it in the code a bit... there may be a bit of refactoring of 
> the admin code. 
>
> Just wondering if anyone would be up for joining me in creating something 
> like this?... or if you know of an existing project trying to do this?
>
> Thanks
> Warren
>
> -- 
> 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/c29b745c-21d5-46c8-ab51-312b1a73114dn%40googlegroups.com
>  
> 
> .
>
> -- 
> Dr. Christian Gonzálezhttps://nerdocs.at
>
>

-- 
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/04da2824-b615-48fb-9ae5-562e3d9c5125n%40googlegroups.com.