Re: [django-cs] emmett

[MirekZv]

Myslím, že silný jazyk jako Python by 2 linie mohl utáhnout.
Jako je v Javascriptu dneska právě na výběr ten React, Vue, Angular (jestli 
už mají něco fullstack serverového, nevím - divil bych se).
Dne pátek 12. února 2021 v 16:42:20 UTC+1 uživatel Honza Javorek napsal:

> 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 djan...@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+...@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
>>  
>> 
>> .
>>
>

-- 
-- 
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/9650d14f-e597-4e6a-9762-d9dbc9577b32n%40googl

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

[MirekZv]

@jan:
Díky za tip. Jasně, jen design, co je navíc, je od zlého, jak praví písmo 
svaté.
Asi už to nebude na pořadu dne, protože už snad ve 3.2 mají být v adminu 
Themes.
Dělal jsem na projektu, kde tam přidali něco složitějšího (teď mi vypadlo 
jméno), možná to v jisté fázi bylo dobré, ale autor to ani neopensourcoval, 
takže za 3 roky začaly problémy růst geometrickou řadou.
Bohužel si zákazník navykl na vzhled.
Takže když se z toho vycouvávalo, nepopulární, ale nutný krok, našli jsme 
django-baton. Ten dělá malinko víc než themes, ale opravdu malinko (zejména 
to konfigurovatelné menu), snažíme se to udržovat stylem proměnné v 
settings BATON=True/False a občas zkontrolovat, že to jede i pod plain 
nativním adminem. Tak snad nás to moc nevypráská.
Dne pátek 12. února 2021 v 22:54:42 UTC+1 uživatel jan.be...@gmail.com 
napsal:

> Ahoj,
>
> s těmi mantinely se to má tak, že tam kde člověk narazí na limity rozumné 
> customizace adminu, tak snadno přihodí vlastní view, template, formuláře, 
> atp. A ten vlastní interface si dopíše do adminu. Což dává smysl, pokud se 
> aspoň kus či většina adminu využije.
>
> Na customizaci vzhledu se mi osvědčil 
> https://github.com/fabiocaccamo/django-admin-interface který nedělá moc 
> velkou magii a spíš to přestyluje jen barevně.
>
> Honza
>
> pá 12. 2. 2021 v 21:52 odesílatel Pavel Cisar  napsal:
>
>> Ahoj,
>> nemuzu si pomoct, ale pripada mi, ze jde spis o nepochopeni podstaty 
>> django admina. Je to skvely nastroj pro nahlizeni do struktury dat a dava 
>> moznost urcitych modifikaci, ale primarne pro vnitrni potrebu.
>> V dokumentaci v podstate pisou, ze pokud chce clovek neco vic a nevejde 
>> se danych mantinelu, je nacase si napsat vlastni interface a s tim musim 
>> rozhodne souhlasit.
>> Pokud clovek vyslovene nechce psat neco vlastniho a rad by zmenit vzhled 
>> nebo mel vice moznosti, tak bych ho odkazal na projekty jako:
>> https://github.com/django-admin-tools/django-admin-tools
>> https://djangosuit.com/
>>
>>
>>
>> pá 12. 2. 2021 v 16:42 odesílatel MirekZv  napsal:
>>
>>> Honza zatím mlčí, odpovím si sám.
>>> Samozřejmě, že admin/app_list.html se volá na 2 místech.
>>> Jedno místo popisuje Honza - to je "vhodné k přetěžování".
>>> Podruhé v nav_sidebar.html, tam opět žádný blok není, neboli další 
>>> šablona, která "není určena k přetěžování".
>>> Ostatně, kdykoli když slyším slovo "přetěžování", tak už je mi jasné, že 
>>> je něco špatně.
>>> Takže závěr: Django je jako vždy geniální, já jsem zase ten blbec, co ho 
>>> chce použít k něčemu, k čemu není určeno.
>>> (sorry za tu mírnou jedovatost, já to tak nemyslím, jen toho mám trochu 
>>> plné zuby)
>>> 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
>>> Ph

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

[MirekZv]

@cisar:
Já tomu rozumím a snad to i chápu jako přínosné.
Co by mi ale připadalo jako správné, dát to formou důrazného doporučení.
Použil sis to pro něco jiného než pro staff, tak se nediv, pokud jsi 
nedomyslel všechny konsekvence, byla to tvoje úvaha.
Ale natvrdo to zablokovat jen pro is_staff, znemožnit to samoúčelnou 
(jasně: oponent řekne že účelnou) validací, která není proto, aby se 
software nezhroutil nebo nedostal do nekonzistentního stavu, ale jen proto, 
aby vývojář, který má u zákazníka trochu jinou konfiguraci uživatelů než v 
redakci nějakého žurnálu, to nemohl použít, i když by to perfektně chodilo, 
mi přijde jako zvěrstvo.
Koncipovat menu tak, aby se nemohlo měnit (spíš tedy rozšiřovat) mi přijde 
jako zvěrstvo. [ono to tak v reálu snad není, snad to bylo jen v této 
diskuzi malinko neštastně řečeno]
Kromě toho, že by i sám vývojář mohl mít právo myslet, tak určitě ten 
zákazník, který do toho vleze, řekne: Prosím Tě, je to paráda, jen mi ještě 
do menu přidej tyto 2 volby, když už tady to menu je. A vy mu jako budete 
říkat (a budete za debila), že sice tomu tak úplně nerozumíte proč, ale 
určitě by to nebylo správné, protože chytří lidi rozhodli, že doplňovat 
další položky do menu je blbost?

Dne pátek 12. února 2021 v 21:52:54 UTC+1 uživatel cisar...@gmail.com 
napsal:

> Ahoj,
> nemuzu si pomoct, ale pripada mi, ze jde spis o nepochopeni podstaty 
> django admina. Je to skvely nastroj pro nahlizeni do struktury dat a dava 
> moznost urcitych modifikaci, ale primarne pro vnitrni potrebu.
> V dokumentaci v podstate pisou, ze pokud chce clovek neco vic a nevejde se 
> danych mantinelu, je nacase si napsat vlastni interface a s tim musim 
> rozhodne souhlasit.
> Pokud clovek vyslovene nechce psat neco vlastniho a rad by zmenit vzhled 
> nebo mel vice moznosti, tak bych ho odkazal na projekty jako:
> https://github.com/django-admin-tools/django-admin-tools
> https://djangosuit.com/
>
>
>
> pá 12. 2. 2021 v 16:42 odesílatel MirekZv  napsal:
>
>> Honza zatím mlčí, odpovím si sám.
>> Samozřejmě, že admin/app_list.html se volá na 2 místech.
>> Jedno místo popisuje Honza - to je "vhodné k přetěžování".
>> Podruhé v nav_sidebar.html, tam opět žádný blok není, neboli další 
>> šablona, která "není určena k přetěžování".
>> Ostatně, kdykoli když slyším slovo "přetěžování", tak už je mi jasné, že 
>> je něco špatně.
>> Takže závěr: Django je jako vždy geniální, já jsem zase ten blbec, co ho 
>> chce použít k něčemu, k čemu není určeno.
>> (sorry za tu mírnou jedovatost, já to tak nemyslím, jen toho mám trochu 
>> plné zuby)
>>
> 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:
>>

Re: [django-cs] emmett

[Honza Javorek]

Full stack je právě Next.js (React) a Nuxt.js (Vue).

HJ

On Tue 16. 2. 2021 at 14:17, MirekZv  wrote:

> Myslím, že silný jazyk jako Python by 2 linie mohl utáhnout.
> Jako je v Javascriptu dneska právě na výběr ten React, Vue, Angular
> (jestli už mají něco fullstack serverového, nevím - divil bych se).
> Dne pátek 12. února 2021 v 16:42:20 UTC+1 uživatel Honza Javorek napsal:
>
>> 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 djan...@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+...@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
>>> 
>>> .
>>>
>> --
> --
> 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..

[django-cs] Jak vlastně pracuje url dispatcher

[MirekZv]

Nechápu jeden detail. Prosím, poraďte.

Co je za magii za implementací urls.py?

Nic to nevrací.
Nic z toho se nikde neimportuje.

Znamená to, že striktně musím použít jméno `urlpatterns` a to se magicky 
automaticky naimportuje někde ve vnitřnostech Djanga?

Znamená to, že v include urls souboru opět musím použít jméno `urlpatterns` 
a to se magicky automaticky naimportuje někde ve vnitřnostech include()?

Nebo to nějak pletu a dá se to vysvětlit lépe?

-- 
-- 
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/da232fdc-0df7-46d2-8cc9-f8a95105430an%40googlegroups.com.

Re: [django-cs] Jak vlastně pracuje url dispatcher

[Honza Král]

On Tue, Feb 16, 2021 at 10:00 PM MirekZv  wrote:

> Nechápu jeden detail. Prosím, poraďte.
>
> Co je za magii za implementací urls.py?
>

Zadna magie, ta byla z django odstranena pred 15 lety -
https://code.djangoproject.com/wiki/RemovingTheMagic :)

>
> Nic to nevrací.
> Nic z toho se nikde neimportuje.
>
> Znamená to, že striktně musím použít jméno `urlpatterns` a to se magicky
> automaticky naimportuje někde ve vnitřnostech Djanga?
>

Neimportuje se to automaticky, musis to explicitne nakonfigurovat v
settings kde das cestu k tomu modulu, pak se proste pouzije kod ala

https://github.com/django/django/blob/master/django/urls/conf.py#L35

Je to proste nadefinovany interface, tedy kontrakt nebo API - je jedno,
jestli se bavime o funkcich, tridach, nebo modulech a promenny, plati pro
to stejna pravidla. V tomto pripade ma django jasne API ktere definuje, ze
modul ze settings se naimportuje po inicializaci a promenna urlpatterns z
toho modulu bude root urls.


> Znamená to, že v include urls souboru opět musím použít jméno
> `urlpatterns` a to se magicky automaticky naimportuje někde ve vnitřnostech
> include()?
>

opet neni to ani magicke ani automaticke, je to naprosto explicitni -
funkce include provadi ten import, jeji kod je linkovany vys a je tam
presne videt, co dela.


> Nebo to nějak pletu a dá se to vysvětlit lépe?
>
> --
> --
> 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/da232fdc-0df7-46d2-8cc9-f8a95105430an%40googlegroups.com
> 
> .
>

-- 
-- 
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/CADoCwr3C2sbmXq7KXKnzeYfTQyxopMZ%3Dku6OJ61FF%2BSE68ubfQ%40mail.gmail.com.

Re: [django-cs] Jak vlastně pracuje url dispatcher

[MirekZv]

Dík.
Takže jestli Ti dobře rozumím,
když v hlavním urls.py budu plnit
patterns = []
a jeden z nich bude include() - připojí urls z aplikace,
a na konci toho hlavního urls.py udělám
urlpatterns = patterns

tak aby to celé fungovalo, musím v tom aplikačním includovaném dávat
urlpatterns = []

ok? rozumím tomu dobře?

Dne úterý 16. února 2021 v 22:13:17 UTC+1 uživatel honza...@gmail.com 
napsal:

> On Tue, Feb 16, 2021 at 10:00 PM MirekZv  wrote:
>
>> Nechápu jeden detail. Prosím, poraďte.
>>
>> Co je za magii za implementací urls.py?
>>
>
> Zadna magie, ta byla z django odstranena pred 15 lety - 
> https://code.djangoproject.com/wiki/RemovingTheMagic :) 
>
>>
>> Nic to nevrací.
>> Nic z toho se nikde neimportuje.
>>
>> Znamená to, že striktně musím použít jméno `urlpatterns` a to se magicky 
>> automaticky naimportuje někde ve vnitřnostech Djanga?
>>
>
> Neimportuje se to automaticky, musis to explicitne nakonfigurovat v 
> settings kde das cestu k tomu modulu, pak se proste pouzije kod ala
>
> https://github.com/django/django/blob/master/django/urls/conf.py#L35
>
> Je to proste nadefinovany interface, tedy kontrakt nebo API - je jedno, 
> jestli se bavime o funkcich, tridach, nebo modulech a promenny, plati pro 
> to stejna pravidla. V tomto pripade ma django jasne API ktere definuje, ze 
> modul ze settings se naimportuje po inicializaci a promenna urlpatterns z 
> toho modulu bude root urls.
>
>
>> Znamená to, že v include urls souboru opět musím použít jméno 
>> `urlpatterns` a to se magicky automaticky naimportuje někde ve vnitřnostech 
>> include()?
>>
>
> opet neni to ani magicke ani automaticke, je to naprosto explicitni - 
> funkce include provadi ten import, jeji kod je linkovany vys a je tam 
> presne videt, co dela.
>
>
>> Nebo to nějak pletu a dá se to vysvětlit lépe?
>>
>> -- 
>> -- 
>> E-mailová skupina djan...@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+...@googlegroups.com.
>> Chcete-li tuto diskusi zobrazit na webu, navštivte 
>> https://groups.google.com/d/msgid/django-cs/da232fdc-0df7-46d2-8cc9-f8a95105430an%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
-- 
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/11ab32f4-a4b7-4bf4-b0a8-7fdf9e217fe9n%40googlegroups.com.

Re: [django-cs] Jak vlastně pracuje url dispatcher

[Honza Král]

On Tue, Feb 16, 2021 at 10:36 PM MirekZv  wrote:

> Dík.
> Takže jestli Ti dobře rozumím,
> když v hlavním urls.py budu plnit
> patterns = []
> a jeden z nich bude include() - připojí urls z aplikace,
> a na konci toho hlavního urls.py udělám
> urlpatterns = patterns
>
> tak aby to celé fungovalo, musím v tom aplikačním includovaném dávat
> urlpatterns = []
>
> ok? rozumím tomu dobře?
>
>
Jsou i jine moznosti jak to udelat, napriklad si naimportovat primo ten
list a ten predat do te funkce include, ale ano, tohle bude fungovat take,
je to presne jako ukazka v dokumentaci:
https://docs.djangoproject.com/en/3.1/topics/http/urls/#including-other-urlconfs



> Dne úterý 16. února 2021 v 22:13:17 UTC+1 uživatel honza...@gmail.com
> napsal:
>
>> On Tue, Feb 16, 2021 at 10:00 PM MirekZv  wrote:
>>
>>> Nechápu jeden detail. Prosím, poraďte.
>>>
>>> Co je za magii za implementací urls.py?
>>>
>>
>> Zadna magie, ta byla z django odstranena pred 15 lety -
>> https://code.djangoproject.com/wiki/RemovingTheMagic :)
>>
>>>
>>> Nic to nevrací.
>>> Nic z toho se nikde neimportuje.
>>>
>>> Znamená to, že striktně musím použít jméno `urlpatterns` a to se magicky
>>> automaticky naimportuje někde ve vnitřnostech Djanga?
>>>
>>
>> Neimportuje se to automaticky, musis to explicitne nakonfigurovat v
>> settings kde das cestu k tomu modulu, pak se proste pouzije kod ala
>>
>> https://github.com/django/django/blob/master/django/urls/conf.py#L35
>>
>> Je to proste nadefinovany interface, tedy kontrakt nebo API - je jedno,
>> jestli se bavime o funkcich, tridach, nebo modulech a promenny, plati pro
>> to stejna pravidla. V tomto pripade ma django jasne API ktere definuje, ze
>> modul ze settings se naimportuje po inicializaci a promenna urlpatterns z
>> toho modulu bude root urls.
>>
>>
>>> Znamená to, že v include urls souboru opět musím použít jméno
>>> `urlpatterns` a to se magicky automaticky naimportuje někde ve vnitřnostech
>>> include()?
>>>
>>
>> opet neni to ani magicke ani automaticke, je to naprosto explicitni -
>> funkce include provadi ten import, jeji kod je linkovany vys a je tam
>> presne videt, co dela.
>>
>>
>>> Nebo to nějak pletu a dá se to vysvětlit lépe?
>>>
>>> --
>>> --
>>> E-mailová skupina djan...@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+...@googlegroups.com.
>>> Chcete-li tuto diskusi zobrazit na webu, navštivte
>>> https://groups.google.com/d/msgid/django-cs/da232fdc-0df7-46d2-8cc9-f8a95105430an%40googlegroups.com
>>> 
>>> .
>>>
>> --
> --
> 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/11ab32f4-a4b7-4bf4-b0a8-7fdf9e217fe9n%40googlegroups.com
> 
> .
>

-- 
-- 
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/CADoCwr2R_Uhbi1aKuyOqjs2A74cviEAQW9jgy6E3-JTBe9ZbeA%40mail.gmail.com.

Re: [django-cs] emmett

[Petr Messner]

Ahoj,

myslím, že kdo chce dělat web v Pythonu, ale ne v Djangu, tak má hromadu
možností. Akorát to nebude tak předšlapaná cestička v podobě "frameworku".
Občas bude potřeba poslat i nějaký pull request. Že je něco bastl... tak se
to nemělo tak zbastlit :) Django appky snad nikdy bastl nejsou? :)

K hegemonii Djanga - podle mě jde o to, že Django plní nějaký typický use
case (někoho, kdo se rozhodl pro vývoj webu v Pythonu), a nějaký jiný
framework, který by byl nějak lepší než Django, tak by byl lepší jen v
nějaké úzké nice, kde nenasbírá dostatečně velkou komunitu.

Tady bych rád věděl, jak si přesně si Mirek představuje ten fullstack
framework (konkurenční ke Djangu), protože tipuju, že by to bylo právě
něco, co se hodí nějaké menší skupině lidí, a jiná skupina lidí by ten
ideál zase viděla jinak.

Upřímně si dokonce myslím, že samotný webový vývoj v Pythonu je a čím dál
víc bude jen nějaká anomálie, protože web je dnes Javascript, weboví lidi
umí Javascript, v Javascriptu se dá už dobře programovat (nehledě na
nadstavbu Typescript), a moc nedává smysl pro webového člověka studovat
ještě Python a Django. Tady dokonce vidím spíš šanci pro
knihovny/mikroframeworky typu Flask, protože mají nižší laťku – člověk
trávící 90 % času mimo Python spíš pochopí a upraví Flask appku (pokud
nebude překomplikovaná) než Django appku.

Naštěstí Python není web-dev-only jazyk, takže samotný Python je i při
tomto scénáři "v pohodě" :)

Přijde mi fajn, že nevymýšlíme stále znova kolo


Tak Django taky znovuvynalezlo dokonce několik kol, nebo to snad byl první
framework, první ORM, první šablonovací engine atd. vůbec? :) Tenhle
argument mi přijde hloupý, bohužel je samoreplikující, protože jeho
"poslechnutí" vede k jeho dalšímu posílení a opakování. Nejlepší ekonomický
systém je takový, kde jeden druh zboží vyrábí jen jedna továrna, že jo :)

Ono stejně ten tvrdý kód, který by se v novém frameworku holt psal znova
(nebo by se zkopíroval), je jen 20 % celku, zbytek je dokumentace,
komunita, snadnost použití, radost ze života... A tam třeba je co vymýšlet
a zlepšovat? Proč teda lidi používají raději Flask?

Nevím, proč je fenomén "jednoho správného frameworku" tak silný zrovna v
Pythonu.

V Ruby


Další minoritní jazyk, ze kterého bych dnes nic nevyvozoval...

(Když už by se měly porovnávat frameworky napříč jazyky, tak je tu několik
jiných dalších jazyků.)

tam to táhl Express


Express je v JS asi něco jako Flask v Pythonu. Mimochodem přijde mi, že v
JS světě nikdo po nějakém "javascript Djangu" moc neteskní, až mi to přijde
trochu podezřelé (jsem třeba jen v jiné bublině?).

Ad Next.js - myslím, že vývoj Next.js spotřeboval obrovské množství energie
- kdyby bylo takové množství investované do Python framekworku, tak by to
na alternativu Djanga stačilo. Taky se mi líbí, že Next.js na to jde
holisticky - od developer experience při psaní React komponent až po
first-class podporu pro static a serverless deployment. (Aneb kvůli čemu
tak moc uspělo PHP?)

Mě osobně se webová aplikace v Pythonu (resp. Python část webové aplikace)
líbí nejvíc jako API, které potom konzumuje "normální" javascript frontend
:) Kdyby admin UI bylo automaticky sestavované nad GraphQL schématem, a
kdyby se ten webový framework primárně soustředil na nosql (ideálně takové,
které lze provozovat serverless), a mělo to first-class podporu
(micro)services architektury pro lepší použitelnost ve větších projektech,
tak takhle bych si nějaký nový framework představit dokázal :) Ale právě
jsem asi sám :)

A to ještě nevíme, co za možnosti přinese wasm. Nebo taky ne.

Petr M.


út 16. 2. 2021 v 14:17 odesílatel MirekZv  napsal:

> Myslím, že silný jazyk jako Python by 2 linie mohl utáhnout.
> Jako je v Javascriptu dneska právě na výběr ten React, Vue, Angular
> (jestli už mají něco fullstack serverového, nevím - divil bych se).
> Dne pátek 12. února 2021 v 16:42:20 UTC+1 uživatel Honza Javorek napsal:
>
>> 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 podo