[django-cs] amqp

[Vladimír Macek]

Zdar,

potrebovali jste nekdy cist frontu amqp protokolem? Mame Django apku a mame 
vycitat frontu, kterou pro nas na druhe strane vytvoril nekdo, koho si 
nemuzeme vybrat. :-)


Ten protokol neznam, ale mam signaly, ze bude pry potreba na nasi strane 
bezet trvaly proces. Chtel bych ale co nejjednodussi setup, stacilo by mi 
frontu sosat jednou za nekolik minut z management commandu v cronu. Pokud 
to jde, co na to pouzit?


Diky,

V.


--
--
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google.

Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/3c047e1d-01b6-0992-5ac6-037a02fe5f9b%40sandbox.cz.

Re: [django-cs] emmett

[Honza Javorek]

Ještě doplním, že si myslím, že prostor pro konkurenci vytváří právě
nedostatek inovace. Webový server je vyřešený problém, takže roky nebylo
potřeba nic inovovat a nikomu to nechybělo. Přišlo async a mohlo to skončit
tím, že by Django dostalo konkurenci, ale nakonec to spíš vypadá, že se
Django velmi rychle async naučí a zůstane ve středu pozornosti.

Inovace teď probíhá spíš na frontendu a propojení frontendu s backendem -
https://jamstack.org/ vs https://hotwire.dev/ Nebo se řeší, jak ty věci
deploynout - co třeba dělá https://vercel.com/ se dost vymyká tomu, jak
chápeme klasický hosting. Prolíná se tam podle potřeby frontend s
backendem, statická stránka s dynamickou, předrenderovaná s on-demand
server-side renderovanou, atd.

Honza

On Thu, Feb 11, 2021 at 11:05 AM Honza Javorek  wrote:

> Ahoj,
>
> zkoušel jsi Pyramid? Já ne, ale přišlo mi to možná nejblíž tomu, co
> hledáš. Myslím si, že Django je skvělá výchozí volba pro web a když máš
> důvod potřebovat něco speciálního, už nyní existuje spousta jiných
> frameworků: https://docs.python-guide.org/scenarios/web/#frameworks A to
> tam ani není všechno kolem těch "nových" asynchronních přístupů, aiohttp,
> Sanic, atd.
>
> Jestli má existovat více těch výchozích voleb, to nevím. Přijde mi fajn,
> že nevymýšlíme stále znova kolo a komunita se soustředí kolem Djanga,
> doplňky jsou django-něco a kdyby frameworky soupeřily, přišlo by mi to asi
> jako škoda lidského potenciálu. Možná je to na úkor nějaké inovace, ale
> proč inovovat za každou cenu, když problém "webový framework" je už roky
> vyřešená věc? Jen kvůli tomu, že člověk X by preferoval nějaký přístup a
> člověk Y by si to chtěl psát zase trošku jinak? To mi přijde jako slabý
> důvod.
>
> V Ruby máš hromadu let stejnou situaci, vládne tam RoR. V JavaScriptu se
> po vynálezu Node.js vyrojily desítky frameworků (nutno podotknout, že ne
> webových serverových, tam to táhl Express, ale spíš frontendových
> renderovacích). Každý se tomu smál, ale když opadla ta inovační fáze,
> ustálilo se to na Reac/Vue a tak je to roky. Dnes se to propojuje s
> backendem a máš Next/Nuxt, kolem kterých se soustředí čím dál více lidí.
> Není to hegemonie jednoho, ale dvou. Stále je to však hegemonie. JS
> komunita je silná a velká, tak má energii udržovat dvě paralelní linie. V
> Ruby nebo Pythonu lidé soustředí své síly do jednoho projektu.
>
> Toť mých 50 haléřů.
>
> Honza
>
> On Thu, Feb 11, 2021 at 10:49 AM MirekZv  wrote:
>
>> Do písmene souhlasím s tím, co autor píše ve Foreword.
>>
>> Byl by ovšem zázrak, kdyby se povedlo vytvořit fullstack framework
>> konkurenční ke Djangu.
>>
>> Na druhou stranu něco jednou přijít musí. Protože jestli bude jediná
>> volba Django, ohrožuje to podle mě samu podstatu volby Pythonu jako jazyka
>> pro webové aplikace (ano, uznávám, trochu ze mě mluví včerejší frustrace
>> (jejíž součástí je i jiný dotaz zde v diskuzi), která není každodenní).
>>
>>
>> Foreword:
>>
>> 
>>
>> I really enjoyed writing code in Python, and after gaining some
>> confidence, I faced the second "big decision": which framework to use to
>> write my applications Looking at the Python scene, I (obviously) started
>> looking at *django*, the most famous one, but after a while I found I
>> didn't like it. It wasn't as user friendly as I had hoped. Then I found
>> *web2py*, and I loved it from the first line of the documentation book:
>> it was simple, full of features, and learning it was much quicker than
>> *django*.
>>
>> Nevertheless, after some years of using *web2py*, inspecting deeply the
>> code and logic, and contributing it, I started having a feeling. A need
>> grew in my mind while writing applications, to write things differently. I
>> found myself thinking "Why should I write this stuff in *this* way? It's
>> not cool or handy at all," and I had to face the problem that doing what I
>> wanted would involve completely re-designing the whole framework.
>>
>> With this nagging feeling in my mind, I started looking around and found
>> that a lot of the syntax and logic in *Flask* were the answer to what I
>> was looking for.
>> Unfortunately, at the same time, *Flask* had a lacked many of the
>> features I was used to having out of the box with *web2py*, and not even
>> using extensions would have been enough to cover it all.
>>
>> --
>> --
>> E-mailová skupina django-cs@googlegroups.com
>> Správa: http://groups.google.cz/group/django-cs
>> ---
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> „django-cs“ ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
>> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
>> Chcete-li tuto diskusi zobrazit na webu, navštivte
>> https://groups.google.com/d/msgid/django-cs/837e5398-60e1-4115-b0f8-800b2968dcdbn%40googlegroups.com
>> 
>> .

[django-cs] emmett

[MirekZv]

Do písmene souhlasím s tím, co autor píše ve Foreword.

Byl by ovšem zázrak, kdyby se povedlo vytvořit fullstack framework 
konkurenční ke Djangu.

Na druhou stranu něco jednou přijít musí. Protože jestli bude jediná volba 
Django, ohrožuje to podle mě samu podstatu volby Pythonu jako jazyka pro 
webové aplikace (ano, uznávám, trochu ze mě mluví včerejší frustrace (jejíž 
součástí je i jiný dotaz zde v diskuzi), která není každodenní).


Foreword:



I really enjoyed writing code in Python, and after gaining some confidence, 
I faced the second "big decision": which framework to use to write my 
applications Looking at the Python scene, I (obviously) started looking at 
*django*, the most famous one, but after a while I found I didn't like it. 
It wasn't as user friendly as I had hoped. Then I found *web2py*, and I 
loved it from the first line of the documentation book: it was simple, full 
of features, and learning it was much quicker than *django*.

Nevertheless, after some years of using *web2py*, inspecting deeply the 
code and logic, and contributing it, I started having a feeling. A need 
grew in my mind while writing applications, to write things differently. I 
found myself thinking "Why should I write this stuff in *this* way? It's 
not cool or handy at all," and I had to face the problem that doing what I 
wanted would involve completely re-designing the whole framework.

With this nagging feeling in my mind, I started looking around and found 
that a lot of the syntax and logic in *Flask* were the answer to what I was 
looking for.
Unfortunately, at the same time, *Flask* had a lacked many of the features 
I was used to having out of the box with *web2py*, and not even using 
extensions would have been enough to cover it all.

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/837e5398-60e1-4115-b0f8-800b2968dcdbn%40googlegroups.com.

Re: [django-cs] Dědičnost Django admin šablon

[MirekZv]

Ještě, kdyby to někdo taky potřeboval implementovat (přestože jsme se 
dozvěděli, že k tomu Django není určeno) přidám jedno vhodné řešení:
*(3) použít django-baton.*

Dne čtvrtek 11. února 2021 v 10:38:05 UTC+1 uživatel MirekZv napsal:

> PS: weppy ~ emmett ?
>
> Dne středa 10. února 2021 v 19:40:26 UTC+1 uživatel MirekZv napsal:
>
>> Abych pořád jen nefňukal, že Weppy je polomrtvé a Cheetah opovrhovaný, 
>> ale abych skončil trochu konstruktivně:
>> V soutěži minimalizace zla se umístila tato řešení:
>>
>> *(1) menší flexibilita, menší náchylnost na problémy při upgradu Djanga*
>> ve vlastní aplikaci: admin/index.html
>> ```
>> {% extends "admin/index.html" %}
>> {% block content %}
>> 
>> {% include 'admin/before_app_list.html' %}{#mz#}
>> {% include "admin/app_list.html" with app_list=app_list 
>> show_changelinks=True %}
>> 
>> {% endblock %}
>> ```
>> ve vlastní aplikaci: admin/nav_sidebar.html
>> {% load i18n %}
>> > aria-label="{% translate 'Toggle navigation' %}">
>> 
>> {% include 'admin/before_app_list.html' %}{#mz#}
>> {% include 'admin/app_list.html' with app_list=available_apps 
>> show_changelinks=False %}
>> 
>>
>> *(2) větší flexibilita, větší náchylnost na problémy při upgradu Djanga*
>> ve vlastní aplikaci: admin/app_list.html
>> nedědit/nepřetěžovat, ale upravit podle potřeby
>>
>> Dne středa 10. února 2021 v 18:45:24 UTC+1 uživatel MirekZv napsal:
>>
>>> PS:
>>> Potíž je, že tím předchozím postupem nejen nelze i18n/trans, ale nelze 
>>> ani vsadit do html jakýkoli string, který bych si připravil předem.
>>> Leda můžu v template/base.py místo `raise self.error(token, '%r must be 
>>> the first tag in the template.' % node,)` dát `pass`,
>>> aby Django neprovádělo své přechytralé kontraproduktivní kontroly.
>>> Jenže to už je zase patchování Djanga.
>>> Ach jo, zlatej Cheetah.
>>>
>>> Dne středa 10. února 2021 v 18:15:18 UTC+1 uživatel MirekZv napsal:
>>>
 Mezitím mám jedno řešení.
 Dokumentace Djanga je "doslovně" pravdivá: If you use {% extends %} in 
 a template, it must be the first template tag in that template.
 To skutečně znamená, že extends může předcházet (nikoli následovat) 
 html kód.
 To by mi celkem vyhovovalo. Jediné, co mě štve je, že nemůžu použít 
 nejen {% include ... %}, ale ani i18n/trans :(
 Příklad viz obrázky.[image: rap1.png][image: rap2.png]

 Dne středa 10. února 2021 v 18:10:44 UTC+1 uživatel MirekZv napsal:

> Možná jsem Tě přesně nepochopil.
> Já umím extendovat admin/app_list.html, jenže je mi to k..h..u, 
> protože ta v sobě nemá žádný {% block  %} - takže proč ji extendovat?
> Ale možná jsi myslel includovat. To by dávalo smysl.
>
> A pak taky nevím, jestli to, co píšeš, řeší, aby moje přidané položky 
> byly všude: 1) Na hlavní stránce admina, 2) Na stránkách aplikací, 3) V 
> sidebar menu během editace.
>
>
>
> Dne středa 10. února 2021 v 17:29:32 UTC+1 uživatel honza...@gmail.com 
> napsal:
>
>> app_list.html neni urcena k pretezovani, proto na to neni zarizena. 
>> Nejjednodussi cesta je:
>>
>> nastav si custom sablonu na index_template (0). Ve sablone (ktera se 
>> nebude jmenovat admin/index.html) extenduj index.html a prepis {% block 
>> content %} kde misto admin/app_list.html naimportujes jinou sablonu, 
>> ktera 
>> byde extendovat admin/app_list.html
>>
>>
>> 0 - 
>> https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite.index_template
>>
>> Honza Král
>> E-Mail: honza...@gmail.com
>> Phone:  +420 606 678585 <+420%20606%20678%20585>
>>
>>
>> On Wed, Feb 10, 2021 at 5:22 PM MirekZv  wrote:
>>
>>> Django mi zas dává do těla.
>>>
>>> Snažím se přidat menu do Django admina.
>>> Ačkoli lze najít plno návodů, zdá se mi, že všechno jsou hrozné 
>>> hacky a přestávají fungovat s nejbližší novější verzí Djanga.
>>>
>>> Takže by se mi zdálo, že nejbezpečnější by bylo,
>>> přidat si svoje vlastní menu položky před to, co generuje šablona 
>>> admin/app_list.html.
>>>
>>> Ta totiž generuje seznam aplikací (skupiny menu) a modelů v nich 
>>> (položky skupin).
>>> Tak bych si tam předhodil jednu skupinu se svými odkazy.
>>> A fungovalo by to ve všech scénářích, kde se to volá, ať už je to 
>>> hlavní obsah stránky, nebo to postranní menu (bavím se o Dj 3.1).
>>>
>>> JENŽE:
>>>
>>> Když předřadím svoji aplikaci před django.contrib.admin, udělám v ní 
>>> také admin/app_list.html, tak běží ten můj přednostně a pokud je v něm 
>>> {% 
>>> extends 'admin/app_list.html' %}, tak volá následně tu originál 
>>> djangovou a 
>>> nahrazuje v ní bloky , které předefinuji.
>>>
>>> To funguje a je to snad i popsáno v dokumentaci.
>>> Jenže v té originál nejsou žádné bloky. Jsou líní to aspoň jedním 
>>> blokem owrapovat,.aby šlo předchozí p

Re: [django-cs] Dědičnost Django admin šablon

[MirekZv]

PS: weppy ~ emmett ?

Dne středa 10. února 2021 v 19:40:26 UTC+1 uživatel MirekZv napsal:

> Abych pořád jen nefňukal, že Weppy je polomrtvé a Cheetah opovrhovaný, ale 
> abych skončil trochu konstruktivně:
> V soutěži minimalizace zla se umístila tato řešení:
>
> *(1) menší flexibilita, menší náchylnost na problémy při upgradu Djanga*
> ve vlastní aplikaci: admin/index.html
> ```
> {% extends "admin/index.html" %}
> {% block content %}
> 
> {% include 'admin/before_app_list.html' %}{#mz#}
> {% include "admin/app_list.html" with app_list=app_list 
> show_changelinks=True %}
> 
> {% endblock %}
> ```
> ve vlastní aplikaci: admin/nav_sidebar.html
> {% load i18n %}
>  aria-label="{% translate 'Toggle navigation' %}">
> 
> {% include 'admin/before_app_list.html' %}{#mz#}
> {% include 'admin/app_list.html' with app_list=available_apps 
> show_changelinks=False %}
> 
>
> *(2) větší flexibilita, větší náchylnost na problémy při upgradu Djanga*
> ve vlastní aplikaci: admin/app_list.html
> nedědit/nepřetěžovat, ale upravit podle potřeby
>
> Dne středa 10. února 2021 v 18:45:24 UTC+1 uživatel MirekZv napsal:
>
>> PS:
>> Potíž je, že tím předchozím postupem nejen nelze i18n/trans, ale nelze 
>> ani vsadit do html jakýkoli string, který bych si připravil předem.
>> Leda můžu v template/base.py místo `raise self.error(token, '%r must be 
>> the first tag in the template.' % node,)` dát `pass`,
>> aby Django neprovádělo své přechytralé kontraproduktivní kontroly.
>> Jenže to už je zase patchování Djanga.
>> Ach jo, zlatej Cheetah.
>>
>> Dne středa 10. února 2021 v 18:15:18 UTC+1 uživatel MirekZv napsal:
>>
>>> Mezitím mám jedno řešení.
>>> Dokumentace Djanga je "doslovně" pravdivá: If you use {% extends %} in a 
>>> template, it must be the first template tag in that template.
>>> To skutečně znamená, že extends může předcházet (nikoli následovat) html 
>>> kód.
>>> To by mi celkem vyhovovalo. Jediné, co mě štve je, že nemůžu použít 
>>> nejen {% include ... %}, ale ani i18n/trans :(
>>> Příklad viz obrázky.[image: rap1.png][image: rap2.png]
>>>
>>> Dne středa 10. února 2021 v 18:10:44 UTC+1 uživatel MirekZv napsal:
>>>
 Možná jsem Tě přesně nepochopil.
 Já umím extendovat admin/app_list.html, jenže je mi to k..h..u, protože 
 ta v sobě nemá žádný {% block  %} - takže proč ji extendovat?
 Ale možná jsi myslel includovat. To by dávalo smysl.

 A pak taky nevím, jestli to, co píšeš, řeší, aby moje přidané položky 
 byly všude: 1) Na hlavní stránce admina, 2) Na stránkách aplikací, 3) V 
 sidebar menu během editace.



 Dne středa 10. února 2021 v 17:29:32 UTC+1 uživatel honza...@gmail.com 
 napsal:

> app_list.html neni urcena k pretezovani, proto na to neni zarizena. 
> Nejjednodussi cesta je:
>
> nastav si custom sablonu na index_template (0). Ve sablone (ktera se 
> nebude jmenovat admin/index.html) extenduj index.html a prepis {% block 
> content %} kde misto admin/app_list.html naimportujes jinou sablonu, 
> ktera 
> byde extendovat admin/app_list.html
>
>
> 0 - 
> https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite.index_template
>
> Honza Král
> E-Mail: honza...@gmail.com
> Phone:  +420 606 678585 <+420%20606%20678%20585>
>
>
> On Wed, Feb 10, 2021 at 5:22 PM MirekZv  wrote:
>
>> Django mi zas dává do těla.
>>
>> Snažím se přidat menu do Django admina.
>> Ačkoli lze najít plno návodů, zdá se mi, že všechno jsou hrozné hacky 
>> a přestávají fungovat s nejbližší novější verzí Djanga.
>>
>> Takže by se mi zdálo, že nejbezpečnější by bylo,
>> přidat si svoje vlastní menu položky před to, co generuje šablona 
>> admin/app_list.html.
>>
>> Ta totiž generuje seznam aplikací (skupiny menu) a modelů v nich 
>> (položky skupin).
>> Tak bych si tam předhodil jednu skupinu se svými odkazy.
>> A fungovalo by to ve všech scénářích, kde se to volá, ať už je to 
>> hlavní obsah stránky, nebo to postranní menu (bavím se o Dj 3.1).
>>
>> JENŽE:
>>
>> Když předřadím svoji aplikaci před django.contrib.admin, udělám v ní 
>> také admin/app_list.html, tak běží ten můj přednostně a pokud je v něm 
>> {% 
>> extends 'admin/app_list.html' %}, tak volá následně tu originál 
>> djangovou a 
>> nahrazuje v ní bloky , které předefinuji.
>>
>> To funguje a je to snad i popsáno v dokumentaci.
>> Jenže v té originál nejsou žádné bloky. Jsou líní to aspoň jedním 
>> blokem owrapovat,.aby šlo předchozí použít.
>>
>> Ale když místo toho dám {% include 'admin/app_list.html' %},
>> tak nejde na tu djangovou originální, ale volá dokola stále tu moji 
>> (nekonečná rekurze).
>>
>> Je nějaká možnost jak mít svoji templatu pod jménem app_list.html a 
>> volat z ní něco svého + ten originální obsah?
>>
>> Aniž bych musel patchova