[django-cs] Re: REST + SOAP

[MirekZv]

Nakonec se mi povedlo realizovat tenhle 
návod: 
https://github.com/arskom/spyne/blob/master/doc/source/manual/05-03_django.rst
Je teda děsivý (je tam sousta překlepů a nikde nedefinovaných proměnných), 
ale nakonec se zadařilo, díky tomu, že ten princip je jasný: in_protocol= a 
out_protocol= (což chceme mít Soap) se nedefinuje celkově ve wsgi.py, ale 
jen pro jednotlivý endpoint v urls.py.
Tak mi běží Soap souběžně s Restem.

Dne středa 9. listopadu 2022 v 17:06:36 UTC+1 uživatel lubos@gmail.com 
napsal:

> Na jednom projektu řešíme podobný problém (FastAPI vs. AIOHttp) a řešíme 
> to spuštěním 2 aplikačních webserverů (jakoby 2 wsgi) nad jedním Python 
> kódem. Větvíme to na úrovni URL PATH na webserveru.
>
> Dne středa 9. listopadu 2022 v 9:17:13 UTC+1 uživatel MirekZv napsal:
>
>> Ahoj.
>> Máme Django REST (DRF) aplikaci
>> a partnerská instituce nás teď nutí, abychom v nějakém detailu 
>> komunikovali přes SOAP.
>> Netuším vůbec, jakou architekturou to řešit - jako klient (zeep) to 
>> problém není, jako server (spyne) se to integruje ve wsgi.py.
>>
>> Měl bych nějak zřetězit funkce ve wsgi nebo větvit url v nginx na 2 jinak 
>> konfigurované (ani nením, co napsat - instance, projekty,..) nebo nějak 
>> úplně jinak?
>>
>> Vygooglit nějak nic nemůžu :(
>>
>

-- 
-- 
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/8f2014a0-d73f-4be1-a095-143622b86248n%40googlegroups.com.

[django-cs] Re: Hosting Django aplikací

[MirekZv]

Já jsem používal Forpsi a myslím, že to šlapalo hezky.
Samozřejmě doba, kdy 20G s Linux image byla za 35 Kč na měsíc, je pryč,
ale myslím, že kolem těch asi 85 Kč je to pořád dost přijatelné.

Dne pátek 21. ledna 2022 v 18:04:26 UTC+1 uživatel stanisl...@gmail.com 
napsal:

> Zdravím,
>
> chtěl bych se zeptat, kde hostujete své Django aplikace/weby? Osobně 
> používám VPSfree hosting. Nemám problém si sám spravovat VPSka, ale v 
> poslední době mi připadají servery takové... líné, pomalu reagující. Když 
> stejnou aplikaci pustím na notebooku či VPSku na serveru co mám doma, 
> dostanu rapidně jinou odezvu.
>
> Předem díky za tipy, Standa
>
>
>

-- 
-- 
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/cff63637-669a-4187-a206-e2de257f9d48n%40googlegroups.com.

[django-cs] REST + SOAP

[MirekZv]

Ahoj.
Máme Django REST (DRF) aplikaci
a partnerská instituce nás teď nutí, abychom v nějakém detailu komunikovali 
přes SOAP.
Netuším vůbec, jakou architekturou to řešit - jako klient (zeep) to problém 
není, jako server (spyne) se to integruje ve wsgi.py.

Měl bych nějak zřetězit funkce ve wsgi nebo větvit url v nginx na 2 jinak 
konfigurované (ani nením, co napsat - instance, projekty,..) nebo nějak 
úplně jinak?

Vygooglit nějak nic nemůžu :(

-- 
-- 
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/16ad356f-ddfe-4ec9-970b-e9cc3f569aacn%40googlegroups.com.

[django-cs] Našeptavač nejčastějších hodnot

[MirekZv]

Potřeboval bych do Django form-u widget, obyč. CharField/Textarea, ale aby 
mi v popupu pod ním nabídnul např. 10 nejčastějších hodnot v příslušném 
sloupci tabulky. Máte nějakou radu? Díky.

-- 
-- 
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/104caa34-32aa-46a1-abe3-6bb73c1d722an%40googlegroups.com.

Re: [django-cs] Re: Jak co nejlépe a obecně na popupy?

[MirekZv]

Tak s nějakým odstupem jsem si to uzavřel.

django-admin-autocomplete-all jsem dotáhl do podoby, že je snad v Adminu 
použitelný. Po jeho připnutí podle návodu zobrazí `./manage.py check` 
informaci, jaké ModelAdmin je potřeba přidat s definovanými 
get_search_results(). Nepovedlo se mi ale jakkoli to použít mimo Admin.

Takže jsem si udělal závěr, že než to řešit jen v Adminu takto (a vůbec: 
než tam používat nativní autocomplete_fields), je lepší jít standardní 
robustní cestou všude stejně, a to je django-autocomplete-light. Data 
získává přes ajax, filtry nejsou problém (pomocí tzv. forwarded údajů). 
Naprosto perfektní, čisté řešení, návod, který možná na první pohled trochu 
zastraší, ale ve skutečnosti je perfektní (ne jako Django samotné, kde 
návod je taky dokonalý, jen ho pochopíte teprve poté, co jste pochopili 
problematiku).

Asi to neumí jednu věc, která by se mi ještě líbila pro absolutní 
dokonalost: Kdyby na backend straně pomocí nějakého .limit(501).count() 
zjistil, že má <= 500 voleb, mohl by na klienta poslat vše a dále by se 
filtrovalo už jen na klientu bez zdržování dalšími ajax dotazy. No ale to 
je detail a to už bych chtěl příliš.
Dne pátek 5. března 2021 v 11:43:22 UTC+1 uživatel MirekZv napsal:

> @Standa
>
> Jestli je řeč o simpleisbetterthancomplex, tak naprosto souhlas. Super 
> návody. A dokonale popsáno a srozumitelné.
>
> @__all__
>
> Pokud by někdo bojoval s tou variantou použít v adminu django 2+ nativní 
> autocomplete_fields, jsou tam 2 možné problémy:
> - některé adminy je vynucováno přidat, protože je v nich vyžadováno 
> search_fields=... ; pokud takové adminy nepotřebujete (máte např. místo 
> nich Inliny), skryjete je takto: has_module_permission = lambda self, req: 
> False
> - nelze rozlišit dva ForeignKeys ve stejném modelu směřující také do 
> jediného modelu (o tom už jsem psal) ; řešení lze vzít z 
> django-admin-autocomplete-all (nebo přímo použít tuto knihovnu)
>
> Dne čtvrtek 4. března 2021 v 20:40:19 UTC+1 uživatel stanisl...@gmail.com 
> napsal:
>
>> Já bych nebyl až tak kritický. Osobně jsem se tam několikrát inspiroval a 
>> přestože některé věci už řeším jinak, dalo mi to možnost mít alespoň nějaké 
>> řešení, většinou opravdu simple. Jsem rád za každé srozumitelné návody, 
>> zvláště proto, že v češtině prakticky nic uceleného neexistuje. Sice mluvím 
>> anglicky plynule, ale učit se nové věci je pro mne příjemnější v češtině. 
>> Takto přímé a srozumitelné návody se velice snadno a dobře konzumují a 
>> vysloveně nesmysly jsem tam snad nikdy neviděl.
>>
>> Btw: mátě někdo tip na podobnou stránku, jen pro vyšší level? Většinou na 
>> potřebné téma vždy najdu velice pěkné články, ale nic uceleného a 
>> mnohahodinová videa na YT mně nikdy nebrala.
>>
>> Standa
>> On 2. 3. 2021 11:08 +0100, MirekZv , wrote:
>>
>> Nemám na to moc času, zatím mně z toho ale vychází, že, jakkoli mám rád 
>> ty stránky simpleisbetterthancomplex, tak tady to je asi ztráta času a krok 
>> nesprávným směrem. 
>> A že správně bude použít django-autocomplete-light, který nejspíš přesně 
>> všechno toto řeší.
>>
>> Dne pátek 26. února 2021 v 10:25:08 UTC+1 uživatel MirekZv napsal:
>>
>>> Mám ne moc minimalistické, ale pro reálné projekty nutné požadavky na 
>>> popupy (select+options) ve formulářích:
>>> 1. ajaxem získávané options (mimo admin i v něm) - všude a vždy, i když 
>>> kdyby to umělo automaticky vypnout, když je v modelu méně než např. 100 
>>> položek, nevadilo by,
>>> 2. dynamický filtr pro options, zejména když jsou relačně závislé popupy 
>>> (opět mimo admin i v adminu, včetně inlinů); příklad: country & city: jen 
>>> cities z vybrané country mají být na výběr.
>>>
>>> Implementoval jsem toto
>>>
>>> https://simpleisbetterthancomplex.com/tutorial/2018/01/29/how-to-implement-dependent-or-chained-dropdown-list-with-django.html
>>> včetně funkcionality (2) v inlinech a dokážu to zprovoznit.
>>>
>>> Ale je zatím dost individuální práce pro každý případ, lepší by bylo 
>>> něco generického.
>>> A neřeší to ten ajax.
>>>
>>> Je nějaká rozumná cesta, jak dosáhnout (1)+(2) všude v aplikaci?
>>> Které packages přidat do projektu? django-autocomplete-light? a ještě 
>>> něco?
>>>
>>> Díky...
>>> PS: samozřejmě, když jsem šel na Django, tak jsem se domníval, že tam 
>>> jdu proto, že takovéto věci dělá out-of-the-box. Ach ta moje naivita.
>>>
>>> Best regards,
>>> Mirek
>>>
>> --
>> --
>> E-mailová skupina djan...@googlegroups.com
>> Správa: http://groups.google.cz/group/django-cs
>>

[django-cs] konfigurace aplikace, app_label, apod.

[MirekZv]

Mohl bych požádat někoho o kontrolu, případně i o vysvětlení?

Jedna z dalších obtížných Django věcí *) je konfigurace aplikace.

Dejme tomu, že připojuji aplikaci aausers.

Řekl bych, že
- v INSTALLED_APPS můžu mít buď `aausers` nebo `aausers.apps.AAUsersConfig`,
- __init__.py aplikace bych měl mít: `default_app_config = 
'aausers.apps.AAUsersConfig'` (a to možná nebude nutné od Dj 3.2?)
- v apps.py bych měl mít AAUsersConfig třídu nějak takto:
  from django.apps import AppConfig
  from django.utils.translation import gettext_lazy as _
  class AAUsersConfig(AppConfig):
  name = 'aausers'
  label = 'aausers'
  verbose_name = _('Users')

Zdá se mi, že pak to docela uspokojivě funguje a moc se nenaráží v různých 
"na hraně" situacích.

Co třeba nevím je:
1) Co je ten `app_label` - pojem, který se rád vyskytuje v chybových 
hláškách - to je totéž jako `label`?
2) jaký je rozdíl mezi name=.. a label=..? Mohou se lišit? Kde se pak které 
používá?
3) mám pocit, že s tím souvisí i ta (pro mě záhadná) syntaxe include(), 
např. `include(('aausers.urls', 'aausers'), namespace='aausers')` - co z 
toho je `label` a co `name`? Nemůžu to v dokumentaci najít.
4) k čemu by aplikaci bylo, aby měla více Configů? Aby se dala zapnout do 
víc různých projektů a třeba aliasovat její jméno?

*) všimněte si, jak už jste mě naučili se vyjadřovat uctivě, až poníženě

-- 
-- 
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/1e3347b7-87c7-4ea2-a666-94318e3722a2n%40googlegroups.com.

Re: [django-cs] Re: Jak co nejlépe a obecně na popupy?

[MirekZv]

@Standa

Jestli je řeč o simpleisbetterthancomplex, tak naprosto souhlas. Super 
návody. A dokonale popsáno a srozumitelné.

@__all__

Pokud by někdo bojoval s tou variantou použít v adminu django 2+ nativní 
autocomplete_fields, jsou tam 2 možné problémy:
- některé adminy je vynucováno přidat, protože je v nich vyžadováno 
search_fields=... ; pokud takové adminy nepotřebujete (máte např. místo 
nich Inliny), skryjete je takto: has_module_permission = lambda self, req: 
False
- nelze rozlišit dva ForeignKeys ve stejném modelu směřující také do 
jediného modelu (o tom už jsem psal) ; řešení lze vzít z 
django-admin-autocomplete-all (nebo přímo použít tuto knihovnu)

Dne čtvrtek 4. března 2021 v 20:40:19 UTC+1 uživatel stanisl...@gmail.com 
napsal:

> Já bych nebyl až tak kritický. Osobně jsem se tam několikrát inspiroval a 
> přestože některé věci už řeším jinak, dalo mi to možnost mít alespoň nějaké 
> řešení, většinou opravdu simple. Jsem rád za každé srozumitelné návody, 
> zvláště proto, že v češtině prakticky nic uceleného neexistuje. Sice mluvím 
> anglicky plynule, ale učit se nové věci je pro mne příjemnější v češtině. 
> Takto přímé a srozumitelné návody se velice snadno a dobře konzumují a 
> vysloveně nesmysly jsem tam snad nikdy neviděl.
>
> Btw: mátě někdo tip na podobnou stránku, jen pro vyšší level? Většinou na 
> potřebné téma vždy najdu velice pěkné články, ale nic uceleného a 
> mnohahodinová videa na YT mně nikdy nebrala.
>
> Standa
> On 2. 3. 2021 11:08 +0100, MirekZv , wrote:
>
> Nemám na to moc času, zatím mně z toho ale vychází, že, jakkoli mám rád ty 
> stránky simpleisbetterthancomplex, tak tady to je asi ztráta času a krok 
> nesprávným směrem. 
> A že správně bude použít django-autocomplete-light, který nejspíš přesně 
> všechno toto řeší.
>
> Dne pátek 26. února 2021 v 10:25:08 UTC+1 uživatel MirekZv napsal:
>
>> Mám ne moc minimalistické, ale pro reálné projekty nutné požadavky na 
>> popupy (select+options) ve formulářích:
>> 1. ajaxem získávané options (mimo admin i v něm) - všude a vždy, i když 
>> kdyby to umělo automaticky vypnout, když je v modelu méně než např. 100 
>> položek, nevadilo by,
>> 2. dynamický filtr pro options, zejména když jsou relačně závislé popupy 
>> (opět mimo admin i v adminu, včetně inlinů); příklad: country & city: jen 
>> cities z vybrané country mají být na výběr.
>>
>> Implementoval jsem toto
>>
>> https://simpleisbetterthancomplex.com/tutorial/2018/01/29/how-to-implement-dependent-or-chained-dropdown-list-with-django.html
>> včetně funkcionality (2) v inlinech a dokážu to zprovoznit.
>>
>> Ale je zatím dost individuální práce pro každý případ, lepší by bylo něco 
>> generického.
>> A neřeší to ten ajax.
>>
>> Je nějaká rozumná cesta, jak dosáhnout (1)+(2) všude v aplikaci?
>> Které packages přidat do projektu? django-autocomplete-light? a ještě 
>> něco?
>>
>> Díky...
>> PS: samozřejmě, když jsem šel na Django, tak jsem se domníval, že tam jdu 
>> proto, že takovéto věci dělá out-of-the-box. Ach ta moje naivita.
>>
>> Best regards,
>> Mirek
>>
> --
> --
> 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/e080bd5f-e7a7-49f3-84cd-3afe0804a958n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-cs/e080bd5f-e7a7-49f3-84cd-3afe0804a958n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
-- 
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/3579c657-7b32-4e27-a07d-1042879f81a2n%40googlegroups.com.

[django-cs] Re: Jak co nejlépe a obecně na popupy?

[MirekZv]

Tak jsem si trochu osvěžil paměť.

V Adminu má Django od verze 2.0 autocomplete_fields, což jsou relační pole 
(ForeignKey, ManyToManyField), které si dohledávají pro svůj widget přes 
ajax obsah na adrese autocomplete/.
Komunikuje to se .search_fields atributem odkazovaného ModelAdminu, který 
určuje, ve kterých polích se má vyhledávat to, co uživatel zapíše do popup 
widgetu. To může být nahrazeno metodou .get_search_results().

Implementace Djanga je slabá (alespoň ve 2.0, ale myslím, že ani později se 
na to nesáhlo) v tom, že nedokážou rozlišit 2 různé ForeignKey, směřující 
do stejného modelu. Např. když budete mít v modelu pole "Zadal" a 
"Schválil", obě směřující do User modelu, nedokážete rozlišit, které právě 
zadáváte a jak se mají filtrovat dostupné možnosti.
Lze udělat trik s rozšířením Referer adresy (request.headers['Referer']) o 
např. ?key=..., takže .get_search_results() pak může najít, které 
ForeignKey po něm požaduje výsledky.
Kdysi jsem si s tím už hrál a v 
github.com/pyutil/django-admin-autocomplete-all je to implementováno (a 
trochu popsáno včetně příkladu volání) 
v autocomplete_all/js/autocomplete_params.js. Spíš snad jako inspirace, 
protože za zrovna tuto package bych ruku do ohně nedal.

Django 2+ autocomplete_fields ale nepomůžou mimo Admin, takže je opravdu 
otevřená otázka, jakou cestou jít:
Zda se snažit použít django-autocomplete-light všude a kašlat na Dj2 
autocomplete_fields
nebo zda v Adminu upřednostnit zmíněnou nativní vymoženost.

Dne úterý 2. března 2021 v 11:08:31 UTC+1 uživatel MirekZv napsal:

> Nemám na to moc času, zatím mně z toho ale vychází, že, jakkoli mám rád ty 
> stránky simpleisbetterthancomplex, tak tady to je asi ztráta času a krok 
> nesprávným směrem.
> A že správně bude použít django-autocomplete-light, který nejspíš přesně 
> všechno toto řeší.
>
> Dne pátek 26. února 2021 v 10:25:08 UTC+1 uživatel MirekZv napsal:
>
>> Mám ne moc minimalistické, ale pro reálné projekty nutné požadavky na 
>> popupy (select+options) ve formulářích:
>> 1. ajaxem získávané options (mimo admin i v něm) - všude a vždy, i když 
>> kdyby to umělo automaticky vypnout, když je v modelu méně než např. 100 
>> položek, nevadilo by,
>> 2. dynamický filtr pro options, zejména když jsou relačně závislé popupy 
>> (opět mimo admin i v adminu, včetně inlinů); příklad: country & city: jen 
>> cities z vybrané country mají být na výběr.
>>
>> Implementoval jsem toto
>>
>> https://simpleisbetterthancomplex.com/tutorial/2018/01/29/how-to-implement-dependent-or-chained-dropdown-list-with-django.html
>> včetně funkcionality (2) v inlinech a dokážu to zprovoznit.
>>
>> Ale je zatím dost individuální práce pro každý případ, lepší by bylo něco 
>> generického.
>> A neřeší to ten ajax.
>>
>> Je nějaká rozumná cesta, jak dosáhnout (1)+(2) všude v aplikaci?
>> Které packages přidat do projektu? django-autocomplete-light? a ještě 
>> něco?
>>
>> Díky...
>> PS: samozřejmě, když jsem šel na Django, tak jsem se domníval, že tam jdu 
>> proto, že takovéto věci dělá out-of-the-box. Ach ta moje naivita.
>>
>> Best regards,
>> Mirek
>>
>

-- 
-- 
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/b7e135a8-66e0-4b97-9087-c00fa5b81325n%40googlegroups.com.

[django-cs] Dá se globálně v celém projektu vyměnit widget?

[MirekZv]

Hledal jsem, ale nejsem z toho moc moudrý.
Když bych třeba pro DateTimeField chtěl všude(!) jiný, než je ten 
standardní.
mz

-- 
-- 
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/7f381a3a-fae7-4cb9-af5c-00c61727fe37n%40googlegroups.com.

[django-cs] Re: Jak co nejlépe a obecně na popupy?

[MirekZv]

Nemám na to moc času, zatím mně z toho ale vychází, že, jakkoli mám rád ty 
stránky simpleisbetterthancomplex, tak tady to je asi ztráta času a krok 
nesprávným směrem.
A že správně bude použít django-autocomplete-light, který nejspíš přesně 
všechno toto řeší.

Dne pátek 26. února 2021 v 10:25:08 UTC+1 uživatel MirekZv napsal:

> Mám ne moc minimalistické, ale pro reálné projekty nutné požadavky na 
> popupy (select+options) ve formulářích:
> 1. ajaxem získávané options (mimo admin i v něm) - všude a vždy, i když 
> kdyby to umělo automaticky vypnout, když je v modelu méně než např. 100 
> položek, nevadilo by,
> 2. dynamický filtr pro options, zejména když jsou relačně závislé popupy 
> (opět mimo admin i v adminu, včetně inlinů); příklad: country & city: jen 
> cities z vybrané country mají být na výběr.
>
> Implementoval jsem toto
>
> https://simpleisbetterthancomplex.com/tutorial/2018/01/29/how-to-implement-dependent-or-chained-dropdown-list-with-django.html
> včetně funkcionality (2) v inlinech a dokážu to zprovoznit.
>
> Ale je zatím dost individuální práce pro každý případ, lepší by bylo něco 
> generického.
> A neřeší to ten ajax.
>
> Je nějaká rozumná cesta, jak dosáhnout (1)+(2) všude v aplikaci?
> Které packages přidat do projektu? django-autocomplete-light? a ještě něco?
>
> Díky...
> PS: samozřejmě, když jsem šel na Django, tak jsem se domníval, že tam jdu 
> proto, že takovéto věci dělá out-of-the-box. Ach ta moje naivita.
>
> Best regards,
> Mirek
>

-- 
-- 
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/e080bd5f-e7a7-49f3-84cd-3afe0804a958n%40googlegroups.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[MirekZv]

https://dafoster.net/articles/2021/02/16/building-web-apps-with-vue-and-django-the-ultimate-guide/

Dne čtvrtek 25. února 2021 v 14:52:16 UTC+1 uživatel jan.be...@gmail.com 
napsal:

> Mám jeden projekt který má Django backend s GraphQL API. A je to super, 
> GraphQL je významný evoluční pokrok oproti REST. Idea byla, že frontend 
> vytvoří někdo jiný, proto taky GraphQL. Ale nakonec jsem ho dělal taky, a 
> abych nemusel přepínat mezi jazyky a technologiemi, tak je frontend taky v 
> Djangu. Nemá žádné modely, jen pracuje s tím GraphQL API a vykresluje z 
> toho web (využívám především views, templaty a formuláře). Ale pokud nevadí 
> vykreslování na serveru, tak je Django na frontend úplně v pohodě.
>
> To jen tak pro zpestření, že se to dá dělat všelijak :-)
>
> Honza
>
> st 24. 2. 2021 v 20:17 odesílatel MirekZv  napsal:
>
>> @Standa
>>
>>>
>> Nevím o tom zatím nic.
>> Tady je nějaké video, které bych si já chtěl zkouknout. 
>> https://www.youtube.com/watch?v=3eTtVY7duJk
>> A pak se samozřejmě proberu názory ostatních, co napsali sem.
>>
>> -- 
>>
> -- 
>> 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/5b9f9231-fdda-4bbc-82c8-4c3f7efd36aen%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/5b9f9231-fdda-4bbc-82c8-4c3f7efd36aen%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
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/ff475ddf-26c1-4d42-98e0-c9b4cc233e2fn%40googlegroups.com.

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@Vláďa - *Proč čteš topics, které Tě nezajímají nebo jsou dokonce otravné?*

Víš co, tak toto teda ne. Ačkoli na sobě obvykle nechám dříví štípat, toto 
si líbit nenechám - toto je příliš, to je přes čáru.

Promiň, ale já jsem dost starej chlap na to, abych už poznal, co je myšleno 
dobře a co není. Jakkoli to přetéká medovými slovy.
Tedy, možná to v rámci dvorečku své mysli dobře myslíš. Ale zamysli se, co 
Ti dává právo se ke mně takto chovat?
A jestli jsi rovný člověk, tak se neurazíš a není důvod nebýt nadále 
přáteli.

Možná jsi neuvážil, že s některými lidmi v diskuzi se známe, takže si 
můžeme dovolit občas nějakou ironickou poznámku (ke mně i ode mě).

Můj názor:
- Koho téma nezajímá, ten ho nečte,
- Věcné příspěvky o problémech v Pythonu a Djangu,
- Eliminovat hraběcí rady, typické zlo českých e-diskuzí,
- Oživit českou diskuzi: Víc věcných příspěvků než vloni (2 měsíčně?)

Dne pátek 26. února 2021 v 10:35:03 UTC+1 uživatel Vláďa Macek napsal:

> Mirku, každý jsme nějak začínali a někteří jsme psali dlouhé dotazy s 
> představou, že svět budou naše problémy zajímat.
>
> Číst tvoje texty je otravné, z větší části proto, že z nich sálá 
> nedostatek 
> pokory. To se ti tu lidi snažili naznačit.
>
> Pokud budeš ještě svoje výlevy upgradovat ad hominem, dospěješ k tomu, že 
> budeš už zcela ignorovaný.
>
> Tohle jsem napsal, abych ti poskytl reflexi, která by ti mohla pomoct. 
> Prosím tě, neodpovídej na ni.
>
> V.
>
>
> On 26. 02. 21 10:28, MirekZv wrote:
> > @jakub
> > Ahoj Jakube. Čteš i co jsem Ti napsal? Trochu Tě podezírám, že ne. Nebo 
> > Ti nerozumím.
> > Já to umím zkonstruovat z __file__, ale když je to v package, která je 
> > někde ve virtualenvs, tak je ve __file__ něco jiného, než si myslíš Ty.
>
>
>
>

-- 
-- 
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/be231622-e8b9-4249-b8e2-73236d2833a5n%40googlegroups.com.

Re: [django-cs] Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[MirekZv]

Create/Recreate databáze:
psql# normální uživatel z adresáře projektu
DROP DATABASE "mujprojekt";
CREATE DATABASE "mujprojekt" WITH OWNER = "mirek" ENCODING = 'UTF8';

Zálohování jsi sám zmínil: dumpdata jsou ok, jen je tam podraz, že někdy 
musíš vysedět, že nesmíš exportovat všechno.
Takže nejdřív a po zásadnějších změnách schématu odzkoušej, že loaddata 
opravdu zálohu obnoví. Pokud ne, musí dumpdata mít -e na některé tabulky 
(např. contenttype - pogoogli, které jsou problematické).

K záloze jsem potřeboval další trvale běžící stroj (kromě virtuálu u 
Forpsi), udělal jsem to takto:
neosvědčil se dropbox: nějaký problém s instalací
neosvědčil se pcloud: nelze čistě command line (potřebuje gui)
neosvědčil se megatools: Je nezávislý na mega a standardně v Debian 
distibuci, jenže mega občas upgraduje api a megatools nestíhá sledovat
osvědčil se megacmd: to je oficiální od mega
záloha jde po linii: server -> mega.nz cloud -> local (např. developer 
machine) POZOR: nic nerušit na local mašinách, aby se nesyncnulo zpětně

v cronu je pod normálním uživatelem něco jako:
@reboot sleep 30 && mega-login xxweb...@gmail.com "pwd" && mega-sync 
/home/mirek/bk/mega_xxweb_eu bk/xxweb
14 18 * * * pg_dump xxweb | gzip > /home/mirek/bk/mega_xxweb_eu/xxweb0a.gz
14 06 * * * pg_dump xxweb | gzip > /home/mirek/bk/mega_xxweb_eu/xxweb0b.gz
29 * * * * pg_dump xxweb | gzip > /home/mirek/bk/mega_xxweb_eu/xxweb1.gz
59 * * * * pg_dump xxweb | gzip > /home/mirek/bk/mega_xxweb_eu/xxweb2.gz

... nebo teda dumpdata. Jasně, toto je jen primitivní řešení narychlo.
Jinak co vím, s Postgresem se dá dělat ten WAL a při crashi dojet do stavu 
před crashem, případně i mít v provozu 2 mašiny a na druhou se 
synchronizovanou db to hned přepnout.
O tom moc nevím, jsem amatér.
Dne pátek 26. února 2021 v 11:01:54 UTC+1 uživatel MirekZv napsal:

> Postgres na Debian nainstaluji:
> sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt 
> $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
> wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | 
> sudo apt-key add -
> sudo apt update
> sudo apt install postgresql postgresql-contrib postgresql-13 
> postgresql-server-dev-13 libpq-dev python3-dev  # bez této repo, přímo z 
> debian-stable bude dost opožděná verze (11?)
>
> Pokud bych potřeboval upgradovat, držím se super návodu v tomto článku:
> https://www.kostolansky.sk/posts/upgrading-to-postgresql-12/
>
> Pak si udělám stejnojmenného uživatele s linux účtem:
> su
> su - postgres
> psql
> \password# jen když to kvůli něčemu potřebuju, např. pokud by mi 
> pro přístup z DBeaver nestačil user mirek
> create role mirek login createdb;
> alter role mirek password '';
> alter role mirek set client_encoding to 'utf8';
> alter role mirek set default_transaction_isolation to 'read committed';
> alter role mirek set timezone to 'Europe/Prague';  # v původním popisu 
> bylo 'UTC'
> create database "mirek" WITH OWNER = "mirek" ENCODING = 'UTF8';
>
> Tím mi psql poběží bez potíží i pod tím normálním uživatelem (je potřeba 
> stejnojmenná databáze, abych ji nemusel explicitně zadávat).
> Do databáze koukám přes `.manage.py shell_plus`(ze django-extensions) a 
> nebo přímo pomocí DBeaver.
> Dne pátek 26. února 2021 v 10:52:01 UTC+1 uživatel MirekZv napsal:
>
>> @stanislav
>>
>> Já jsem si 2012 ve Web2py udělal účetnictví pro občanské sdružení, který 
>> čte z FIO platby, podle VarSymb je rozděluje lidem, kámošova aplikace (C#) 
>> z toho zas tahá platby za akce.
>> Běží to na alwaysdata dlouhé roky. S SQLite.
>>
>> Takže Tvoje a moje (a jistě nejen) zkušenost je, že s SQLite se na málo 
>> zatížené produkci dá.
>> Nicméně s přechodem na Django jsem přešel striktně na Postgres, na vývoji 
>> i produkci. Dělám taky pro jednu firmu, tam je to stejné.
>> Asi bych nechtěl na vývoji SQLite a na produkci Postgres.
>>
>> Jedu všude Debian 10, bez kontejnerů.
>> Mám univerzální konfiguraci databáze takto:
>> import getpass
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.postgresql',  # případně 
>> django.contrib.gis.db.backends.postgis
>> 'NAME': PROJECT_NAME,
>> 'USER': getpass.getuser(),
>> 'PASSWORD': envget('main', 'DB_DEFAULT_PASSWORD'),
>> 'HOST': 'localhost',
>> 'PORT': 5432,
>> 'ATOMIC_REQUESTS': True,
>> 'CONN_MAX_AGE': 1800,
>> }
>> }
>>
>> Databázi tedy vytvářím pod non-root uživatelem, identickým s Debian 
>> uživatelem (při víc projektech možná uvažovat o nestejných uživatelích?).
>> Ten envget() někde načte to heslo be

Re: [django-cs] Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[MirekZv]

Postgres na Debian nainstaluji:
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release 
-cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo 
apt-key add -
sudo apt update
sudo apt install postgresql postgresql-contrib postgresql-13 
postgresql-server-dev-13 libpq-dev python3-dev  # bez této repo, přímo z 
debian-stable bude dost opožděná verze (11?)

Pokud bych potřeboval upgradovat, držím se super návodu v tomto článku:
https://www.kostolansky.sk/posts/upgrading-to-postgresql-12/

Pak si udělám stejnojmenného uživatele s linux účtem:
su
su - postgres
psql
\password# jen když to kvůli něčemu potřebuju, např. pokud by mi 
pro přístup z DBeaver nestačil user mirek
create role mirek login createdb;
alter role mirek password '';
alter role mirek set client_encoding to 'utf8';
alter role mirek set default_transaction_isolation to 'read committed';
alter role mirek set timezone to 'Europe/Prague';  # v původním popisu bylo 
'UTC'
create database "mirek" WITH OWNER = "mirek" ENCODING = 'UTF8';

Tím mi psql poběží bez potíží i pod tím normálním uživatelem (je potřeba 
stejnojmenná databáze, abych ji nemusel explicitně zadávat).
Do databáze koukám přes `.manage.py shell_plus`(ze django-extensions) a 
nebo přímo pomocí DBeaver.
Dne pátek 26. února 2021 v 10:52:01 UTC+1 uživatel MirekZv napsal:

> @stanislav
>
> Já jsem si 2012 ve Web2py udělal účetnictví pro občanské sdružení, který 
> čte z FIO platby, podle VarSymb je rozděluje lidem, kámošova aplikace (C#) 
> z toho zas tahá platby za akce.
> Běží to na alwaysdata dlouhé roky. S SQLite.
>
> Takže Tvoje a moje (a jistě nejen) zkušenost je, že s SQLite se na málo 
> zatížené produkci dá.
> Nicméně s přechodem na Django jsem přešel striktně na Postgres, na vývoji 
> i produkci. Dělám taky pro jednu firmu, tam je to stejné.
> Asi bych nechtěl na vývoji SQLite a na produkci Postgres.
>
> Jedu všude Debian 10, bez kontejnerů.
> Mám univerzální konfiguraci databáze takto:
> import getpass
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',  # případně 
> django.contrib.gis.db.backends.postgis
> 'NAME': PROJECT_NAME,
> 'USER': getpass.getuser(),
> 'PASSWORD': envget('main', 'DB_DEFAULT_PASSWORD'),
> 'HOST': 'localhost',
> 'PORT': 5432,
> 'ATOMIC_REQUESTS': True,
> 'CONN_MAX_AGE': 1800,
> }
> }
>
> Databázi tedy vytvářím pod non-root uživatelem, identickým s Debian 
> uživatelem (při víc projektech možná uvažovat o nestejných uživatelích?).
> Ten envget() někde načte to heslo bezpečným způsobem (z ENV proměnných, 
> nebo já - jak jsem psal v sousedním vlákně - to čtu přes RawConfigParser z 
> /etc/django/project.ini).
> Dne pátek 26. února 2021 v 10:34:34 UTC+1 uživatel jan.be...@gmail.com 
> napsal:
>
>> Na produkci vždy PostgreSQL (zálohování obvykle řeší někdo jiný). Na 
>> lokále pro vývoj taky PostgreSQL (puštěná v Dockeru), protože tak mám větší 
>> jistotu, že vše pojede i v produkci (SQLite není 100% kompatibilní s 
>> PostgreSQL). A je snazší si loadnout dump/zálohu produkční databáze na 
>> lokál, když je to stejný typ databáze.
>>
>> V zásadě potřebuju na lokále jen dva manage.py commandy - makemigrations 
>> a migrate. Na produkci jen migrate, který se spustí při startu aplikačního 
>> kontejneru před spuštěním webserveru.
>>
>> Přes SQL a dbshell téměř nikdy na DB nekoukám. Všechno přes Django shell 
>> (protože přetížené save metody, signály, a podobné vedlejší efekty), 
>> respektive shell_plus z Django-extensions.
>>
>> Honza
>>
>> pá 26. 2. 2021 v 10:19 odesílatel starenka .  napsal:
>>
>>> To je to jedno procento :)
>>>
>>> On Fri, Feb 26, 2021, 09:47 Jan Walter  wrote:
>>>
>>>> @starenka umis pres dbshell i zalohu?
>>>>
>>>> On Fri, 26 Feb 2021, 09:26 Vladimir Linhart,  
>>>> wrote:
>>>>
>>>>> Ja bych ten prechod na velkou DB odkladal dokud to fakt nebudes 
>>>>> potrebovat
>>>>> - db na jinem stroji
>>>>> - pomala sqlite
>>>>> - problemy se zapisem
>>>>> - chces vyuzit featury postgresu
>>>>>
>>>>> Taky pouzivam sqlite na spouste mensich projektu a to pohodli/cas ma
>>>>> velkou cenu.
>>>>>
>>>>> On Fri, Feb 26, 2021 at 9:17 AM starenka .  wrote:
>>>>> >
>>>>> > V 99% pres 'manage.py dbshell'
>>>>> >
>>>>> > On Fri, Feb 26, 2021, 08:28 Stanislav Vasko  
>>>&

Re: [django-cs] Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[MirekZv]

@stanislav

Já jsem si 2012 ve Web2py udělal účetnictví pro občanské sdružení, který 
čte z FIO platby, podle VarSymb je rozděluje lidem, kámošova aplikace (C#) 
z toho zas tahá platby za akce.
Běží to na alwaysdata dlouhé roky. S SQLite.

Takže Tvoje a moje (a jistě nejen) zkušenost je, že s SQLite se na málo 
zatížené produkci dá.
Nicméně s přechodem na Django jsem přešel striktně na Postgres, na vývoji i 
produkci. Dělám taky pro jednu firmu, tam je to stejné.
Asi bych nechtěl na vývoji SQLite a na produkci Postgres.

Jedu všude Debian 10, bez kontejnerů.
Mám univerzální konfiguraci databáze takto:
import getpass
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql',  # případně 
django.contrib.gis.db.backends.postgis
'NAME': PROJECT_NAME,
'USER': getpass.getuser(),
'PASSWORD': envget('main', 'DB_DEFAULT_PASSWORD'),
'HOST': 'localhost',
'PORT': 5432,
'ATOMIC_REQUESTS': True,
'CONN_MAX_AGE': 1800,
}
}

Databázi tedy vytvářím pod non-root uživatelem, identickým s Debian 
uživatelem (při víc projektech možná uvažovat o nestejných uživatelích?).
Ten envget() někde načte to heslo bezpečným způsobem (z ENV proměnných, 
nebo já - jak jsem psal v sousedním vlákně - to čtu přes RawConfigParser z 
/etc/django/project.ini).
Dne pátek 26. února 2021 v 10:34:34 UTC+1 uživatel jan.be...@gmail.com 
napsal:

> Na produkci vždy PostgreSQL (zálohování obvykle řeší někdo jiný). Na 
> lokále pro vývoj taky PostgreSQL (puštěná v Dockeru), protože tak mám větší 
> jistotu, že vše pojede i v produkci (SQLite není 100% kompatibilní s 
> PostgreSQL). A je snazší si loadnout dump/zálohu produkční databáze na 
> lokál, když je to stejný typ databáze.
>
> V zásadě potřebuju na lokále jen dva manage.py commandy - makemigrations a 
> migrate. Na produkci jen migrate, který se spustí při startu aplikačního 
> kontejneru před spuštěním webserveru.
>
> Přes SQL a dbshell téměř nikdy na DB nekoukám. Všechno přes Django shell 
> (protože přetížené save metody, signály, a podobné vedlejší efekty), 
> respektive shell_plus z Django-extensions.
>
> Honza
>
> pá 26. 2. 2021 v 10:19 odesílatel starenka .  napsal:
>
>> To je to jedno procento :)
>>
>> On Fri, Feb 26, 2021, 09:47 Jan Walter  wrote:
>>
>>> @starenka umis pres dbshell i zalohu?
>>>
>>> On Fri, 26 Feb 2021, 09:26 Vladimir Linhart,  
>>> wrote:
>>>
 Ja bych ten prechod na velkou DB odkladal dokud to fakt nebudes 
 potrebovat
 - db na jinem stroji
 - pomala sqlite
 - problemy se zapisem
 - chces vyuzit featury postgresu

 Taky pouzivam sqlite na spouste mensich projektu a to pohodli/cas ma
 velkou cenu.

 On Fri, Feb 26, 2021 at 9:17 AM starenka .  wrote:
 >
 > V 99% pres 'manage.py dbshell'
 >
 > On Fri, Feb 26, 2021, 08:28 Stanislav Vasko  
 wrote:
 >>
 >> Díky všem za reakci. Osobně jsem se na produkci také nikdy nevracel, 
 ale tak ještě to důležité:
 >>
 >> DB spravujete přes DB aplikaci, extra, nebo jsou v Django na to 
 příkazy, jako jsem uváděl níže?
 >>
 >> Standa
 >>
 >>
 >> On 26 February 2021 at 1:24:18, starenka . (star...@gmail.com) 
 wrote:
 >>
 >> Messa: session muze mit x backendu, samorejme se cachuje atd. bylo 
 mi jasny uz pri psani, ze budes kejhat :)
 >>
 >> Slo o zdurazneni pointu, ze sqlite imo na produkci neceho min nez 
 toy projektu nema co delat...
 >>
 >> On Fri, Feb 26, 2021, 01:11 Petr Messner  
 wrote:
 >>>
 >>> pá 26. 2. 2021 v 0:51 odesílatel starenka .  
 napsal:
 
  Souhlasim s Honou a este bych rad upozornil, ze sqlite (pokud je 
 mi znamo) nepodoruje (narozdil od cteni) simultani zapis a tedy kdyz do ni 
 jeden worker/proces zapisuje, je databaze locknuta na zapis a ty cekaji ve 
 fronte (cteni je behem zapisu ok). Vzhledem k tomu, ze se do db zapisuje i 
 "mimo tvuj kod" (napr. session), neni to asi obecne idealni reseni pro 
 vytizenejsi appky.
 >>>
 >>>
 >>>
 >>> Je to v praxi (u menších aplikací) opravdu problém? I ve WAL módu?
 >>> https://sqlite.org/wal.html
 >>>
 >>> Jestli i obyčejný read-only přístup do session znamená nějaký zápis 
 do db, tak to možná není ideální a dá se to řešit několika způsoby. Ale 
 dobrý point, někdy je třeba na toto myslet.
 >>>
 >>> Petr M.
 >>>
 >>>
 >>> --
 >>> --
 >>> 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 
 

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@Honza(jan.be..)
Ahoj. Já jsem django-environ snad trochu používal (už si přesně 
nepamatuju), ale protože to zatím nedávám nikam do cloudu, ale na virtuální 
server, tak jsem nakonec ENV proměnné, aspoň prozatím, úplně opustil.
Používám místo toho klasický ini file, někde v /etc/django/myproject.ini, 
který čtu pomocí RawConfigParser ze standardní knihovny.

Dne pátek 26. února 2021 v 10:28:02 UTC+1 uživatel MirekZv napsal:

> @jakub
> Ahoj Jakube. Čteš i co jsem Ti napsal? Trochu Tě podezírám, že ne. Nebo Ti 
> nerozumím.
> Já to umím zkonstruovat z __file__, ale když je to v package, která je 
> někde ve virtualenvs, tak je ve __file__ něco jiného, než si myslíš Ty.
>
> Dne čtvrtek 25. února 2021 v 14:59:21 UTC+1 uživatel jakub@gmail.com 
> napsal:
>
>> Ve __file__ je i cesta v modulu. Takze ja jsem si to konstruoval napr v 
>> settings. 
>>
>> On Mon, Feb 22, 2021 at 8:14 PM MirekZv  wrote:
>>
>>> @honza
>>>
>>> S pydanny/cookiecutterem jsem dělal.
>>> Je to super, pokud člověk potřebuje zjistit, jak uspořádat projekt, jaká 
>>> udělat nastavení a jak je udělat. Pro nějakého samotáře asi skoro jediná 
>>> možnost, jak prakticky začít.
>>> Pokud jsi někde ve firmě, máš navíc možnost obšlehnout firemní 
>>> uspořádání, jak si ho za léta na nějakých jiných projektech vymazlili.
>>>
>>> Ale cookiecutter zas jen rozkopírovává šablonu do projektu. Není to 
>>> reuse. Já chci reuse. Nechci to mít 4x a těkat mezi projekty, jestli už 
>>> jsem i v tomhle implementoval to vylepšení, co jsem udělal v jiném.
>>> Jasně, u settings je diskutabilní, jestli si budou mezi projekty podobné 
>>> nebo ne. Můj názor je, že django je natolik brutálně (nechci psát: 
>>> nadbytečně) konfigurovatelné, že většinou pojedeš se stejnými nebo velmi 
>>> podobnými nastaveními. Proto reuse, ne rozkopírování načtyřikrát.
>>>
>>> @jakub
>>>
>>> Jasně. Ale __file__ je ten soubor, jehož kód právě běží. Pokud je tento 
>>> soubor mimo strom projektu, tak z __file__ nic nezjistíš. Abys měl nějaké 
>>> příklady:
>>> $HOME/.virtualenvs/
>>> $HOME/.cache/pypoetry/virtualenvs/
>>> apod.
>>>
>>> @radim
>>>
>>> Ty se tam dotýkáš jedné věci, která mě zajímá, ale teď s tím nebudu 
>>> otravovat. Potřebuju už na těch projektech taky popojet, ale časem se asi k 
>>> tomu zeptám.
>>>
>>> Díky všem.
>>> Dne pondělí 22. února 2021 v 16:33:15 UTC+1 uživatel honza...@gmail.com 
>>> napsal:
>>>
>>>> Jedna z nejvetsich vyhod Djanga je jeho rozsahly ekosystem. Jak uz tady 
>>>> psalo nekolik lidi tak tohle je vyreseny problem. Nez vymyslet vlastni 
>>>> reseni, doporucil bych sahnout k nejake existujici sablone. Ja mam treba 
>>>> rad https://github.com/pydanny/cookiecutter-django ze ktere jsem 
>>>> odvodil i svuj soucasny velky projekt. Resi vsechno vcetne nasazeni do 
>>>> dockeru pokud o to budes stat.
>>>>
>>>>
>>>> Honza Král
>>>> E-Mail: honza...@gmail.com
>>>> Phone:  +420 606 678585 <+420%20606%20678%20585>
>>>>
>>>>
>>>> On Mon, Feb 22, 2021 at 4:30 PM Radim Novotny  
>>>> wrote:
>>>>
>>>>> Já mám součástí deploymentu (Ansible) nastavení environment var, která 
>>>>> obsahuje cestu, kam se to celé nainstalovalo. 
>>>>> Ostatní settings se odvozují od toho, takže třeba 
>>>>>
>>>>> PROJECT_ROOT = os.environ.get('DJANGO_PROJECT_ROOT')
>>>>> STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
>>>>>
>>>>> Navíc tam je i kontrola, aby to fakt bylo nastavený, takže v 
>>>>> settings.py je  
>>>>> if not PROJECT_ROOT:
>>>>> raise ImproperlyConfigured('Environment variable 
>>>>> DJANGO_PROJECT_ROOT is not defined.')
>>>>>
>>>>> Neřeší se, kde je nainstalovaný samotný kód aplikace (python package), 
>>>>> jestli je to venv/src/ nebo venv/lib/python. To mne už samořejmě 
>>>>> nezajímá. 
>>>>> Pokud by mne to zajímalo, použiju __file__.
>>>>>
>>>>> Co se týká rozdělení settings, tak je fakt, že jich mám hodně a 
>>>>> postupně se importují. Deployment je zatím vždy na Debian a development 
>>>>> je 
>>>>> na Dockeru, takže je to takový šroubovaný, ale všechno je to podchycené 
>>>>> buď 
>>>>> v Ansible deploymentu a nebo v

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@jakub
Ahoj Jakube. Čteš i co jsem Ti napsal? Trochu Tě podezírám, že ne. Nebo Ti 
nerozumím.
Já to umím zkonstruovat z __file__, ale když je to v package, která je 
někde ve virtualenvs, tak je ve __file__ něco jiného, než si myslíš Ty.

Dne čtvrtek 25. února 2021 v 14:59:21 UTC+1 uživatel jakub@gmail.com 
napsal:

> Ve __file__ je i cesta v modulu. Takze ja jsem si to konstruoval napr v 
> settings. 
>
> On Mon, Feb 22, 2021 at 8:14 PM MirekZv  wrote:
>
>> @honza
>>
>> S pydanny/cookiecutterem jsem dělal.
>> Je to super, pokud člověk potřebuje zjistit, jak uspořádat projekt, jaká 
>> udělat nastavení a jak je udělat. Pro nějakého samotáře asi skoro jediná 
>> možnost, jak prakticky začít.
>> Pokud jsi někde ve firmě, máš navíc možnost obšlehnout firemní 
>> uspořádání, jak si ho za léta na nějakých jiných projektech vymazlili.
>>
>> Ale cookiecutter zas jen rozkopírovává šablonu do projektu. Není to 
>> reuse. Já chci reuse. Nechci to mít 4x a těkat mezi projekty, jestli už 
>> jsem i v tomhle implementoval to vylepšení, co jsem udělal v jiném.
>> Jasně, u settings je diskutabilní, jestli si budou mezi projekty podobné 
>> nebo ne. Můj názor je, že django je natolik brutálně (nechci psát: 
>> nadbytečně) konfigurovatelné, že většinou pojedeš se stejnými nebo velmi 
>> podobnými nastaveními. Proto reuse, ne rozkopírování načtyřikrát.
>>
>> @jakub
>>
>> Jasně. Ale __file__ je ten soubor, jehož kód právě běží. Pokud je tento 
>> soubor mimo strom projektu, tak z __file__ nic nezjistíš. Abys měl nějaké 
>> příklady:
>> $HOME/.virtualenvs/
>> $HOME/.cache/pypoetry/virtualenvs/
>> apod.
>>
>> @radim
>>
>> Ty se tam dotýkáš jedné věci, která mě zajímá, ale teď s tím nebudu 
>> otravovat. Potřebuju už na těch projektech taky popojet, ale časem se asi k 
>> tomu zeptám.
>>
>> Díky všem.
>> Dne pondělí 22. února 2021 v 16:33:15 UTC+1 uživatel honza...@gmail.com 
>> napsal:
>>
>>> Jedna z nejvetsich vyhod Djanga je jeho rozsahly ekosystem. Jak uz tady 
>>> psalo nekolik lidi tak tohle je vyreseny problem. Nez vymyslet vlastni 
>>> reseni, doporucil bych sahnout k nejake existujici sablone. Ja mam treba 
>>> rad https://github.com/pydanny/cookiecutter-django ze ktere jsem 
>>> odvodil i svuj soucasny velky projekt. Resi vsechno vcetne nasazeni do 
>>> dockeru pokud o to budes stat.
>>>
>>>
>>> Honza Král
>>> E-Mail: honza...@gmail.com
>>> Phone:  +420 606 678585 <+420%20606%20678%20585>
>>>
>>>
>>> On Mon, Feb 22, 2021 at 4:30 PM Radim Novotny  
>>> wrote:
>>>
>>>> Já mám součástí deploymentu (Ansible) nastavení environment var, která 
>>>> obsahuje cestu, kam se to celé nainstalovalo. 
>>>> Ostatní settings se odvozují od toho, takže třeba 
>>>>
>>>> PROJECT_ROOT = os.environ.get('DJANGO_PROJECT_ROOT')
>>>> STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
>>>>
>>>> Navíc tam je i kontrola, aby to fakt bylo nastavený, takže v 
>>>> settings.py je  
>>>> if not PROJECT_ROOT:
>>>> raise ImproperlyConfigured('Environment variable 
>>>> DJANGO_PROJECT_ROOT is not defined.')
>>>>
>>>> Neřeší se, kde je nainstalovaný samotný kód aplikace (python package), 
>>>> jestli je to venv/src/ nebo venv/lib/python. To mne už samořejmě nezajímá. 
>>>> Pokud by mne to zajímalo, použiju __file__.
>>>>
>>>> Co se týká rozdělení settings, tak je fakt, že jich mám hodně a 
>>>> postupně se importují. Deployment je zatím vždy na Debian a development je 
>>>> na Dockeru, takže je to takový šroubovaný, ale všechno je to podchycené 
>>>> buď 
>>>> v Ansible deploymentu a nebo v konfiguraci Dockeru.
>>>>
>>>> Možná ale vlastně potřebuješ úplně něco jinýho :) Přiznávám se, že jsem 
>>>> se v tom moc nezorientoval.
>>>>
>>>> Radim
>>>>
>>>> On Mon, Feb 22, 2021 at 4:04 PM Jakub Vysoky  
>>>> wrote:
>>>>
>>>>> Spis pouzij `__file__`
>>>>>
>>>>> V `settings.py` si z toho udelat `BASE_DIR` jak pises. `PROJECT_NAME` 
>>>>> bych ja osobne spis napsal natvrdo, nez takhle magicky odvozoval.
>>>>>
>>>>> Na zorganizovani Django settings je vicero projektu a ja momentalne 
>>>>> nejsem Django mega aktivni, takze nebudu konkretni doporucovat.
>>>>>
>>>>> On Mon, Fe

[django-cs] Jak co nejlépe a obecně na popupy?

[MirekZv]

Mám ne moc minimalistické, ale pro reálné projekty nutné požadavky na 
popupy (select+options) ve formulářích:
1. ajaxem získávané options (mimo admin i v něm) - všude a vždy, i když 
kdyby to umělo automaticky vypnout, když je v modelu méně než např. 100 
položek, nevadilo by,
2. dynamický filtr pro options, zejména když jsou relačně závislé popupy 
(opět mimo admin i v adminu, včetně inlinů); příklad: country & city: jen 
cities z vybrané country mají být na výběr.

Implementoval jsem toto
https://simpleisbetterthancomplex.com/tutorial/2018/01/29/how-to-implement-dependent-or-chained-dropdown-list-with-django.html
včetně funkcionality (2) v inlinech a dokážu to zprovoznit.

Ale je zatím dost individuální práce pro každý případ, lepší by bylo něco 
generického.
A neřeší to ten ajax.

Je nějaká rozumná cesta, jak dosáhnout (1)+(2) všude v aplikaci?
Které packages přidat do projektu? django-autocomplete-light? a ještě něco?

Díky...
PS: samozřejmě, když jsem šel na Django, tak jsem se domníval, že tam jdu 
proto, že takovéto věci dělá out-of-the-box. Ach ta moje naivita.

Best regards,
Mirek

-- 
-- 
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/d1743ed4-73cb-4a1b-b305-b4d6c83920afn%40googlegroups.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[MirekZv]

@Standa

>
Nevím o tom zatím nic.
Tady je nějaké video, které bych si já chtěl zkouknout. 
https://www.youtube.com/watch?v=3eTtVY7duJk
A pak se samozřejmě proberu názory ostatních, co napsali sem.

-- 
-- 
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/5b9f9231-fdda-4bbc-82c8-4c3f7efd36aen%40googlegroups.com.

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@honza

S pydanny/cookiecutterem jsem dělal.
Je to super, pokud člověk potřebuje zjistit, jak uspořádat projekt, jaká 
udělat nastavení a jak je udělat. Pro nějakého samotáře asi skoro jediná 
možnost, jak prakticky začít.
Pokud jsi někde ve firmě, máš navíc možnost obšlehnout firemní uspořádání, 
jak si ho za léta na nějakých jiných projektech vymazlili.

Ale cookiecutter zas jen rozkopírovává šablonu do projektu. Není to reuse. 
Já chci reuse. Nechci to mít 4x a těkat mezi projekty, jestli už jsem i v 
tomhle implementoval to vylepšení, co jsem udělal v jiném.
Jasně, u settings je diskutabilní, jestli si budou mezi projekty podobné 
nebo ne. Můj názor je, že django je natolik brutálně (nechci psát: 
nadbytečně) konfigurovatelné, že většinou pojedeš se stejnými nebo velmi 
podobnými nastaveními. Proto reuse, ne rozkopírování načtyřikrát.

@jakub

Jasně. Ale __file__ je ten soubor, jehož kód právě běží. Pokud je tento 
soubor mimo strom projektu, tak z __file__ nic nezjistíš. Abys měl nějaké 
příklady:
$HOME/.virtualenvs/
$HOME/.cache/pypoetry/virtualenvs/
apod.

@radim

Ty se tam dotýkáš jedné věci, která mě zajímá, ale teď s tím nebudu 
otravovat. Potřebuju už na těch projektech taky popojet, ale časem se asi k 
tomu zeptám.

Díky všem.
Dne pondělí 22. února 2021 v 16:33:15 UTC+1 uživatel honza...@gmail.com 
napsal:

> Jedna z nejvetsich vyhod Djanga je jeho rozsahly ekosystem. Jak uz tady 
> psalo nekolik lidi tak tohle je vyreseny problem. Nez vymyslet vlastni 
> reseni, doporucil bych sahnout k nejake existujici sablone. Ja mam treba 
> rad https://github.com/pydanny/cookiecutter-django ze ktere jsem odvodil 
> i svuj soucasny velky projekt. Resi vsechno vcetne nasazeni do dockeru 
> pokud o to budes stat.
>
>
> Honza Král
> E-Mail: honza...@gmail.com
> Phone:  +420 606 678585 <+420%20606%20678%20585>
>
>
> On Mon, Feb 22, 2021 at 4:30 PM Radim Novotny  wrote:
>
>> Já mám součástí deploymentu (Ansible) nastavení environment var, která 
>> obsahuje cestu, kam se to celé nainstalovalo. 
>> Ostatní settings se odvozují od toho, takže třeba 
>>
>> PROJECT_ROOT = os.environ.get('DJANGO_PROJECT_ROOT')
>> STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
>>
>> Navíc tam je i kontrola, aby to fakt bylo nastavený, takže v settings.py 
>> je  
>> if not PROJECT_ROOT:
>> raise ImproperlyConfigured('Environment variable DJANGO_PROJECT_ROOT 
>> is not defined.')
>>
>> Neřeší se, kde je nainstalovaný samotný kód aplikace (python package), 
>> jestli je to venv/src/ nebo venv/lib/python. To mne už samořejmě nezajímá. 
>> Pokud by mne to zajímalo, použiju __file__.
>>
>> Co se týká rozdělení settings, tak je fakt, že jich mám hodně a postupně 
>> se importují. Deployment je zatím vždy na Debian a development je na 
>> Dockeru, takže je to takový šroubovaný, ale všechno je to podchycené buď v 
>> Ansible deploymentu a nebo v konfiguraci Dockeru.
>>
>> Možná ale vlastně potřebuješ úplně něco jinýho :) Přiznávám se, že jsem 
>> se v tom moc nezorientoval.
>>
>> Radim
>>
>> On Mon, Feb 22, 2021 at 4:04 PM Jakub Vysoky  wrote:
>>
>>> Spis pouzij `__file__`
>>>
>>> V `settings.py` si z toho udelat `BASE_DIR` jak pises. `PROJECT_NAME` 
>>> bych ja osobne spis napsal natvrdo, nez takhle magicky odvozoval.
>>>
>>> Na zorganizovani Django settings je vicero projektu a ja momentalne 
>>> nejsem Django mega aktivni, takze nebudu konkretni doporucovat.
>>>
>>> On Mon, Feb 22, 2021 at 3:22 PM MirekZv  wrote:
>>>
>>>> Závěr: Nakonec jsem se příliš bál toho `os.getcwd()` a udělal jsem si 
>>>> tuto funkci:
>>>> ```
>>>> import inspect
>>>> import os
>>>> from pathlib import Path
>>>>
>>>> def get_project_root():
>>>> for prg in inspect.stack()[::-1]:
>>>> prg = prg.filename
>>>> if '/wsgi.py' in prg or '/asgi.py' in prg:
>>>> return Path(prg).parent.parent
>>>> elif '/manage.py' in prg:
>>>> return Path(prg).parent
>>>> else:
>>>> return Path(os.getcwd())
>>>>
>>>> BASE_DIR = get_project_root()
>>>> PROJECT_NAME = BASE_DIR.name   # to make some settings portable 
>>>> (DATABASES=..)
>>>> PROJECT_DIR = BASE_DIR / PROJECT_NAME
>>>> ```
>>>>
>>>> Dne pondělí 22. února 2021 v 15:18:01 UTC+1 uživatel MirekZv napsal:
>>>>
>>>>> @Honza, @starenka
>>>>>
>>>>> Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

Závěr: Nakonec jsem se příliš bál toho `os.getcwd()` a udělal jsem si tuto 
funkci:
```
import inspect
import os
from pathlib import Path

def get_project_root():
for prg in inspect.stack()[::-1]:
prg = prg.filename
if '/wsgi.py' in prg or '/asgi.py' in prg:
return Path(prg).parent.parent
elif '/manage.py' in prg:
return Path(prg).parent
else:
return Path(os.getcwd())

BASE_DIR = get_project_root()
PROJECT_NAME = BASE_DIR.name   # to make some settings portable 
(DATABASES=..)
PROJECT_DIR = BASE_DIR / PROJECT_NAME
```

Dne pondělí 22. února 2021 v 15:18:01 UTC+1 uživatel MirekZv napsal:

> @Honza, @starenka
>
> Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem spíš, 
> že po této otázce už na mě někdo vlítne a pěkně mi vynadá.
>
> Jo, máte přesně pravdu, bylo by to asi lepší (získat to v umístění 
> projektu a předat to nějakým parametrem), než účelu nepřiměřené úsilí, co 
> se s tím snažím dělat.
>
> Přidám nějakou story, jak jsem se do té situace dostal, snad z toho bude 
> něco jasnější, i když osobně jsem nad svým postupem dost na rozpacích:
>
> 1. Nejdřív jsem copy/pastoval ze starého projektu pro vytvoření nového, 
> jak se to asi běžně dělá.
> 2. Pak jsem začal myslet na nějaký reuse, tak jsem si udělal jednu django 
> aplikaci na věci, které by asi byly potřebné ve 2+ projektech.
> 3. Pak mě začalo štvát, že tu aplikaci mám pod jednotlivými projekty, 
> takže když ji někde změním, neměl bych zapomenout jít i do těch ostatních 
> projektů a udělat v ní stejné změny i tam.
> 4. Pak jsem tu django aplikaci obecností odkopíroval do adresáře mimo, 
> udělal jí vlastní git repozitář, a instaluji ji nějak jako `poetry add 
> ../../obecna`
> 5. Pak mě začalo štvát, že běžná django settings mají tak 200 řádek kódu, 
> stejně jsou vždycky skoro stejná, a když tam něco vylepším, tak zas abych 
> šel po projektech a implementoval vylepšení i do ostatních (a nebo v tom 
> měl chaos).
> 6. Pak jsem si zkusil jakési django-split-settings, rozdělil ten mega-file 
> na 10 malých (vypadá to dobře, ale o vhodnosti tohoto mám velké pochyby, 
> protože to už jsme možná trochu u zacházení s jmennými prostory jako ve 
> Web2py).
> 7. Pak jsem většinu nastavení přepsal tak, aby byla obecná, bez závislostí 
> na projektu. Příklad: Nemám důvod, proč by se moje postgres databáze neměla 
> jmenovat stejně jako projekt. Tak proč psát do nastavení natvrdo jméno 
> databáze? - toto je další věc, kterou na Djangu nemám rád, že když dělá 
> startproject, tak rozkopíruje po x souborech na y míst jméno projektu jako 
> string.
> 8. Pak jsem (ze stejných důvodů jako výše) to odsunul mimo ty mé projekty.
>
> Takže: mohl bych si to nastavit v projektech a předat jako parametr. Ale 
> čím míň toho zůstane customizovaného pro projekty, tím lépe.
> Navíc to django-split-settings se volá pomocí jakýchsi funkcí include() a 
> optional() a nejsem si tak úplně jistý, jak snadno tam jdou parametry 
> předávat.
>
> Dne pondělí 22. února 2021 v 14:58:03 UTC+1 uživatel MirekZv napsal:
>
>> @John
>>
>> Jo, zase jsem horlivější než je vhodné.
>> Nemyslel jsem to tak, že já sám chci mít na stagingu/produkci/.. různá 
>> prostředí.
>> Myslel jsem to tak, že kdyby se to někdy z nějakých nyní neznámých důvodů 
>> ocitlo pod jiným prostředím (např. na různých cloudech), aby to chodilo.
>> Čili přehnaná snaha o obecnost, která se nakonec skoro vždycky spíš 
>> vymstí.
>>
>> Jinak vyvíjím i nasazuji na poslední Debian, takže vlastně skoro 
>> identické prostředí na vývoji i produkci.
>> Díky tedy za doporučení dockeru, já už jsem si s ním kdysi pohrával, ale 
>> zjistil jsem, že pro laika to zas tak ultrasnadné není,
>> pak se mi zdá, že to docela žere místo na disku (zvlášť když tam 
>> zapomeneš něco nesmazaného z předchozích pokusů), což při nasazování na 
>> (cizí=veřejný) virtuální server je dost zásadní,
>> a pak, když to jedu vše na Debianu, tak by ten přínos zas tak zásadní 
>> nebyl.
>> Takže Docker je zatím odložen.
>>
>> Dne pátek 19. února 2021 v 22:59:35 UTC+1 uživatel starenka napsal:
>>
>>> A kdyz to teda volas z toho prokektu, proc to ty fci v tom modulu 
>>> nepredas jako arg? 
>>>
>>>
>>> On Fri, Feb 19, 2021, 22:51 Jan Bednařík  wrote:
>>>
>>>> A nemůžeš mít název toho projektu jako konstantu přímo v settings? 
>>>> Zjišťovat to z názvu adresáře mi přijde příliš křehké.
>>>>
>>>> A Sites znáš? to je takovej dobrej způsob, jak pracovat s více projekty 
>>>> / instalacemi / weby v jedné code base: 
>>>> https://docs.djangoproject.com/en/3.1/ref/contrib/sites/
>

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@Honza, @starenka

Ahoj chlapi, především díky za vlídné a věcné odpovědi, čekal jsem spíš, že 
po této otázce už na mě někdo vlítne a pěkně mi vynadá.

Jo, máte přesně pravdu, bylo by to asi lepší (získat to v umístění projektu 
a předat to nějakým parametrem), než účelu nepřiměřené úsilí, co se s tím 
snažím dělat.

Přidám nějakou story, jak jsem se do té situace dostal, snad z toho bude 
něco jasnější, i když osobně jsem nad svým postupem dost na rozpacích:

1. Nejdřív jsem copy/pastoval ze starého projektu pro vytvoření nového, jak 
se to asi běžně dělá.
2. Pak jsem začal myslet na nějaký reuse, tak jsem si udělal jednu django 
aplikaci na věci, které by asi byly potřebné ve 2+ projektech.
3. Pak mě začalo štvát, že tu aplikaci mám pod jednotlivými projekty, takže 
když ji někde změním, neměl bych zapomenout jít i do těch ostatních 
projektů a udělat v ní stejné změny i tam.
4. Pak jsem tu django aplikaci obecností odkopíroval do adresáře mimo, 
udělal jí vlastní git repozitář, a instaluji ji nějak jako `poetry add 
../../obecna`
5. Pak mě začalo štvát, že běžná django settings mají tak 200 řádek kódu, 
stejně jsou vždycky skoro stejná, a když tam něco vylepším, tak zas abych 
šel po projektech a implementoval vylepšení i do ostatních (a nebo v tom 
měl chaos).
6. Pak jsem si zkusil jakési django-split-settings, rozdělil ten mega-file 
na 10 malých (vypadá to dobře, ale o vhodnosti tohoto mám velké pochyby, 
protože to už jsme možná trochu u zacházení s jmennými prostory jako ve 
Web2py).
7. Pak jsem většinu nastavení přepsal tak, aby byla obecná, bez závislostí 
na projektu. Příklad: Nemám důvod, proč by se moje postgres databáze neměla 
jmenovat stejně jako projekt. Tak proč psát do nastavení natvrdo jméno 
databáze? - toto je další věc, kterou na Djangu nemám rád, že když dělá 
startproject, tak rozkopíruje po x souborech na y míst jméno projektu jako 
string.
8. Pak jsem (ze stejných důvodů jako výše) to odsunul mimo ty mé projekty.

Takže: mohl bych si to nastavit v projektech a předat jako parametr. Ale 
čím míň toho zůstane customizovaného pro projekty, tím lépe.
Navíc to django-split-settings se volá pomocí jakýchsi funkcí include() a 
optional() a nejsem si tak úplně jistý, jak snadno tam jdou parametry 
předávat.

Dne pondělí 22. února 2021 v 14:58:03 UTC+1 uživatel MirekZv napsal:

> @John
>
> Jo, zase jsem horlivější než je vhodné.
> Nemyslel jsem to tak, že já sám chci mít na stagingu/produkci/.. různá 
> prostředí.
> Myslel jsem to tak, že kdyby se to někdy z nějakých nyní neznámých důvodů 
> ocitlo pod jiným prostředím (např. na různých cloudech), aby to chodilo.
> Čili přehnaná snaha o obecnost, která se nakonec skoro vždycky spíš vymstí.
>
> Jinak vyvíjím i nasazuji na poslední Debian, takže vlastně skoro identické 
> prostředí na vývoji i produkci.
> Díky tedy za doporučení dockeru, já už jsem si s ním kdysi pohrával, ale 
> zjistil jsem, že pro laika to zas tak ultrasnadné není,
> pak se mi zdá, že to docela žere místo na disku (zvlášť když tam zapomeneš 
> něco nesmazaného z předchozích pokusů), což při nasazování na 
> (cizí=veřejný) virtuální server je dost zásadní,
> a pak, když to jedu vše na Debianu, tak by ten přínos zas tak zásadní 
> nebyl.
> Takže Docker je zatím odložen.
>
> Dne pátek 19. února 2021 v 22:59:35 UTC+1 uživatel starenka napsal:
>
>> A kdyz to teda volas z toho prokektu, proc to ty fci v tom modulu 
>> nepredas jako arg? 
>>
>>
>> On Fri, Feb 19, 2021, 22:51 Jan Bednařík  wrote:
>>
>>> A nemůžeš mít název toho projektu jako konstantu přímo v settings? 
>>> Zjišťovat to z názvu adresáře mi přijde příliš křehké.
>>>
>>> A Sites znáš? to je takovej dobrej způsob, jak pracovat s více projekty 
>>> / instalacemi / weby v jedné code base: 
>>> https://docs.djangoproject.com/en/3.1/ref/contrib/sites/
>>>
>>> Honza
>>>
>>> pá 19. 2. 2021 v 19:50 odesílatel Jan Walter  napsal:
>>>
>>>> Asi nejsem sto se přesně naladit na charakter Tvého problému, ale pokud 
>>>> mohu poradit obecně, snažil bych se vystříhat tomu, aby "bylo na produkci 
>>>> pokaždé něco jinak".
>>>>
>>>> My v partě máme oblíbený docker, což je technologie využitelná např. na 
>>>> to, aby bylo, pokud možno, "všude všechno v základu stejně". Doporučuji 
>>>> Tvé 
>>>> pozornosti.
>>>>
>>>> John
>>>>
>>>> On Fri, 19 Feb 2021, 19:32 MirekZv,  wrote:
>>>>
>>>>> Běží mi kód ve stacku projektu,
>>>>> ale dotyčný soubor se nachází mimo adresář projektu.
>>>>> Jak bych zjistil jméno projektu?
>>>>>
>>>>> Abych to trochu vysvětlil:
>>>>> V běžných

Re: [django-cs] Jak zjistit jméno projektu

[MirekZv]

@John

Jo, zase jsem horlivější než je vhodné.
Nemyslel jsem to tak, že já sám chci mít na stagingu/produkci/.. různá 
prostředí.
Myslel jsem to tak, že kdyby se to někdy z nějakých nyní neznámých důvodů 
ocitlo pod jiným prostředím (např. na různých cloudech), aby to chodilo.
Čili přehnaná snaha o obecnost, která se nakonec skoro vždycky spíš vymstí.

Jinak vyvíjím i nasazuji na poslední Debian, takže vlastně skoro identické 
prostředí na vývoji i produkci.
Díky tedy za doporučení dockeru, já už jsem si s ním kdysi pohrával, ale 
zjistil jsem, že pro laika to zas tak ultrasnadné není,
pak se mi zdá, že to docela žere místo na disku (zvlášť když tam zapomeneš 
něco nesmazaného z předchozích pokusů), což při nasazování na 
(cizí=veřejný) virtuální server je dost zásadní,
a pak, když to jedu vše na Debianu, tak by ten přínos zas tak zásadní nebyl.
Takže Docker je zatím odložen.

Dne pátek 19. února 2021 v 22:59:35 UTC+1 uživatel starenka napsal:

> A kdyz to teda volas z toho prokektu, proc to ty fci v tom modulu nepredas 
> jako arg? 
>
>
> On Fri, Feb 19, 2021, 22:51 Jan Bednařík  wrote:
>
>> A nemůžeš mít název toho projektu jako konstantu přímo v settings? 
>> Zjišťovat to z názvu adresáře mi přijde příliš křehké.
>>
>> A Sites znáš? to je takovej dobrej způsob, jak pracovat s více projekty / 
>> instalacemi / weby v jedné code base: 
>> https://docs.djangoproject.com/en/3.1/ref/contrib/sites/
>>
>> Honza
>>
>> pá 19. 2. 2021 v 19:50 odesílatel Jan Walter  napsal:
>>
>>> Asi nejsem sto se přesně naladit na charakter Tvého problému, ale pokud 
>>> mohu poradit obecně, snažil bych se vystříhat tomu, aby "bylo na produkci 
>>> pokaždé něco jinak".
>>>
>>> My v partě máme oblíbený docker, což je technologie využitelná např. na 
>>> to, aby bylo, pokud možno, "všude všechno v základu stejně". Doporučuji Tvé 
>>> pozornosti.
>>>
>>> John
>>>
>>> On Fri, 19 Feb 2021, 19:32 MirekZv,  wrote:
>>>
>>>> Běží mi kód ve stacku projektu,
>>>> ale dotyčný soubor se nachází mimo adresář projektu.
>>>> Jak bych zjistil jméno projektu?
>>>>
>>>> Abych to trochu vysvětlil:
>>>> V běžných django settings se řeší přesně toto, co potřebuju, třeba 
>>>> nějak přibližně takto:
>>>> BASE_DIR = Path(__file__).resolve().parent.parent
>>>> PROJECT_NAME = BASE_DIR.name
>>>>
>>>> Potřebuju totéž zjistit v souboru, který není v BASE_DIR.
>>>> A to tak, že nechci nic nastavovat nikde v souborech pod BASE_DIR.
>>>>
>>>> Napadají mě 2 možnosti:
>>>> - zjistit to nějak z inspect.stack() --ale nevím, jak to udělat dost 
>>>> bezpečně
>>>> - vzít jenom os.getcwd() --za předpokladu, že mám úplně standardní 
>>>> projekt, se stejným jménem rootu i adresáře projektu
>>>>
>>>> Zatím jsem se spokojil s tím posledním.
>>>> Myslíte, že by na to mohl být spoleh ve všech variantách na produkci?
>>>>
>>>> Alternativně: Dá se nějak snadno zjistit z kódu settings file (protože 
>>>> ten mám pod projektem; nebo prostě jakýkoli file, který je bezpečně pod 
>>>> adresářem projektu (např. ve stacku mám jako první manage.py, jenže to asi 
>>>> na produkci bude pokaždé jinak).
>>>>
>>>> Díky, tedy kdyby někdo věděl.
>>>>
>>>> -- 
>>>> -- 
>>>> 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/2c569772-cc17-437d-80ec-0411a0207c33n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-cs/2c569772-cc17-437d-80ec-0411a0207c33n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>>> -- 
>>> 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 djan

[django-cs] Re: Jak zjistit jméno projektu

[MirekZv]

PS: dokud nejsou vyhodnoceny settings; tedy obecná package, která má něco 
připravit pro vyhodnocení těch settings.

Dne pátek 19. února 2021 v 19:41:30 UTC+1 uživatel MirekZv napsal:

> Zeptám se lépe: Jak může obecná package zjistit jméno nebo adresář 
> projektu, z něhož je zavolána?
>
> Dne pátek 19. února 2021 v 19:32:36 UTC+1 uživatel MirekZv napsal:
>
>> Běží mi kód ve stacku projektu,
>> ale dotyčný soubor se nachází mimo adresář projektu.
>> Jak bych zjistil jméno projektu?
>>
>> Abych to trochu vysvětlil:
>> V běžných django settings se řeší přesně toto, co potřebuju, třeba nějak 
>> přibližně takto:
>> BASE_DIR = Path(__file__).resolve().parent.parent
>> PROJECT_NAME = BASE_DIR.name
>>
>> Potřebuju totéž zjistit v souboru, který není v BASE_DIR.
>> A to tak, že nechci nic nastavovat nikde v souborech pod BASE_DIR.
>>
>> Napadají mě 2 možnosti:
>> - zjistit to nějak z inspect.stack() --ale nevím, jak to udělat dost 
>> bezpečně
>> - vzít jenom os.getcwd() --za předpokladu, že mám úplně standardní 
>> projekt, se stejným jménem rootu i adresáře projektu
>>
>> Zatím jsem se spokojil s tím posledním.
>> Myslíte, že by na to mohl být spoleh ve všech variantách na produkci?
>>
>> Alternativně: Dá se nějak snadno zjistit z kódu settings file (protože 
>> ten mám pod projektem; nebo prostě jakýkoli file, který je bezpečně pod 
>> adresářem projektu (např. ve stacku mám jako první manage.py, jenže to asi 
>> na produkci bude pokaždé jinak).
>>
>> Díky, tedy kdyby někdo věděl.
>>
>

-- 
-- 
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/b5e8d696-2715-4742-ad54-b7786068cf88n%40googlegroups.com.

[django-cs] Re: Jak zjistit jméno projektu

[MirekZv]

Zeptám se lépe: Jak může obecná package zjistit jméno nebo adresář 
projektu, z něhož je zavolána?

Dne pátek 19. února 2021 v 19:32:36 UTC+1 uživatel MirekZv napsal:

> Běží mi kód ve stacku projektu,
> ale dotyčný soubor se nachází mimo adresář projektu.
> Jak bych zjistil jméno projektu?
>
> Abych to trochu vysvětlil:
> V běžných django settings se řeší přesně toto, co potřebuju, třeba nějak 
> přibližně takto:
> BASE_DIR = Path(__file__).resolve().parent.parent
> PROJECT_NAME = BASE_DIR.name
>
> Potřebuju totéž zjistit v souboru, který není v BASE_DIR.
> A to tak, že nechci nic nastavovat nikde v souborech pod BASE_DIR.
>
> Napadají mě 2 možnosti:
> - zjistit to nějak z inspect.stack() --ale nevím, jak to udělat dost 
> bezpečně
> - vzít jenom os.getcwd() --za předpokladu, že mám úplně standardní 
> projekt, se stejným jménem rootu i adresáře projektu
>
> Zatím jsem se spokojil s tím posledním.
> Myslíte, že by na to mohl být spoleh ve všech variantách na produkci?
>
> Alternativně: Dá se nějak snadno zjistit z kódu settings file (protože ten 
> mám pod projektem; nebo prostě jakýkoli file, který je bezpečně pod 
> adresářem projektu (např. ve stacku mám jako první manage.py, jenže to asi 
> na produkci bude pokaždé jinak).
>
> Díky, tedy kdyby někdo věděl.
>

-- 
-- 
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/45253134-6a12-435d-b571-914725d1b182n%40googlegroups.com.

Re: [django-cs] Re: Django admin too danger for integrity

[MirekZv]

Udělal jsem to takhle, musí to pochopitelně být v aplikaci, která je 
předřazená v INSTALLED_APPS před django.contrib.admin.
`templates/admin/base.html`:
```
{% extends 'admin/base.html' %}
{% block footer %}
  {{ block.super }}
  
($ || django.jQuery)('a.delete-related, a.change-related').hide();
  
{% endblock footer %}
```
Dne pátek 19. února 2021 v 15:41:25 UTC+1 uživatel cisar...@gmail.com 
napsal:

> @star...@gmail.com :D komu neni rady, tomu neni pomoci.
>
> pá 19. 2. 2021 v 12:26 odesílatel starenka .  napsal:
>
>> ¯\_(ツ)_/¯
>> ---
>> In Perl you shoot yourself in the foot, but nobody can understand how you 
>> did it. Six months later, neither can you. | print 'aknerats'[::-1]
>>
>>
>> On Fri, Feb 19, 2021 at 11:08 AM MirekZv  wrote:
>>
>>> Díky.
>>> Klidně spím, protože si Django nenechávám přerůst přes hlavu. Je to 
>>> přece jen taková hra.
>>>
>>> Ty Vaše návrhy si cením, ale zdají se mi mimo (je možné, že jim 
>>> nerozumím).
>>> Já nepotřebuju bránit smazat osobu. Já potřebuju zabránit mazání osoby 
>>> JEN během vyplňování něčeho naprosto jiného (a navíc křížkem, o kterém 
>>> vůbec není jasné, že se chystá provést právě toto).
>>> Taky nepotřebuju to řešit na úrovni každého Admin nebo každého Model. 
>>> Ten problém je obecný, všude v adminu. Potřebuju 1 nastavení nebo 2 řádky 
>>> kódu a zlikvidovat ten nesmysl. Takže patch v templatě formou Javascriptu 
>>> bude asi nejlepší.
>>>
>>>
>>> Dne pátek 19. února 2021 v 10:44:51 UTC+1 uživatel Ing. Vladimir napsal:
>>>
>>>> pripadne zakazat vsechno, Mixin pro admin classu :-)
>>>>
>>>> class NonEditableMixin:
>>>> def has_delete_permission(self, request, obj=None):
>>>> return False
>>>>
>>>> def has_change_permission(self, request, obj=None):
>>>> return False
>>>>
>>>> def has_add_permission(self, request, obj=None):
>>>> return False
>>>>
>>>> can_delete = False
>>>>
>>>> On Fri, Feb 19, 2021 at 10:42 AM starenka .  wrote:
>>>>
>>>>> A nastav userum spravne prava na modely
>>>>>
>>>>> On Fri, Feb 19, 2021, 10:41 starenka .  wrote:
>>>>>
>>>>>> Nebo si udelej vlastni form na ten inline...
>>>>>>
>>>>>> On Fri, Feb 19, 2021, 10:38 Vladimir Linhart  
>>>>>> wrote:
>>>>>>
>>>>>>> nebo 
>>>>>>>
>>>>>>> readonly_fields
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 17, 2021 at 10:35 PM starenka .  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Tak si tam dej raw_id a budes klidne spat :)
>>>>>>>>
>>>>>>>> On Wed, Feb 17, 2021, 22:15 MirekZv  wrote:
>>>>>>>>
>>>>>>>>> PS: ono tedy i ten Edit je příliš nebezpečný. Nějakej Lojza si to 
>>>>>>>>> může otevřít a přepsat Lenku na Martina. Vždycky jsem si myslel, že 
>>>>>>>>> při 
>>>>>>>>> návrhu ovládání by měly být odlišeny (a tady by to mělo velké 
>>>>>>>>> opodstatnění) 
>>>>>>>>> plnokrevná editace od opravy překlepu.
>>>>>>>>> No ale to bych chtěl moc.
>>>>>>>>> Nicméně asi bych nejradši všude v adminu znepřístupnil tu editaci 
>>>>>>>>> i rušení (přes ForeignKey odkazovaného) záznamu.
>>>>>>>>>
>>>>>>>>> Dokážu to jen tím Javascriptem (což velká věda nebude) nebo to 
>>>>>>>>> můžu někde nastavit?
>>>>>>>>>
>>>>>>>>> Dne středa 17. února 2021 v 22:08:54 UTC+1 uživatel MirekZv napsal:
>>>>>>>>>
>>>>>>>>>> Podívejte se na obrázek, jsou tam dva inliny a na začátku každého 
>>>>>>>>>> z nich popup s vyplněným jménem Lenka.
>>>>>>>>>>
>>>>>>>>>> Jak se ty popupy liší? jeden má "rušící křížek", druhý ho nemá.
>>>>>>>>>> Jak se liší návrh databáze? Jedno ForeignKey připouští 
>>>>>>>>>> null/blank=True, druhé ho nepřipouští.
>>>>>>>>>>
>>>>>>>

Re: [django-cs] Aplikace mimo root projektu?

[MirekZv]

Sorry, Honzovi i všem, moje chyba,
samozřejmě jsem tam někde zapomněl: from apps.friends
a měl jsem tam: from friends
... nejsem na to talent :(
Dne pátek 19. února 2021 v 16:35:18 UTC+1 uživatel MirekZv napsal:

> @Honza
>
> S darovaným koněm je to stoprocentně pravda. Toho jsem si vědomý a když si 
> tady tak držkuju, tak to neznamená, že nejsem za Django vděčný.
>
> Za ten filozofický nadhled na věc určitě díky, z toho nějaké poučení vezmu.
>
> Ještě bych potřeboval, kdybych se dověděl, co tedy dělám špatně, proč mi 
> nejdou ty importy žádným způsobem.
> Lámu to už skoro celý den, máme tady dokonce jiný projekt, kde se to 
> používá, ale ani tak nejsem schopný zatím najít chybu.
> Hodinovému refactoringu se tedy s dovolením lehce pousměju (abych si 
> nezapomněl zadržkovat).
>
> Dne pátek 19. února 2021 v 16:01:28 UTC+1 uživatel honza...@gmail.com 
> napsal:
>
>> On Fri, Feb 19, 2021 at 3:49 PM MirekZv  wrote:
>>
>>> Zdravím. Tak už vás asi štvu, že sem furt postuju nějaké nesmysly. Nebo 
>>> je to dobře, oživit tuhle google grupu?
>>>
>>> Kam umísťujete Django aplikace?
>>> Nahňácáte jich 10 do rootu projektu (standardní Django bordýlek)
>>>
>>
>> Asi odpovim na prvni dve otazky dohromady - ozivit grupu je dobre, ptat 
>> se je dobre, ale trochu se zamysli nad tim, ceho chces docilit. Ja zcela 
>> osobne. jsem velmi blizko toho zacit tve otazky ignorovat protoze nemam 
>> zajem stale cist komentare nekoho o vecech jako je "standardni Django 
>> Bordylek" nebo kdo si stezuje, ze admin interface je pro adminy a ne pro 
>> verejnost pote co ho na to lidi upozorni.
>>  
>>
>>> nebo na ně máte extra adresář, třeba apps/ nebo applications/ ?
>>>
>>
>> pokud je to aplikace ktera jse specificka jen pro jeden projekt, dam ji 
>> do toho projektu, pokud by mela byt vyuzitelna pro vice projektu, dam ji do 
>> samostatneho repa jako uplne samostatnou vec kterou budu instalovat a 
>> importovat, napriklad:
>>
>> projekt ktery by resil hypotetickou konferenci:
>>
>> pycon
>> cfp
>> schedule
>>
>> Samostatne aplikace ktere bych v tom projektu take pouzil:
>>
>> calendar
>> mailinglist
>> 
>>
>>
>>> Já jsem si zkusil udělat ten extra adresář, ale zdá se mi, že to opravdu 
>>> není dobrý nápad, co myslíte?
>>> Mám s tím furt potíže a nemůžu najít nikde žádný checklist, co by člověk 
>>> měl mít uděláno, aby to běhalo.
>>>
>>
>> tohle totiz neni otazka na django, ale standardni python baliky, jak je 
>> nejlepe strukturovat a rozpadnout. 
>>
>>>
>>> Zatím jsem udělal toto:
>>> - prázdný soubor apps/__init__.py
>>> - INSTALLED_APPS: 'apps.friends', 'apps.events'
>>> - AppConfig: name='apps.friends', label='friends'
>>> - sys.path.append(str(BASE_DIR / 'apps'))
>>>
>>>
>>> Potíž mám s importy mezi aplikacemi:
>>> from ..friends.models import Friend : ImportError: attempted relative 
>>> import beyond top-level package (to nepřekvapí)
>>> from .friends.models import Friend : ModuleNotFoundError: No module 
>>> named 'apps.events.friends'
>>> RuntimeError: Model class friends.models.Finger doesn't declare an 
>>> explicit app_label and isn't in an application in INSTALLED_APPS.
>>> from apps.friends.models import Friend : RuntimeError: Model class 
>>> events.models.EventType doesn't declare an explicit app_label and isn't in 
>>> an application in INSTALLED_APPS.   # EventType je první model v aplikaci 
>>> events
>>>
>>> Tak co, mám ještě něco zkoušet,
>>> nebo mám radši hodně rychle pokorně vycouvat z tohoto laviniště?
>>>
>>> Kromě toho asi je blbé mít někde v kódu apps. a apps/, kdyby člověk 
>>> třeba časem usoudil, že tu aplikaci zbuilduje, že?
>>>
>>
>> Obecne neni treba se bat refactoringu. Pokud se rozhodnes neco zmenit, 
>> napriklad vzit aplikaci ktera byla doted jen v jednom projektu a ted bude 
>> samostatna, tak je to vetsinou otazka na cca hodinu ji odevsud vykopat a 
>> pak pustit testy aby ses ubezzpecil, ze vse funguje.
>>
>>>
>>> Zdravím, Mirek
>>>
>>> Asi si sem přidám slogan:
>>> *Django: Daruji Ti problém.*
>>>
>>
>> Darovanemu koni...
>>  
>>
>>> -- 
>>> -- 
>>> 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ři

Re: [django-cs] Aplikace mimo root projektu?

[MirekZv]

@Honza

S darovaným koněm je to stoprocentně pravda. Toho jsem si vědomý a když si 
tady tak držkuju, tak to neznamená, že nejsem za Django vděčný.

Za ten filozofický nadhled na věc určitě díky, z toho nějaké poučení vezmu.

Ještě bych potřeboval, kdybych se dověděl, co tedy dělám špatně, proč mi 
nejdou ty importy žádným způsobem.
Lámu to už skoro celý den, máme tady dokonce jiný projekt, kde se to 
používá, ale ani tak nejsem schopný zatím najít chybu.
Hodinovému refactoringu se tedy s dovolením lehce pousměju (abych si 
nezapomněl zadržkovat).

Dne pátek 19. února 2021 v 16:01:28 UTC+1 uživatel honza...@gmail.com 
napsal:

> On Fri, Feb 19, 2021 at 3:49 PM MirekZv  wrote:
>
>> Zdravím. Tak už vás asi štvu, že sem furt postuju nějaké nesmysly. Nebo 
>> je to dobře, oživit tuhle google grupu?
>>
>> Kam umísťujete Django aplikace?
>> Nahňácáte jich 10 do rootu projektu (standardní Django bordýlek)
>>
>
> Asi odpovim na prvni dve otazky dohromady - ozivit grupu je dobre, ptat se 
> je dobre, ale trochu se zamysli nad tim, ceho chces docilit. Ja zcela 
> osobne. jsem velmi blizko toho zacit tve otazky ignorovat protoze nemam 
> zajem stale cist komentare nekoho o vecech jako je "standardni Django 
> Bordylek" nebo kdo si stezuje, ze admin interface je pro adminy a ne pro 
> verejnost pote co ho na to lidi upozorni.
>  
>
>> nebo na ně máte extra adresář, třeba apps/ nebo applications/ ?
>>
>
> pokud je to aplikace ktera jse specificka jen pro jeden projekt, dam ji do 
> toho projektu, pokud by mela byt vyuzitelna pro vice projektu, dam ji do 
> samostatneho repa jako uplne samostatnou vec kterou budu instalovat a 
> importovat, napriklad:
>
> projekt ktery by resil hypotetickou konferenci:
>
> pycon
> cfp
> schedule
>
> Samostatne aplikace ktere bych v tom projektu take pouzil:
>
> calendar
> mailinglist
> 
>
>
>> Já jsem si zkusil udělat ten extra adresář, ale zdá se mi, že to opravdu 
>> není dobrý nápad, co myslíte?
>> Mám s tím furt potíže a nemůžu najít nikde žádný checklist, co by člověk 
>> měl mít uděláno, aby to běhalo.
>>
>
> tohle totiz neni otazka na django, ale standardni python baliky, jak je 
> nejlepe strukturovat a rozpadnout. 
>
>>
>> Zatím jsem udělal toto:
>> - prázdný soubor apps/__init__.py
>> - INSTALLED_APPS: 'apps.friends', 'apps.events'
>> - AppConfig: name='apps.friends', label='friends'
>> - sys.path.append(str(BASE_DIR / 'apps'))
>>
>>
>> Potíž mám s importy mezi aplikacemi:
>> from ..friends.models import Friend : ImportError: attempted relative 
>> import beyond top-level package (to nepřekvapí)
>> from .friends.models import Friend : ModuleNotFoundError: No module named 
>> 'apps.events.friends'
>> RuntimeError: Model class friends.models.Finger doesn't declare an 
>> explicit app_label and isn't in an application in INSTALLED_APPS.
>> from apps.friends.models import Friend : RuntimeError: Model class 
>> events.models.EventType doesn't declare an explicit app_label and isn't in 
>> an application in INSTALLED_APPS.   # EventType je první model v aplikaci 
>> events
>>
>> Tak co, mám ještě něco zkoušet,
>> nebo mám radši hodně rychle pokorně vycouvat z tohoto laviniště?
>>
>> Kromě toho asi je blbé mít někde v kódu apps. a apps/, kdyby člověk třeba 
>> časem usoudil, že tu aplikaci zbuilduje, že?
>>
>
> Obecne neni treba se bat refactoringu. Pokud se rozhodnes neco zmenit, 
> napriklad vzit aplikaci ktera byla doted jen v jednom projektu a ted bude 
> samostatna, tak je to vetsinou otazka na cca hodinu ji odevsud vykopat a 
> pak pustit testy aby ses ubezzpecil, ze vse funguje.
>
>>
>> Zdravím, Mirek
>>
>> Asi si sem přidám slogan:
>> *Django: Daruji Ti problém.*
>>
>
> Darovanemu koni...
>  
>
>> -- 
>> -- 
>> 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/d511ea52-9b96-4485-bf37-ef3f377d7b07n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/d511ea52-9b96-4485-bf37-ef3f377d7b07n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
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/78934470-4acb-4f51-883f-1d7434b044fen%40googlegroups.com.

[django-cs] Aplikace mimo root projektu?

[MirekZv]

Zdravím. Tak už vás asi štvu, že sem furt postuju nějaké nesmysly. Nebo je 
to dobře, oživit tuhle google grupu?

Kam umísťujete Django aplikace?
Nahňácáte jich 10 do rootu projektu (standardní Django bordýlek)
nebo na ně máte extra adresář, třeba apps/ nebo applications/ ?

Já jsem si zkusil udělat ten extra adresář, ale zdá se mi, že to opravdu 
není dobrý nápad, co myslíte?
Mám s tím furt potíže a nemůžu najít nikde žádný checklist, co by člověk 
měl mít uděláno, aby to běhalo.

Zatím jsem udělal toto:
- prázdný soubor apps/__init__.py
- INSTALLED_APPS: 'apps.friends', 'apps.events'
- AppConfig: name='apps.friends', label='friends'
- sys.path.append(str(BASE_DIR / 'apps'))


Potíž mám s importy mezi aplikacemi:
from ..friends.models import Friend : ImportError: attempted relative 
import beyond top-level package (to nepřekvapí)
from .friends.models import Friend : ModuleNotFoundError: No module named 
'apps.events.friends'
RuntimeError: Model class friends.models.Finger doesn't declare an explicit 
app_label and isn't in an application in INSTALLED_APPS.
from apps.friends.models import Friend : RuntimeError: Model class 
events.models.EventType doesn't declare an explicit app_label and isn't in 
an application in INSTALLED_APPS.   # EventType je první model v aplikaci 
events

Tak co, mám ještě něco zkoušet,
nebo mám radši hodně rychle pokorně vycouvat z tohoto laviniště?

Kromě toho asi je blbé mít někde v kódu apps. a apps/, kdyby člověk třeba 
časem usoudil, že tu aplikaci zbuilduje, že?

Zdravím, Mirek

Asi si sem přidám slogan:
*Django: Daruji Ti problém.*

-- 
-- 
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/d511ea52-9b96-4485-bf37-ef3f377d7b07n%40googlegroups.com.

Re: [django-cs] Bug URLField?

[MirekZv]

Super. Děkuju za perfektní rozbor. Jistě za tím bylo plno práce.

Dne pátek 19. února 2021 v 11:23:42 UTC+1 uživatel novotn...@gmail.com 
napsal:

> Pravda, já hlupák jsem nezkusil Edit v Django adminu, tam bych to viděl. 
>
> Pokazí se to až v Adminu, kde AdminURLFieldWidget upraví href takto:
> context['widget']['href'] = smart_urlquote(context['widget']['value']) if 
> value else ''
>
> No, a to smart_urlquote s tím provede to co s tím provede. Viz 
> https://github.com/django/django/blob/3.1.6/django/utils/html.py#L221
>
> (Pdb) value
> '
> https://mapy.cz/zakladni?planovani-trasy=14.3997275=49.8658414=14=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrC=coor=stre=stre=stre=coor=coor==5184552=5184960=5185096
> '
> (Pdb) smart_urlquote(value)
> '
> https://mapy.cz/zakladni?planovani-trasy==14.3997275=49.8658414=14=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrC=coor=stre=stre=stre=coor=coor==5184552=5184960=5185096
> '
>
> Řešením by mohlo být použít ModelAdmin.formfield_overrides a pro URLField 
> si udělat subclass AdminURLFieldWidget, který by to href neupravoval
> a nebo se zahloubat do specifikace a vymyslet, jestli je chyba v 
> Django smart_urlquote nebo urllib.parse.urlencode nebo jestli mají mapy.cz 
> používají URL v rozporu se standardy :)
>
> Radim
>
>
> On Fri, Feb 19, 2021 at 11:01 AM MirekZv  wrote:
>
>> Díky, Radime.
>> Já se renderováním (zatím) nijak nezabývám. Je to standardní widget pro 
>> URLField ve standardním adminu.
>>
>>
>>
>> Dne čtvrtek 18. února 2021 v 7:14:09 UTC+1 uživatel novotn...@gmail.com 
>> napsal:
>>
>>> URLField validuje (upravuje) strukturu odkazu (scheme, host, port, path, 
>>> fragment, query,) ale nevaliduje obsah  jednotlivých částí, takže URL je z 
>>> tohoto pohledu validní
>>> >>> urlsplit('scheme://blah:34787654/?query#frgmnt')
>>> SplitResult(scheme='scheme', netloc='blah:34787654', path='/', 
>>> query='query', fragment='frgmnt')
>>>
>>> Ten problém je tedy někde v renderování. Zkusil jsem si to, ale 
>>> nepodařilo se mi to zopakovat. 
>>>
>>> Jak to renderuješ? Nemůže být problém někde tam? Tohle se ve standardním 
>>> Django templates vyrenderuje stejně, jak je to v DB. 
>>>
>>> {{ obj.url }}
>>>
>>> Radim
>>>
>>> On Wed, Feb 17, 2021 at 10:29 PM MirekZv  wrote:
>>>
>>>> @novotn
>>>>
>>>> PS: Ještě bych pochopil (i když potěšilo by mě to ještě míň), že by 
>>>> Django neumožnilo pomocí validace toho URLFieldu tu chybnou hodnotu 
>>>> uložit. 
>>>> Ale ono ji uloží a v databázi je ta správná (i když tedy zřejmě 
>>>> nevalidní). 
>>>> Pokroutí ji až při renderování href=..
>>>>
>>>> Dne středa 17. února 2021 v 17:32:12 UTC+1 uživatel novotn...@gmail.com 
>>>> napsal:
>>>>
>>>>> Já bych tomu rozuměl tak, že to za otazníkem jsou parametry (query 
>>>>> string). Parametr má název a hodnotu. Hodnota je nepovinná, takže 
>>>>> ?param1==9 je ok. Pokud je to ve formátu ?param1=9 tak 
>>>>> se to zřejmě někde  normalizuje do toho ?param1==9 a param1 
>>>>> sice existuje, ale nemá hodnotu. Proto ta poznámka, že = nic nedělá. 
>>>>>
>>>>> Přijde mi, že mapy.cz to používají nějak nestandardně.
>>>>>
>>>>> URLField s tím evidentně nedělá žádný vopičárny. Udělá něco jako 
>>>>> urlunsplit(urlsplit(value)) aby to bylo validní. Podíval bych se co 
>>>>> je opravdu v databázi a jestli se to nepomate někde jinde.
>>>>>
>>>>> Radim
>>>>>
>>>>> On Wed, Feb 17, 2021 at 4:49 PM MirekZv  wrote:
>>>>>
>>>>>> No, jestli myslíš "nic nedělá" ve smyslu že "nezobrazí tu trasu", tak 
>>>>>> to máš pravdu.
>>>>>> Mimochodem můžete přijít na výlet, zítra Čt 9:05 ze Smíchovského 
>>>>>> nádraží 338 do Štěchovic.
>>>>>>
>>>>>> Dne středa 17. února 2021 v 16:46:31 UTC+1 uživatel starenka napsal:
>>>>>>
>>>>>>> tak to = tam fakt nic nedela, jak rika Vladimir...
>>>>>>>
>>>>>>> ---
>>>>>>> In Perl you shoot yourself in the foot, but nobody can understand 
>>>>>>> how you did it. Six months later, neither can you. | print 
>>>>>>> 'aknerats'[::-1]
>>>>>>>
>>>>>>> On Wed, Feb 17, 2021 at 4:44 PM Mire

Re: [django-cs] Re: Django admin too danger for integrity

[MirekZv]

Díky.
Klidně spím, protože si Django nenechávám přerůst přes hlavu. Je to přece 
jen taková hra.

Ty Vaše návrhy si cením, ale zdají se mi mimo (je možné, že jim nerozumím).
Já nepotřebuju bránit smazat osobu. Já potřebuju zabránit mazání osoby JEN 
během vyplňování něčeho naprosto jiného (a navíc křížkem, o kterém vůbec 
není jasné, že se chystá provést právě toto).
Taky nepotřebuju to řešit na úrovni každého Admin nebo každého Model. Ten 
problém je obecný, všude v adminu. Potřebuju 1 nastavení nebo 2 řádky kódu 
a zlikvidovat ten nesmysl. Takže patch v templatě formou Javascriptu bude 
asi nejlepší.


Dne pátek 19. února 2021 v 10:44:51 UTC+1 uživatel Ing. Vladimir napsal:

> pripadne zakazat vsechno, Mixin pro admin classu :-)
>
> class NonEditableMixin:
> def has_delete_permission(self, request, obj=None):
> return False
>
> def has_change_permission(self, request, obj=None):
> return False
>
> def has_add_permission(self, request, obj=None):
> return False
>
> can_delete = False
>
> On Fri, Feb 19, 2021 at 10:42 AM starenka .  wrote:
>
>> A nastav userum spravne prava na modely
>>
>> On Fri, Feb 19, 2021, 10:41 starenka .  wrote:
>>
>>> Nebo si udelej vlastni form na ten inline...
>>>
>>> On Fri, Feb 19, 2021, 10:38 Vladimir Linhart  
>>> wrote:
>>>
>>>> nebo 
>>>>
>>>> readonly_fields
>>>>
>>>>
>>>> On Wed, Feb 17, 2021 at 10:35 PM starenka .  wrote:
>>>>
>>>>> Tak si tam dej raw_id a budes klidne spat :)
>>>>>
>>>>> On Wed, Feb 17, 2021, 22:15 MirekZv  wrote:
>>>>>
>>>>>> PS: ono tedy i ten Edit je příliš nebezpečný. Nějakej Lojza si to 
>>>>>> může otevřít a přepsat Lenku na Martina. Vždycky jsem si myslel, že při 
>>>>>> návrhu ovládání by měly být odlišeny (a tady by to mělo velké 
>>>>>> opodstatnění) 
>>>>>> plnokrevná editace od opravy překlepu.
>>>>>> No ale to bych chtěl moc.
>>>>>> Nicméně asi bych nejradši všude v adminu znepřístupnil tu editaci i 
>>>>>> rušení (přes ForeignKey odkazovaného) záznamu.
>>>>>>
>>>>>> Dokážu to jen tím Javascriptem (což velká věda nebude) nebo to můžu 
>>>>>> někde nastavit?
>>>>>>
>>>>>> Dne středa 17. února 2021 v 22:08:54 UTC+1 uživatel MirekZv napsal:
>>>>>>
>>>>>>> Podívejte se na obrázek, jsou tam dva inliny a na začátku každého z 
>>>>>>> nich popup s vyplněným jménem Lenka.
>>>>>>>
>>>>>>> Jak se ty popupy liší? jeden má "rušící křížek", druhý ho nemá.
>>>>>>> Jak se liší návrh databáze? Jedno ForeignKey připouští 
>>>>>>> null/blank=True, druhé ho nepřipouští.
>>>>>>>
>>>>>>> To null se dá samozřejmě nastavit manipulací popupu pomocí např. 
>>>>>>> myši.
>>>>>>>
>>>>>>> Takže nepřekvapuje, že ten křížek dělá něco jiného.
>>>>>>> Zruší osobu Lenka (s celou soustavou CASCADE deleting záznamů).
>>>>>>>
>>>>>>> Když nad tím budeme přemýšlet, nějakou stopu logiky najdeme:
>>>>>>> V obou případech by mohlo být legitimní osobu Lenka zrušit (i když 
>>>>>>> proč takovou čistku zrovna při add/edit úplně jiného záznamu?). Ovšem 
>>>>>>> ve 
>>>>>>> druhém případě bychom místo té zrušené musely do ForeignKey vybrat 
>>>>>>> nějakou 
>>>>>>> jinou osobu (která už ani nemusí v tabulce být, Lenka může být 
>>>>>>> poslední).
>>>>>>>
>>>>>>> Ovšem i když jako programátor tyhle souvislosti nahlédneme, stejně 
>>>>>>> je to trochu příliš překombinované. A jak to má pochopit ubohý uživatel?
>>>>>>>
>>>>>>> Neboli se ptám:
>>>>>>> Jak můžu tuhletu nebezpečnou featuru zakázat?
>>>>>>> Dokážu to jedině Javascriptem nebo jsem přehlédnul nějaké nastavení?
>>>>>>>
>>>>>>> Díky pokud někdo poradí ...
>>>>>>> [image: broken_integrity.png]
>>>>>>>
>>>>>> -- 
>>>>>> -- 
>>>>>> E-mailová skupina djan...@googlegroups.com
>>>>>> Správa: http://groups.google.cz/group/django-cs
>

Re: [django-cs] Bug URLField?

[MirekZv]

Díky, Radime.
Já se renderováním (zatím) nijak nezabývám. Je to standardní widget pro 
URLField ve standardním adminu.



Dne čtvrtek 18. února 2021 v 7:14:09 UTC+1 uživatel novotn...@gmail.com 
napsal:

> URLField validuje (upravuje) strukturu odkazu (scheme, host, port, path, 
> fragment, query,) ale nevaliduje obsah  jednotlivých částí, takže URL je z 
> tohoto pohledu validní
> >>> urlsplit('scheme://blah:34787654/?query#frgmnt')
> SplitResult(scheme='scheme', netloc='blah:34787654', path='/', 
> query='query', fragment='frgmnt')
>
> Ten problém je tedy někde v renderování. Zkusil jsem si to, ale nepodařilo 
> se mi to zopakovat. 
>
> Jak to renderuješ? Nemůže být problém někde tam? Tohle se ve standardním 
> Django templates vyrenderuje stejně, jak je to v DB. 
>
> {{ obj.url }}
>
> Radim
>
> On Wed, Feb 17, 2021 at 10:29 PM MirekZv  wrote:
>
>> @novotn
>>
>> PS: Ještě bych pochopil (i když potěšilo by mě to ještě míň), že by 
>> Django neumožnilo pomocí validace toho URLFieldu tu chybnou hodnotu uložit. 
>> Ale ono ji uloží a v databázi je ta správná (i když tedy zřejmě nevalidní). 
>> Pokroutí ji až při renderování href=..
>>
>> Dne středa 17. února 2021 v 17:32:12 UTC+1 uživatel novotn...@gmail.com 
>> napsal:
>>
>>> Já bych tomu rozuměl tak, že to za otazníkem jsou parametry (query 
>>> string). Parametr má název a hodnotu. Hodnota je nepovinná, takže 
>>> ?param1==9 je ok. Pokud je to ve formátu ?param1=9 tak se 
>>> to zřejmě někde  normalizuje do toho ?param1==9 a param1 sice 
>>> existuje, ale nemá hodnotu. Proto ta poznámka, že = nic nedělá. 
>>>
>>> Přijde mi, že mapy.cz to používají nějak nestandardně.
>>>
>>> URLField s tím evidentně nedělá žádný vopičárny. Udělá něco jako 
>>> urlunsplit(urlsplit(value)) aby to bylo validní. Podíval bych se co je 
>>> opravdu v databázi a jestli se to nepomate někde jinde.
>>>
>>> Radim
>>>
>>> On Wed, Feb 17, 2021 at 4:49 PM MirekZv  wrote:
>>>
>>>> No, jestli myslíš "nic nedělá" ve smyslu že "nezobrazí tu trasu", tak 
>>>> to máš pravdu.
>>>> Mimochodem můžete přijít na výlet, zítra Čt 9:05 ze Smíchovského 
>>>> nádraží 338 do Štěchovic.
>>>>
>>>> Dne středa 17. února 2021 v 16:46:31 UTC+1 uživatel starenka napsal:
>>>>
>>>>> tak to = tam fakt nic nedela, jak rika Vladimir...
>>>>>
>>>>> ---
>>>>> In Perl you shoot yourself in the foot, but nobody can understand how 
>>>>> you did it. Six months later, neither can you. | print 
>>>>> 'aknerats'[::-1]
>>>>>
>>>>> On Wed, Feb 17, 2021 at 4:44 PM MirekZv  wrote:
>>>>>
>>>>>> @Starenka: No jo. Aktuálně: https://mapy.cz/zakladni?planovani-trasy=x=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>>>>>>  
>>>>>> <https://mapy.cz/zakladni?planovani-trasy==14.3997275=49.8658414=14=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrC=coor=stre=stre=stre=coor=coor==5184552=5184960=5185096===%7B%22c%22%3A131%7D=%5B%5D>
>>>>>> ">
>>>>>> https://mapy.cz/zakladni?planovani-trasyx=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>>>>>> 
>>>>>>
>>>>>> @Ing.Vladimír: Jak nevadí  Proč si asi ukládáš linky? Aby někam 
>>>>>> vedly, né ???
>>>>>>
>>>>>>
>>>>>> Dne středa 17. února 2021 v 14:39:14 UTC+1 uživatel Ing. Vladimir 
>>>>>> napsal:
>>>>>>
>>>>>>> navic to asi nicemu nevadi? to = navic
>>>>>>>
>>>>>>> On Wed, Feb 17, 2021 at 2:18 PM starenka .  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Jen pro sichr, do zdrojaku toho html ses dival, ze to tam fakt je 
>>>>>>>> (tj, ze browserum nehrabe...)?
>>>>>>>> ---
>>>>>>>> In Perl you shoot yourself in the foot, but nobody can understand 
>>>>>>>> how you did it. Six months later, neither can you. | print 
>>>>>>>> 'aknerats'[::-1]
>>>>>>>>
>>>>>>>>
>>>>>>&

Re: [django-cs] Bug URLField?

[MirekZv]

@novotn

PS: Ještě bych pochopil (i když potěšilo by mě to ještě míň), že by Django 
neumožnilo pomocí validace toho URLFieldu tu chybnou hodnotu uložit. Ale 
ono ji uloží a v databázi je ta správná (i když tedy zřejmě nevalidní). 
Pokroutí ji až při renderování href=..

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

> Já bych tomu rozuměl tak, že to za otazníkem jsou parametry (query 
> string). Parametr má název a hodnotu. Hodnota je nepovinná, takže 
> ?param1==9 je ok. Pokud je to ve formátu ?param1=9 tak se 
> to zřejmě někde  normalizuje do toho ?param1==9 a param1 sice 
> existuje, ale nemá hodnotu. Proto ta poznámka, že = nic nedělá. 
>
> Přijde mi, že mapy.cz to používají nějak nestandardně.
>
> URLField s tím evidentně nedělá žádný vopičárny. Udělá něco jako 
> urlunsplit(urlsplit(value)) aby to bylo validní. Podíval bych se co je 
> opravdu v databázi a jestli se to nepomate někde jinde.
>
> Radim
>
> On Wed, Feb 17, 2021 at 4:49 PM MirekZv  wrote:
>
>> No, jestli myslíš "nic nedělá" ve smyslu že "nezobrazí tu trasu", tak to 
>> máš pravdu.
>> Mimochodem můžete přijít na výlet, zítra Čt 9:05 ze Smíchovského nádraží 
>> 338 do Štěchovic.
>>
>> Dne středa 17. února 2021 v 16:46:31 UTC+1 uživatel starenka napsal:
>>
>>> tak to = tam fakt nic nedela, jak rika Vladimir...
>>>
>>> ---
>>> In Perl you shoot yourself in the foot, but nobody can understand how 
>>> you did it. Six months later, neither can you. | print 'aknerats'[::-1]
>>>
>>> On Wed, Feb 17, 2021 at 4:44 PM MirekZv  wrote:
>>>
>>>> @Starenka: No jo. Aktuálně: https://mapy.cz/zakladni?planovani-trasy=x=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>>>>  
>>>> <https://mapy.cz/zakladni?planovani-trasy==14.3997275=49.8658414=14=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrC=coor=stre=stre=stre=coor=coor==5184552=5184960=5185096===%7B%22c%22%3A131%7D=%5B%5D>
>>>> ">
>>>> https://mapy.cz/zakladni?planovani-trasyx=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>>>> 
>>>>
>>>> @Ing.Vladimír: Jak nevadí  Proč si asi ukládáš linky? Aby někam 
>>>> vedly, né ???
>>>>
>>>>
>>>> Dne středa 17. února 2021 v 14:39:14 UTC+1 uživatel Ing. Vladimir 
>>>> napsal:
>>>>
>>>>> navic to asi nicemu nevadi? to = navic
>>>>>
>>>>> On Wed, Feb 17, 2021 at 2:18 PM starenka .  wrote:
>>>>>
>>>>>> Jen pro sichr, do zdrojaku toho html ses dival, ze to tam fakt je 
>>>>>> (tj, ze browserum nehrabe...)?
>>>>>> ---
>>>>>> In Perl you shoot yourself in the foot, but nobody can understand how 
>>>>>> you did it. Six months later, neither can you. | print 
>>>>>> 'aknerats'[::-1]
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 17, 2021 at 2:09 PM MirekZv  wrote:
>>>>>>
>>>>>>> Narazil jste někdo na toto chování?
>>>>>>> Pastnuté URL je v pořádku, ale při sledování odkazu přibyde v místě 
>>>>>>> kurzoru "=" navíc (jak je vidět dole).
>>>>>>> Debian 10 Testing KDE, Py 3.9.1, Dj 3.1.6, Chrome i Firefox[image: 
>>>>>>> bug_urlfield.png]
>>>>>>>
>>>>>>> -- 
>>>>>>> -- 
>>>>>>> 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/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com
>>>>>>>  
>>>>>>> <https://groups.google.com/d/msgid/django-cs/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com?utm_medium=email_source=footer>
>>>>>>> .

Re: [django-cs] Bug URLField?

[MirekZv]

@novotn

Máš pravdu, že to rovnítko se objevuje až za otazníkem a že je to teda 
nestandardní a dost možná to odporuje validnímu url.
To jsem si neuvědomil.
Ale i tak mi přijde dost divoké, aby si Django samo to url upravovalo.
I když asi z nevalidního na validní.
Dne středa 17. února 2021 v 17:32:12 UTC+1 uživatel novotn...@gmail.com 
napsal:

> Já bych tomu rozuměl tak, že to za otazníkem jsou parametry (query 
> string). Parametr má název a hodnotu. Hodnota je nepovinná, takže 
> ?param1==9 je ok. Pokud je to ve formátu ?param1=9 tak se 
> to zřejmě někde  normalizuje do toho ?param1==9 a param1 sice 
> existuje, ale nemá hodnotu. Proto ta poznámka, že = nic nedělá. 
>
> Přijde mi, že mapy.cz to používají nějak nestandardně.
>
> URLField s tím evidentně nedělá žádný vopičárny. Udělá něco jako 
> urlunsplit(urlsplit(value)) aby to bylo validní. Podíval bych se co je 
> opravdu v databázi a jestli se to nepomate někde jinde.
>
> Radim
>
> On Wed, Feb 17, 2021 at 4:49 PM MirekZv  wrote:
>
>> No, jestli myslíš "nic nedělá" ve smyslu že "nezobrazí tu trasu", tak to 
>> máš pravdu.
>> Mimochodem můžete přijít na výlet, zítra Čt 9:05 ze Smíchovského nádraží 
>> 338 do Štěchovic.
>>
>> Dne středa 17. února 2021 v 16:46:31 UTC+1 uživatel starenka napsal:
>>
>>> tak to = tam fakt nic nedela, jak rika Vladimir...
>>>
>>> ---
>>> In Perl you shoot yourself in the foot, but nobody can understand how 
>>> you did it. Six months later, neither can you. | print 'aknerats'[::-1]
>>>
>>> On Wed, Feb 17, 2021 at 4:44 PM MirekZv  wrote:
>>>
>>>> @Starenka: No jo. Aktuálně: https://mapy.cz/zakladni?planovani-trasy=x=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>>>>  
>>>> <https://mapy.cz/zakladni?planovani-trasy==14.3997275=49.8658414=14=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrC=coor=stre=stre=stre=coor=coor==5184552=5184960=5185096===%7B%22c%22%3A131%7D=%5B%5D>
>>>> ">
>>>> https://mapy.cz/zakladni?planovani-trasyx=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>>>> 
>>>>
>>>> @Ing.Vladimír: Jak nevadí  Proč si asi ukládáš linky? Aby někam 
>>>> vedly, né ???
>>>>
>>>>
>>>> Dne středa 17. února 2021 v 14:39:14 UTC+1 uživatel Ing. Vladimir 
>>>> napsal:
>>>>
>>>>> navic to asi nicemu nevadi? to = navic
>>>>>
>>>>> On Wed, Feb 17, 2021 at 2:18 PM starenka .  wrote:
>>>>>
>>>>>> Jen pro sichr, do zdrojaku toho html ses dival, ze to tam fakt je 
>>>>>> (tj, ze browserum nehrabe...)?
>>>>>> ---
>>>>>> In Perl you shoot yourself in the foot, but nobody can understand how 
>>>>>> you did it. Six months later, neither can you. | print 
>>>>>> 'aknerats'[::-1]
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 17, 2021 at 2:09 PM MirekZv  wrote:
>>>>>>
>>>>>>> Narazil jste někdo na toto chování?
>>>>>>> Pastnuté URL je v pořádku, ale při sledování odkazu přibyde v místě 
>>>>>>> kurzoru "=" navíc (jak je vidět dole).
>>>>>>> Debian 10 Testing KDE, Py 3.9.1, Dj 3.1.6, Chrome i Firefox[image: 
>>>>>>> bug_urlfield.png]
>>>>>>>
>>>>>>> -- 
>>>>>>> -- 
>>>>>>> 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/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com
>>>>>>>  
>>>>>>> <https://groups.google.com/d/msgid/django-cs/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com?utm_medium=email_source=footer>
>>>>>>> .
>>

[django-cs] Re: Django admin too danger for integrity

[MirekZv]

PS: ono tedy i ten Edit je příliš nebezpečný. Nějakej Lojza si to může 
otevřít a přepsat Lenku na Martina. Vždycky jsem si myslel, že při návrhu 
ovládání by měly být odlišeny (a tady by to mělo velké opodstatnění) 
plnokrevná editace od opravy překlepu.
No ale to bych chtěl moc.
Nicméně asi bych nejradši všude v adminu znepřístupnil tu editaci i rušení 
(přes ForeignKey odkazovaného) záznamu.

Dokážu to jen tím Javascriptem (což velká věda nebude) nebo to můžu někde 
nastavit?

Dne středa 17. února 2021 v 22:08:54 UTC+1 uživatel MirekZv napsal:

> Podívejte se na obrázek, jsou tam dva inliny a na začátku každého z nich 
> popup s vyplněným jménem Lenka.
>
> Jak se ty popupy liší? jeden má "rušící křížek", druhý ho nemá.
> Jak se liší návrh databáze? Jedno ForeignKey připouští null/blank=True, 
> druhé ho nepřipouští.
>
> To null se dá samozřejmě nastavit manipulací popupu pomocí např. myši.
>
> Takže nepřekvapuje, že ten křížek dělá něco jiného.
> Zruší osobu Lenka (s celou soustavou CASCADE deleting záznamů).
>
> Když nad tím budeme přemýšlet, nějakou stopu logiky najdeme:
> V obou případech by mohlo být legitimní osobu Lenka zrušit (i když proč 
> takovou čistku zrovna při add/edit úplně jiného záznamu?). Ovšem ve druhém 
> případě bychom místo té zrušené musely do ForeignKey vybrat nějakou jinou 
> osobu (která už ani nemusí v tabulce být, Lenka může být poslední).
>
> Ovšem i když jako programátor tyhle souvislosti nahlédneme, stejně je to 
> trochu příliš překombinované. A jak to má pochopit ubohý uživatel?
>
> Neboli se ptám:
> Jak můžu tuhletu nebezpečnou featuru zakázat?
> Dokážu to jedině Javascriptem nebo jsem přehlédnul nějaké nastavení?
>
> Díky pokud někdo poradí ...
> [image: broken_integrity.png]
>

-- 
-- 
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/f3252964-735b-4d30-bc7c-1618d11c3471n%40googlegroups.com.

[django-cs] Django admin too danger for integrity

[MirekZv]

Podívejte se na obrázek, jsou tam dva inliny a na začátku každého z nich 
popup s vyplněným jménem Lenka.

Jak se ty popupy liší? jeden má "rušící křížek", druhý ho nemá.
Jak se liší návrh databáze? Jedno ForeignKey připouští null/blank=True, 
druhé ho nepřipouští.

To null se dá samozřejmě nastavit manipulací popupu pomocí např. myši.

Takže nepřekvapuje, že ten křížek dělá něco jiného.
Zruší osobu Lenka (s celou soustavou CASCADE deleting záznamů).

Když nad tím budeme přemýšlet, nějakou stopu logiky najdeme:
V obou případech by mohlo být legitimní osobu Lenka zrušit (i když proč 
takovou čistku zrovna při add/edit úplně jiného záznamu?). Ovšem ve druhém 
případě bychom místo té zrušené musely do ForeignKey vybrat nějakou jinou 
osobu (která už ani nemusí v tabulce být, Lenka může být poslední).

Ovšem i když jako programátor tyhle souvislosti nahlédneme, stejně je to 
trochu příliš překombinované. A jak to má pochopit ubohý uživatel?

Neboli se ptám:
Jak můžu tuhletu nebezpečnou featuru zakázat?
Dokážu to jedině Javascriptem nebo jsem přehlédnul nějaké nastavení?

Díky pokud někdo poradí ...
[image: broken_integrity.png]

-- 
-- 
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/5faeded7-642c-4403-b74c-7f224fa588d9n%40googlegroups.com.

Re: [django-cs] emmett

[MirekZv]

@Honza Javorek

Pyramid: Dost jsem ho zaregistroval, všimnul jsem si, že to lidi celkem 
chválí, ale dopodrobna jsem se neodhodlal to zkoumat a zkoušet. Rozhodnul 
jsem se pro Django, protože mě přišlo, že kolem Pyramid je menší komunita, 
chybí 3p knihovny apod. Dělal jsem tohle rozhodování Django vs Flask vs 
Pyramid asi před 2 roky, třeba se to zas nějak posunulo, nevím. Nemám 
dostatečný rozhled po jiných python fullstack frameworcích, ale byl by 
podle mě zázrak, kdyby do 5 let bylo něco reálnou konkurencí Djanga.

Dne středa 17. února 2021 v 14:40:48 UTC+1 uživatel Honza Javorek napsal:

> A ten Pyramid jsi zkoušel? Přijde mi, že to je právě celkem známé, tak to 
> asi má i nějakou komunitu, návody, atd.
>
> HJ
>
>
> On Wed 17. 2. 2021 at 14:04, MirekZv  wrote:
>
>> Mně ten dnešní JavaScript připadá už docela hezký, skoro jako Python. 
>> Teda kdyby ho někdo zvládl sám a začal si v tom psát, pokud pro někoho, tak 
>> asi spadne do legacy projektu a to nikomu nepřeju.
>> K Vue jsem si poznamenal toto video, bylo by fajn, kdyby někdo znalejší 
>> na to mrknul a řekl, jestli mu to přijde jako správný směr. 
>> https://www.youtube.com/watch?v=3eTtVY7duJk
>> Kromě emmett jsem objevil další pokus o fullstack v Pythonu: masonite. 
>> Ale dokud se něco z toho nestane trochu mainstream, nemá smysl po tom 
>> koukat. A já nechci od Djanga zdrhat. Jenom bych rád celou tvorbu webu 
>> zvládal efektivně vč. deployment a javascriptu i v 1 člověku a nejsem si 
>> jistý, jestli Django byla nejlepší volba. No ale už jsem ji udělal. A 
>> myslím, že třeba po 2 letech učení a 2 letech budování nějaké vlastní 
>> infrastruktury by se třeba uspět dalo.
>>
>> Dne středa 17. února 2021 v 10:04:50 UTC+1 uživatel stanisl...@gmail.com 
>> napsal:
>>
>>> Tak toto naprosto podepisuji. Před pár lety jsem se vrátil k 
>>> programování a strávil neskutečné množství času hledáním svatého grálu, 
>>> volbou jazyka/frameworku. Hodně jsem váhal mezi nějakým JS a Python 
>>> frameworkem. Nakonec vyhrál Python pro svoji obecnou použitelnost, ale s 
>>> nabývajícími zkušenostmi jsem zjistil, že JS není špatná volba, resp. že by 
>>> mi fungovalo obojí. Nicméně JS, pohledově a zápisem, mi vůbec nevyhovuje a 
>>> nesedí. Dodnes jsem si k němu nenašel cestu, ale musím, klienti to vyžadují.
>>>
>>> Co se týče frameworků pro Python, tak vyhrálo Django. Dlouho jsem měl 
>>> úmysly si adoptovat něco “menšího a obratnějšího” na malé projekty, 
>>> microsite, prezentaci dat apod. Nakonec jsem to zavrhl a udělal jsem jen 
>>> dobře. Dneska i na microsite jde rovnou Django jako podvozek. Typicky 
>>> projekt 2 měsíce zpět: pár skriptů pro úpravu XML mezi dodavatelem a 
>>> odběratelem. Vše hozeno jako “robůtci” do jednotlivých Views, adresy do 
>>> Urls a bylo hotovo. Ale za 2 týdny najednou potřebovali překládat 
>>> produktová data s výpočtem nějakých dalších hodnot a držet některá data v 
>>> čase: další App + Model + Views + Urls a do Crontab pak volání pár Urls. 
>>> Pak další: simple administrace, výpis produktů, čistě funkčně, 
>>> nepotřebovali žádnou krásu. Nakonec zaheslovat přístup. Pohoda, “vždy 
>>> připraven", vše hned a bez problémů. A pro mne nejzásadnější výhoda: vše 
>>> systematicky. Dneska již mohu říct, že se vracím k projektům co jsem 2 roky 
>>> “neviděl”. Vím kam sáhnout, jak a co řešit nebo jak projekt “the right way” 
>>> doplnit/upravit. U starších projektů, a to nejsem žádný bastlíř a patlal, 
>>> buď vzpomínám jakou cestu/řešení jsem zrovna zvolil a nebo hledám v 
>>> dokumentaci (i proto, že už danou věc nepoužívám). Prostě, Django chleba na 
>>> severu nežere, nepřekáží, ale když je třeba, pomůže.
>>>
>>> A co se týče JS, tady budu rád za každou radu, zkušenost co píšete. JS 
>>> se mi vizuálně nelíbí a navíc skripty ve stránce nemám rád. Je to hlavně 
>>> proto, že Request->Response cyklus je jasný, mám vše pod kontrolou. Jít 
>>> dopisovat v JS něco do stránky kde už řádí řada jiných funkcí mi proti tomu 
>>> připadá jak minové pole. Ale uznávám, je to nejspíše jen moje 
>>> neznalost/nezkušenost. Proto hledám cestu jak klientům přinést lepší 
>>> frontend a sobě nezničit zdraví. Zatím to vidím na Vue.js, + REST API. Jen 
>>> mi pak připadá už trochu zvláštní přes View poslat prvotní stav a zbytek 
>>> řešit REST API. Možná nejsem daleko od stavu, kdy Django bude jen backend a 
>>> frontend už převezme Vue (či něco podobného) kompletně. Mimochodem, nějaký 
>>> tip na praktickou či zajímavou knihu/eLearning pro efektivní tvorbu 
>>&g

Re: [django-cs] emmett

[MirekZv]

@stanislav

Naprosto s Tebou nesouhlasím. To neber jako nějaké nepřátelství nebo chuť 
se o něco hádat.
Chci prostě jen vyjádřit jiný názor na věc:
Jestliže chceš nějak zúročit dobu, kdy jsi se učil nebo kdy jsi zakládal 
firmu (ono to totiž platí pro jednotlivce, i pro malou firmu, i pro velkou 
firmu), musíš dát focus na určitou technologii nebo technologie a nemůžeš 
přecházet od jednoho k druhému. Musíš prostě vykompenzovat to ztrátové 
období, kdy ses to učil, kdy se to učili Tvoji lidi, kdy sis budoval 
nějakou infrastrukturu. To všechno sežralo nebo sežere řekněme 3 roky a 
jestli to nebyla nějaká pitomá hra se životem, tak u té technologie musíš 
5-10 let zůstat a vytřískat z ní přiměřené výsledky.
(Že tu další by ses naučil už rychleji, to nerozporuju.)

Takže já zůstanu u Djanga ještě pěkně dlouho, protože letos tak sotva 
dokončím aspoň základní učení.
Ovšem pěkně si tady nebo jinde ještě zanadávám, protože kamkoli se mrknu, 
tam je nějaká komplikace. Hned jdu zas připsat jeden nový topic.
Dne středa 17. února 2021 v 14:43:43 UTC+1 uživatel stanisl...@gmail.com 
napsal:

> Django, Masonite a vše další bude tak dobré a efektivní, jak dobře to 
> budeš umět. Když se podívám 3 roky zpět, musím se smát, kolik času jsem 
> promrhal a na druhou stranu jak jsem si věci komplikoval. Prostě výtečně 
> knížky jako Two scoops of Django (mimochodem doporučuji!), PyCharm či YT 
> tutoriály mi začaly dávat smysl, a dokázal jsem pochopit celý obsah, až 
> jsem měl něco odprogramováno. Prostě programuj, ono to přijde…
>
> Jinak očima programátora (pokud už se tak mohu označit), se mi zdá, že čím 
> více toho umím, tím snazší by bylo přejít na cokoliv jiného. Když jsem 
> nedávno koukal do Flask, bez větších problémů jsem se zorientoval. Postupy 
> jak co řešit mi dávaly zásadně lepší logiku než když jsem kdysi, se 
> základní znalostí Python 3, koukal různé tutoriál a videa typu “how to do 
> in …..” nebo zcela ztracený čas u “django vs flask vs ….”. Myslím, že vůbec 
> nemá cenu řešit Django vs jiné, dokonce nemá ani větší význam řešit Django 
> vs Ruby vs Laravel atd. Logika a východiska jsou velice podobná
>
> Ano, je tu stále otázka, zda JS komplet, nebo kde si dát hranici mezi JS a 
> Django. Tak hurá na videa “Django REST API and Vue”. Všichni ostatní mohou 
> trávit čas u “JS vs Django vs Laravel” a “what to learn in 2021” :)
>
> Standa
>
> On 17 February 2021 at 14:04:29, MirekZv (mirek@gmail.com) wrote:
>
> Mně ten dnešní JavaScript připadá už docela hezký, skoro jako Python. Teda 
> kdyby ho někdo zvládl sám a začal si v tom psát, pokud pro někoho, tak asi 
> spadne do legacy projektu a to nikomu nepřeju.
> K Vue jsem si poznamenal toto video, bylo by fajn, kdyby někdo znalejší na 
> to mrknul a řekl, jestli mu to přijde jako správný směr. 
> https://www.youtube.com/watch?v=3eTtVY7duJk
> Kromě emmett jsem objevil další pokus o fullstack v Pythonu: masonite. Ale 
> dokud se něco z toho nestane trochu mainstream, nemá smysl po tom koukat. A 
> já nechci od Djanga zdrhat. Jenom bych rád celou tvorbu webu zvládal 
> efektivně vč. deployment a javascriptu i v 1 člověku a nejsem si jistý, 
> jestli Django byla nejlepší volba. No ale už jsem ji udělal. A myslím, že 
> třeba po 2 letech učení a 2 letech budování nějaké vlastní infrastruktury 
> by se třeba uspět dalo.
>
> Dne středa 17. února 2021 v 10:04:50 UTC+1 uživatel stanisl...@gmail.com 
> napsal:
>
>> Tak toto naprosto podepisuji. Před pár lety jsem se vrátil k programování 
>> a strávil neskutečné množství času hledáním svatého grálu, volbou 
>> jazyka/frameworku. Hodně jsem váhal mezi nějakým JS a Python frameworkem. 
>> Nakonec vyhrál Python pro svoji obecnou použitelnost, ale s nabývajícími 
>> zkušenostmi jsem zjistil, že JS není špatná volba, resp. že by mi fungovalo 
>> obojí. Nicméně JS, pohledově a zápisem, mi vůbec nevyhovuje a nesedí. 
>> Dodnes jsem si k němu nenašel cestu, ale musím, klienti to vyžadují.
>>
>> Co se týče frameworků pro Python, tak vyhrálo Django. Dlouho jsem měl 
>> úmysly si adoptovat něco “menšího a obratnějšího” na malé projekty, 
>> microsite, prezentaci dat apod. Nakonec jsem to zavrhl a udělal jsem jen 
>> dobře. Dneska i na microsite jde rovnou Django jako podvozek. Typicky 
>> projekt 2 měsíce zpět: pár skriptů pro úpravu XML mezi dodavatelem a 
>> odběratelem. Vše hozeno jako “robůtci” do jednotlivých Views, adresy do 
>> Urls a bylo hotovo. Ale za 2 týdny najednou potřebovali překládat 
>> produktová data s výpočtem nějakých dalších hodnot a držet některá data v 
>> čase: další App + Model + Views + Urls a do Crontab pak volání pár Urls. 
>> Pak další: simple administrace, výpis produktů, čistě funkčně, 
>> nepotřebovali žádnou krásu. Nakonec zaheslovat přístup. Pohoda, “vžd

Re: [django-cs] Bug URLField?

[MirekZv]

No, jestli myslíš "nic nedělá" ve smyslu že "nezobrazí tu trasu", tak to 
máš pravdu.
Mimochodem můžete přijít na výlet, zítra Čt 9:05 ze Smíchovského nádraží 
338 do Štěchovic.

Dne středa 17. února 2021 v 16:46:31 UTC+1 uživatel starenka napsal:

> tak to = tam fakt nic nedela, jak rika Vladimir...
>
> ---
> In Perl you shoot yourself in the foot, but nobody can understand how you 
> did it. Six months later, neither can you. | print 'aknerats'[::-1]
>
> On Wed, Feb 17, 2021 at 4:44 PM MirekZv  wrote:
>
>> @Starenka: No jo. Aktuálně: https://mapy.cz/zakladni?planovani-trasy=x=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>>  
>> <https://mapy.cz/zakladni?planovani-trasy==14.3997275=49.8658414=14=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrC=coor=stre=stre=stre=coor=coor==5184552=5184960=5185096===%7B%22c%22%3A131%7D=%5B%5D>
>> ">
>> https://mapy.cz/zakladni?planovani-trasyx=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>> 
>>
>> @Ing.Vladimír: Jak nevadí  Proč si asi ukládáš linky? Aby někam 
>> vedly, né ???
>>
>>
>> Dne středa 17. února 2021 v 14:39:14 UTC+1 uživatel Ing. Vladimir napsal:
>>
>>> navic to asi nicemu nevadi? to = navic
>>>
>>> On Wed, Feb 17, 2021 at 2:18 PM starenka .  wrote:
>>>
>>>> Jen pro sichr, do zdrojaku toho html ses dival, ze to tam fakt je (tj, 
>>>> ze browserum nehrabe...)?
>>>> ---
>>>> In Perl you shoot yourself in the foot, but nobody can understand how 
>>>> you did it. Six months later, neither can you. | print 'aknerats'[::-1]
>>>>
>>>>
>>>> On Wed, Feb 17, 2021 at 2:09 PM MirekZv  wrote:
>>>>
>>>>> Narazil jste někdo na toto chování?
>>>>> Pastnuté URL je v pořádku, ale při sledování odkazu přibyde v místě 
>>>>> kurzoru "=" navíc (jak je vidět dole).
>>>>> Debian 10 Testing KDE, Py 3.9.1, Dj 3.1.6, Chrome i Firefox[image: 
>>>>> bug_urlfield.png]
>>>>>
>>>>> -- 
>>>>> -- 
>>>>> 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/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/django-cs/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>>> -- 
>>>> 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/CA%2B7MNVo0WRfmiknrf%3DdhOJuXiwwof0yQ9%3Dp9OC%3D3tWpD6G_i6w%40mail.gmail.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-cs/CA%2B7MNVo0WRfmiknrf%3DdhOJuXiwwof0yQ9%3Dp9OC%3D3tWpD6G_i6w%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> -- 
>> 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/d34d76ed-e2aa-4dbe-80c8-164879c25d57n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/d34d76ed-e2aa-4dbe-80c8-164879c25d57n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
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/5f488e00-9fef-41c4-bc8c-76c2c95b07e0n%40googlegroups.com.

Re: [django-cs] Bug URLField?

[MirekZv]

PS @Ing.Vladimír: Ten odkaz tady v diskuzi jde prokliknout. Tak si to zkus 
a pak zkus odstranit to = za tím planovani-trasy. Trochu rozdíl, ne? A to 
je ještě úplná náhoda, že to není rozbité úplně.

Dne středa 17. února 2021 v 16:44:20 UTC+1 uživatel MirekZv napsal:

> @Starenka: No jo. Aktuálně: https://mapy.cz/zakladni?planovani-trasy=x=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
>  
> <https://mapy.cz/zakladni?planovani-trasy==14.3997275=49.8658414=14=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrC=coor=stre=stre=stre=coor=coor==5184552=5184960=5185096===%7B%22c%22%3A131%7D=%5B%5D>
> ">
> https://mapy.cz/zakladni?planovani-trasyx=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
> 
>
> @Ing.Vladimír: Jak nevadí  Proč si asi ukládáš linky? Aby někam vedly, 
> né ???
>
>
> Dne středa 17. února 2021 v 14:39:14 UTC+1 uživatel Ing. Vladimir napsal:
>
>> navic to asi nicemu nevadi? to = navic
>>
>> On Wed, Feb 17, 2021 at 2:18 PM starenka .  wrote:
>>
>>> Jen pro sichr, do zdrojaku toho html ses dival, ze to tam fakt je (tj, 
>>> ze browserum nehrabe...)?
>>> ---
>>> In Perl you shoot yourself in the foot, but nobody can understand how 
>>> you did it. Six months later, neither can you. | print 'aknerats'[::-1]
>>>
>>>
>>> On Wed, Feb 17, 2021 at 2:09 PM MirekZv  wrote:
>>>
>>>> Narazil jste někdo na toto chování?
>>>> Pastnuté URL je v pořádku, ale při sledování odkazu přibyde v místě 
>>>> kurzoru "=" navíc (jak je vidět dole).
>>>> Debian 10 Testing KDE, Py 3.9.1, Dj 3.1.6, Chrome i Firefox[image: 
>>>> bug_urlfield.png]
>>>>
>>>> -- 
>>>> -- 
>>>> 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/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-cs/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>>> -- 
>>> 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/CA%2B7MNVo0WRfmiknrf%3DdhOJuXiwwof0yQ9%3Dp9OC%3D3tWpD6G_i6w%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/django-cs/CA%2B7MNVo0WRfmiknrf%3DdhOJuXiwwof0yQ9%3Dp9OC%3D3tWpD6G_i6w%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
-- 
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/aef7c56f-0b61-4df5-b69e-3a4fff747901n%40googlegroups.com.

Re: [django-cs] Bug URLField?

[MirekZv]

@Starenka: No jo. Aktuálně: https://mapy.cz/zakladni?planovani-trasy=x=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D
 
<https://mapy.cz/zakladni?planovani-trasy==14.3997275=49.8658414=14=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrC=coor=stre=stre=stre=coor=coor==5184552=5184960=5185096===%7B%22c%22%3A131%7D=%5B%5D>
">https://mapy.cz/zakladni?planovani-trasyx=14.3997275y=49.8658414z=14rc=9gzb-xWeX3h.ihoDdqEirpfDOiZIfdm5x-iZLdrCrs=coorrs=strers=strers=strers=coorrs=coorri=ri=5184552ri=5184960ri=5185096ri=ri=mrp=%7B%22c%22%3A131%7Dxc=%5B%5D

@Ing.Vladimír: Jak nevadí  Proč si asi ukládáš linky? Aby někam vedly, 
né ???


Dne středa 17. února 2021 v 14:39:14 UTC+1 uživatel Ing. Vladimir napsal:

> navic to asi nicemu nevadi? to = navic
>
> On Wed, Feb 17, 2021 at 2:18 PM starenka .  wrote:
>
>> Jen pro sichr, do zdrojaku toho html ses dival, ze to tam fakt je (tj, ze 
>> browserum nehrabe...)?
>> ---
>> In Perl you shoot yourself in the foot, but nobody can understand how you 
>> did it. Six months later, neither can you. | print 'aknerats'[::-1]
>>
>>
>> On Wed, Feb 17, 2021 at 2:09 PM MirekZv  wrote:
>>
>>> Narazil jste někdo na toto chování?
>>> Pastnuté URL je v pořádku, ale při sledování odkazu přibyde v místě 
>>> kurzoru "=" navíc (jak je vidět dole).
>>> Debian 10 Testing KDE, Py 3.9.1, Dj 3.1.6, Chrome i Firefox[image: 
>>> bug_urlfield.png]
>>>
>>> -- 
>>> -- 
>>> 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/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-cs/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> -- 
>> -- 
>> 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/CA%2B7MNVo0WRfmiknrf%3DdhOJuXiwwof0yQ9%3Dp9OC%3D3tWpD6G_i6w%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/CA%2B7MNVo0WRfmiknrf%3DdhOJuXiwwof0yQ9%3Dp9OC%3D3tWpD6G_i6w%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
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/d34d76ed-e2aa-4dbe-80c8-164879c25d57n%40googlegroups.com.

[django-cs] Bug URLField?

[MirekZv]

Narazil jste někdo na toto chování?
Pastnuté URL je v pořádku, ale při sledování odkazu přibyde v místě kurzoru 
"=" navíc (jak je vidět dole).
Debian 10 Testing KDE, Py 3.9.1, Dj 3.1.6, Chrome i Firefox[image: 
bug_urlfield.png]

-- 
-- 
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/0a4427a7-46c8-443b-a8f2-339034a178f3n%40googlegroups.com.

Re: [django-cs] emmett

[MirekZv]

lí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 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áz

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
>>  
>> <https://groups.google.com/d/msgid/django-cs/da232fdc-0df7-46d2-8cc9-f8a95105430an%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

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

[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] 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. 
>>>>>&g

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 editac

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
>>  
>> <https://groups.google.com/d/msgid/django-cs/837e5398-60e1-4115-b0f8-800b2968dcdbn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 

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

[MirekZv]

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:
>>>>
>>>>> 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.
>>>>>
>>>>> A

Re: [django-cs] emmett

[MirekZv]

Jo, mikroframeworků v Pythonu je plno. Když chceš udělat webovou aplikaci, 
potřebuješ fullstack. Když si microframework rozšíříš o nějaký stack 
knihoven, dostaneš sice fullstack, ale pěkně zbastlený.
Takže se mi zdá, že Django je jasná volba. (párkrát jsem byl u diskuzí 
Django vs Flask)
Jenže je prostě přesložitělé a jestli účelem tvé aplikace není "web pro 
novinový deník se sdíleným obsahem na 3 doménách" tak je v některých věcech 
dost omezující.
Takže: Junior to nedává, nečistá řešení, pomalý vývoj, ohrožená dlouhodobá 
udržovatelnost, atp.
Bude muset přijít něco jiného (a včas se stát silným streamem). Jinak nás 
smete JavaScript i na serveru.
Dne čtvrtek 11. února 2021 v 11:11:21 UTC+1 uživatel Honza Javorek napsal:

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

Re: [django-cs] Python Class a potomci

[MirekZv]

Omlouvám se, že možná neodpovídám přímo na to, co zajímá Tebe. Jen nějaký 
postřeh (k horní polovině toho, co píšeš; v dolní polovině Tvých 
experimentů už se příliš ztrácím, ale nezdá se mi, že by ses přibližoval 
nějakému normálnímu používání tříd a objektů).

>> co mi vadi, ze kazdy potomek vytvori novou instanci toho LmsDbClass, 
chtel bych aby to bylo jen jednou

To pochybuju, že by vytvářel nějaké instance LmsDbClass.
Asi máš na mysli instanci toho TesstLms.
Ta TesstLms dědí z LmsDbClass a to neznamená nic jiného, že běží kód z té 
třídy LmsDbClass všude tam, kde
- neexistuje příslušná metoda ve vyděděné TesstLms třídě,
- existuje příslušná metoda ve vyděděné TesstLms třídě a ta volá 
super().metoda() -- ano, normální je volat rodičovskou metodu pomocí 
super() a ne tak, jak ji voláš Ty.


Dne středa 3. února 2021 v 14:22:56 UTC+1 uživatel Daniel Kopecký napsal:

> Čau,
>
> nečetl jsem důkladně tvůj problém, ale pokud chceš odkazovat na již 
> vytvořenou instanci, tak použij Singleton pattern (
> https://python-patterns.guide/gang-of-four/singleton/). Pozor na 
> implementace, na netu nalezneš stovky, ale některé jsou nevhodné. 
>
> Mojí implemetaci nalezneš zde: 
> https://github.com/oarepo/oarepo-oai-pmh-harvester/blob/master/oarepo_oai_pmh_harvester/ext.py#L14,
>  
> kde mám nadefinovaný Singloton jako metaclassu, kterou používám v další 
> třídě: 
> https://github.com/oarepo/oarepo-oai-pmh-harvester/blob/master/oarepo_oai_pmh_harvester/ext.py#L25
>
> Hezký den
> Dan
>
> ne 31. 1. 2021 v 20:52 odesílatel fa...@orkasystems.cz <
> fa...@orkasystems.cz> napsal:
>
>> Ahoj,
>>
>> řeším následující problém. Mám třídu LmsDb která řeší připojení k 
>> databázi vypada to nějak takhle:
>>
>> class LmsDbClass:
>> def __init__(self):
>> self.options = LmsIniReader(lmsini_filename)
>> self.Database = pymysql.connect(host=self.options.dbhost,
>> user=self.options.dbuser,
>> password=self.options.dbpasswd,
>> db=self.options.dbname)
>>
>> def open(self):
>> self.Database.open()
>>
>> 
>>
>> Tak a ted resim, jak tuto tridu využívat, pokud z ní udělám potomky. 
>> Takhle to mam
>>
>> class TesstLms(LmsDbClass):
>> def __init__(self):
>> LmsDbClass.__init__(self)
>>
>> ale co mi vadi, ze kazdy potomek vytvori novou instanci toho LmsDbClass, 
>> chtel bych aby to bylo jen jednou.
>>
>> Jasne, mohu udelat neco takoveho:
>> Njeprve si vytvorim LmsDbClass
>>
>> lmsdata = LmsDbClass()
>>
>> a potomky upravim nejak takhle:
>> class TesstLms:
>> def __init__(self, lmsdata:LmsDbClass):
>> self.lmsdata = lmsdata
>>
>>
>> Jako funguje to, ale chtel bych se zeptat, jestli Python umí nějaký odkaz 
>> na již vytvořený objekt,  idealne neco takoveho :
>>
>> class TesstLms:
>> def __init__(self):
>> if globalnitridaLmsDbClass = None:
>> globalnitridaLmsDbClass = LmsDbClass()
>> self.lmsdata = globalnitridaLmsDbClass 
>>
>>
>> Jsem uplne mimo mísu? :)
>>
>>
>>
>>
>>
>> -- 
>> -- 
>> 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/8a5c788b-32f0-48e3-a088-822bf4389583n%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/dcc52206-15ea-4e1d-bdae-77c643c5e7dcn%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 pl

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.
>&g

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

[MirekZv]

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


{% 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ředefi

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

[MirekZv]

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 patchovat ten originální Django kód a jako kretén to 
>>>> upravovat pokaždé, když vyjde nová verze Djanga??
>>>>
>>>> -- 
>>>> -- 
>>>> 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/07164eea-9a91-4796-abd5-94eaabc3454bn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-cs/07164eea-9a91-4796-abd5-94eaabc3454bn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>

-- 
-- 
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/c167152a-1893-447c-801b-3727238c5fa5n%40googlegroups.com.

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

[MirekZv]

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 patchovat ten originální Django kód a jako kretén to 
>>> upravovat pokaždé, když vyjde nová verze Djanga??
>>>
>>> -- 
>>> -- 
>>> 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/07164eea-9a91-4796-abd5-94eaabc3454bn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-cs/07164eea-9a91-4796-abd5-94eaabc3454bn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
-- 
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/1f9bb2ee-9d38-43fd-b4c0-c7fa7952da25n%40googlegroups.com.

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

[MirekZv]

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 patchovat ten originální Django kód a jako kretén to 
>> upravovat pokaždé, když vyjde nová verze Djanga??
>>
>> -- 
>> -- 
>> 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/07164eea-9a91-4796-abd5-94eaabc3454bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/07164eea-9a91-4796-abd5-94eaabc3454bn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
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/1c8eb904-d327-46fa-96b3-57fa776cc73fn%40googlegroups.com.

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

[MirekZv]

PS: Potřeboval bych prostě buď umět includnout tu originální (ze 
stejnojmenné) nebo něco jako předefinovat {% block cela_originalni_sablona 
%} s voláním {{block.super}}.

Dne středa 10. února 2021 v 17:22:05 UTC+1 uživatel MirekZv napsal:

> 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 patchovat ten originální Django kód a jako kretén to 
> upravovat pokaždé, když vyjde nová verze Djanga??
>
>

-- 
-- 
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/a5b7af5b-ba4f-4aa8-91bb-24b05c453429n%40googlegroups.com.

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

[MirekZv]

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 patchovat ten originální Django kód a jako kretén to 
upravovat pokaždé, když vyjde nová verze Djanga??

-- 
-- 
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/07164eea-9a91-4796-abd5-94eaabc3454bn%40googlegroups.com.

Re: [django-cs] package pro file upload

[MirekZv]

Dík. Nakonec jsem to udělal s filepond + django-drf-filepond.

Dne sobota 26. prosince 2020 v 15:57:14 UTC+1 uživatel JirkaV napsal:

> Ja pouzivam dropzone.js. Ale uz jsem hodne let nezjistoval, jak je na tom 
> s aktualni podporou apod. Mrkni se na to, treba to bude to, co hledas. 
>
>   Jirka
>
> *From:* mirek@gmail.com
> *Sent:* 26 December 2020 11:15
> *To:* djan...@googlegroups.com
> *Reply to:* djan...@googlegroups.com
> *Subject:* [django-cs] package pro file upload
>
> Ahoj,
> chystám se teprv poprvé dělat něco s file uploadem,
> a přemýšlím, jestli si mám pro to vybrat nějakou package.
> Koukal jsem na djangopackages.org, ale asi žádná jasná volba. Dost 
> starých věcí, bez vývoje, pro Py 3.9 problematické.
>
> Nemáte někdo nějaké doporučení?
>
> Momentálně by mi stačil ukazatel průběhu importu,
> kupodivu nepotřebuju teď import do media/ (jde o upload a rozbalení 
> zálohy).
>
> Ale protože by se hodilo, abych to používal univerzálně do budoucna,
> tak dobrá podpora Images (náhled) by se taky hodila.
>
> Díky, jestli má někdo nějaký fajn tip
>
> -- 
> -- 
> 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/0b5c028e-0c87-47d0-9f4b-9b6e05f53833n%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/2bf2bf2c-ef82-4ba4-8d0a-0c93bf696350n%40googlegroups.com.

[django-cs] package pro file upload

[MirekZv]

Ahoj,
chystám se teprv poprvé dělat něco s file uploadem,
a přemýšlím, jestli si mám pro to vybrat nějakou package.
Koukal jsem na djangopackages.org, ale asi žádná jasná volba. Dost starých 
věcí, bez vývoje, pro Py 3.9 problematické.

Nemáte někdo nějaké doporučení?

Momentálně by mi stačil ukazatel průběhu importu,
kupodivu nepotřebuju teď import do media/ (jde o upload a rozbalení zálohy).

Ale protože by se hodilo, abych to používal univerzálně do budoucna,
tak dobrá podpora Images (náhled) by se taky hodila.

Díky, jestli má někdo nějaký fajn tip

-- 
-- 
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/0b5c028e-0c87-47d0-9f4b-9b6e05f53833n%40googlegroups.com.

Re: [django-cs] rq - redis queue

[MirekZv]

@I-V:
Díky. Tak jsem to měl původně udělané.
Ale rozhodně jdu na rq. Použiju tedy subprocess. Změním ten proces na 
synchronní, nějak takhle (zatím neodzkoušeno):
```
process = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE, shell=False)
stdout, stderr = process.communicate()
if stderr:
raise 
```

Má to pro mě 2 zásadní výhody.

1) Job zařazením do fronty dostane id. Pak můžu pomocí toho id a 
fronta.finished_job_registry.get_job_ids() a podobně 
fronta.failed_job_registry.get_job_ids() jednoduše zjistit, jestli příkaz 
skončil a jestli dobře nebo havaroval.
To potřebuju zjišťovat z ajaxu (jde o vytváření nebo zpětné nahrávání záloh 
z nějakého administračního panelu).

2) Integrace django_rq do admina se mi zdá perfektní, takže tam vidím 
všechno, co kdy spadlo. Chybu dostanu taky do Sentry. Ještě to nemám, ale 
snad se mi podaří přenést nějakým jednotným způsobem i stderr z bash 
skriptu do rq panelu i do Sentry.

A prostě celé mi to přijde takové robustnější  a systematičtější řešení.

Dne neděle 20. prosince 2020 v 22:36:16 UTC+1 uživatel Ing. Vladimir napsal:

> zavolej subrproses a dal neres. nic takovyho jako shell volani z rq si 
> nepamatuju. 
>
> On Sun, 20 Dec 2020, 22:01 MirekZv,  wrote:
>
>> Pouštěl jsem asynchronně nějaké bash scripty z pythoního kódu.
>> Pak jsem si řekl, že lépe dělat to lépe, a sáhnul po rq.
>>
>> Vypadá to, že to funguje krásně (celery by jistě taky byla krásná).
>> Ale umím jen spustit Python funkci.
>>
>> Dá se spustit příkaz shellu?
>> Pořád mám totiž pocit, že jsem někde četl, že pouštět lze jakékoli 
>> skripty.
>>
>> Zatím můžu tak leda udělat Python funkci, kde budu mít to subprocess 
>> volání,
>> tentokrát synchronně
>>
>> -- 
>> -- 
>> 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/7b3eb799-eb09-46a8-accc-9dfb54be9a2dn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/7b3eb799-eb09-46a8-accc-9dfb54be9a2dn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
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/78dc9523-26f9-4805-bc1c-6c5be81db22dn%40googlegroups.com.

Re: [django-cs] Jak používat redis a globální proměnné v Djangu

[MirekZv]

Díky Aleši 

Dne úterý 1. prosince 2020 v 14:23:15 UTC+1 uživatel Ales Zoulek napsal:

> Ahoj,
>
>
>
>
> On Sat, Nov 28, 2020 at 4:54 PM MirekZv  wrote:
>
>> Zdravím.
>> Je to trochu filozofická otázka, spíš jsem ji tak zkusil sepsat, i s 
>> pokusem o odpověď, abych si sám věci ujasnil.
>> Jestli někdo má trpělivost si to přečíst a má k tomu nějaký postřeh, 
>> samozřejmě vítám.
>>
>> Šéf mi dal toto zadání [zdravím, šéfe]:
>>
>> Produkty z různých skladů - chceme v redisu mít jejich celkový počet na 
>> všech skladech (ten pak vypisujeme v eshopu na obrazovku, kde je vždy 
>> několik produktů).
>>
>> Neznalý zacházení s redisem jsem to udělal tak, že jsem pro každý produkt 
>> udělal jeden klíč, něco jako stock_.
>>
>> Šéf pak řekl "ne-ne-né", my chceme mít jediný klíč a v něm dictionary 
>> {product_id: stock}.
>>
>> Tak to teď předělávám.
>> Ale vylíhlo se mi tu plno otázek:
>>
>> a) Mám-li u produktu nějakou funkci Product.get_stock() tak sice můžu v 
>> ní volat cache.get(),
>> u mého řešení 1produkt=1klíč toto ani nebyl problém,
>> ale tady tu celou velkou dict budu na stránce, kde je 20 produktů, z 
>> cache tahat 20x?
>>
> 1. Neznam vas setup (kde bezi redis, ani kolik produktu mate), ale obecne 
> bych si troufnul rict, ze to zasadni rozdil nebude. Pokud nemate opravdu 
> tunu tech produktu.
> 2. Redis umi HGET, kterej ti vrati jen jeden prvek z toho dictu a pak je 
> to ekvivalentni s tvym puvodnim resenim. (Ale pak musis s redisem 
> komunikovat primo pomoci redis knihovny, django cache api to myslim neumi.)
> 3. Spis bych se soustredil na to, co je lehci spravovat. Jak se to bude 
> invalidovat? Je lepsi mit globalni ttl na cely dict? Nebo po jednotlivych 
> produktech? Nebo budete "vzdy" invalidovat rucne?
>
>
>
>> b) Tak bych si ji měl asi někam uložit. Ale kam?
>> Třeba bych si uměl představit, navěsit ji na request, jenže u metod 
>> modelu se asi k requestu nedostano snadno.
>>
> V zasade bych se 20ti requestu do redisu nebal, ale muzes pouzit treba 
> https://pypi.org/project/django-request-cache/ coz je cache, ktera se 
> invaliduje s kazdym requestem.
>  
>
>>
>> c) Nakonec by ani nebylo špatné mít to úplně trvalé, jako atribut 
>> nějakého globálního objektu. Jenže - je v Djangu něco takového? (napadá mě 
>> jedině: Product._meta)
>> Jenže stejně by zas byl problém, že se z toho stane taková další level 
>> cache a bude potřeba to nějak synchronizovat se změnami stavu.
>>
> To bych radsi nedelal. Od toho prave mas ten redis :)
>  
>
>>
>> Zkusím si nějak odpovědět:
>> Když něco řeším u produktu, nemůžu vědět, jestli to bude potřeba v rámci 
>> requestu nebo jinak (management command). Takže řešit obecně nějaké uložení 
>> na nějakou dobu je problém. Můžu leda tak zavést parametr stock=None, který 
>> když bude None, načte se cache.get() během té funkce. A tam, kde mám pocit, 
>> že by se opakovaná volání vyplatilo optimalizovat, můžu to načíst předem 
>> (např. na začátku view) a předávat už hotové tím parametrem.
>>
>> Pozn.:
>> Na naplnění té cache chceme použít nějaký anotovaný queryset 
>> Product.objects.with_stock().
>> Ještě mě napadlo, že by bylo bezva, kdyby ten queryset vrátil ten stav 
>> skladu z Redisu, pokud to v tom Redisu už je.
>> Jenže to asi není možné z principu věci, protože queryset se vždy jen 
>> hrabe v databázi, že (?).
>>
>> -- 
>> -- 
>> 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/535fec5d-e3e7-4d4a-9ab6-d364c275d14bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/535fec5d-e3e7-4d4a-9ab6-d364c275d14bn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
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/d13f99d8-b7c9-44b0-aad3-526d54ebd509n%40googlegroups.com.

[django-cs] rq - redis queue

[MirekZv]

Pouštěl jsem asynchronně nějaké bash scripty z pythoního kódu.
Pak jsem si řekl, že lépe dělat to lépe, a sáhnul po rq.

Vypadá to, že to funguje krásně (celery by jistě taky byla krásná).
Ale umím jen spustit Python funkci.

Dá se spustit příkaz shellu?
Pořád mám totiž pocit, že jsem někde četl, že pouštět lze jakékoli skripty.

Zatím můžu tak leda udělat Python funkci, kde budu mít to subprocess volání,
tentokrát synchronně

-- 
-- 
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/7b3eb799-eb09-46a8-accc-9dfb54be9a2dn%40googlegroups.com.

Re: [django-cs] Importy v Pythonu - filozofická a rebelská otázka

[MirekZv]

Omlouvám se. Smazal jsem svůj nejapný dotaz, proto to není na webovém 
rozhraní.
Byl jsem tou svojí myšlenkou tak zaujatý, že jsem to sepsal, a pak jsem se 
teprve na chvíli zamyslel.
Takže jsem došel k tomu, co píše pe...@bla.. (tedy jen tu část o dědění 
tříd).
Tak jsem se zastyděl a smazal dotaz - nedošlo mi, že je to i mailová 
konference.

Takže dát import příkazy, které nejsou během importu modulu potřeba na 
konec, by sice circular import řešilo,
- ale jednak je to spíš obejití než řešení (jak píše pe...),
- jednak, když něco nahoře být musí, tak to ztrácí veškerou eleganci.
To už to pak můžu naimportovat přímo v té definici funkce, když nejsem 
schopen ten circular import řešit správnější strukturou celého projektu.

Ještě jednou se omlouvám a dík.

Dne pondělí 30. listopadu 2020 v 11:00:17 UTC+1 uživatel 
jakub@gmail.com napsal:

> +1 ke vsem Petrovym odpovedim a +1 k jeho otazce: dva posledni Mirkovy 
> dotazy prisly 2x pokazde s nejakou opravou v $SUBJ - muzu poslat screenshot 
> z mojeho Inboxu - nicmene na webovem rozhrani 
> https://groups.google.com/g/django-cs to nevidim.
>
> Mejte se!
>
>
> On Mon, Nov 30, 2020 at 10:43 AM Petr Blahoš  wrote:
>
>> Proč se vlastně v Pythonu importuje na začátku souboru a ne na konci?
>>
>>
>> No, já nevím. Když jdu okopávat zahrádku, tak si nejprve vezmu motyku, a 
>> pak 
>> to okopu. Není to tak, že to nejprve okopu, a pak si jdu pro motyku. 
>> Nehledě na to,
>> že když si definuju třídu, která dědí od něčeho, co importuju, tak bych 
>> asi měl 
>> importovat předtím. No a nakonec, to že importuju na začátku mě nutí 
>> organizovat
>> věci tak, abych neměl circular imports :-)
>>
>>  [...]
>>
>>> Mám třeba Django model a v něm chci použít nějakou obecnou utilitu. A 
>>> obecná utilita potřebuje jiný model ze stejného souboru.
>>>
>>> Končím circular importem :(
>>> Takže můžu:
>>> 1) předat model do utility parametrem [trochu hnusné]
>>> 2) naimportovat až v kódu metody (a nahoře si třeba napsat poznámku, že 
>>> něco vynuceně importuju v kódu metody [dost hnusné]
>>>
>>
>> Spíš bych se zamyslel, jestli bych to neměl strukturovat jinak. Obecná 
>> utilita by neměla vyžadovat 
>> specifický model.
>>
>> A nebo můžu vše importovat na konci a circular importy nevzniknou.
>>> To mi přijde minimálně stejně elegantní jako importovat nahoře.
>>> A řeší to vážný problém.
>>>
>>
>> Neřeší. Obejde. 
>>  
>>
>>> Co myslíte .??
>>>
>>
>> Mě vrtá hlavou, že poslední 2 maily od Tebe přišly 2x s drobnýma 
>> rozdílama. Tak si říkám, zda o tom víš,
>> a čím to je. Ne že by mi to vadilo, při téhle četnosti mailů v 
>> konferenci, ale říkám si, jak to vznikne.
>>
>> --
>> Petr
>>
>>
>> -- 
>> -- 
>> 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/CA%2ByMeXWkozuDALkPYVMaubMYCd3xQ5y7J31g7JH3c_MACSAX%2BA%40mail.gmail.com
>>  
>> 
>> .
>>
>
>
> -- 
> Jakub Vysoky
>
> mob: +420 605 852 377 <+420%20605%20852%20377>
> jab: jakub@gmail.com
> twit: https://twitter.com/kvbik
>

-- 
-- 
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/1a91b7b3-4d3e-4f1f-9db6-5dd7f21322f7n%40googlegroups.com.

[django-cs] Importy v Pythonu - filozofická a rebelská otázka

[MirekZv]

Proč se vlastně v Pythonu importuje na začátku souboru a ne na konci?

Vážně přemýšlím, že to ve svém (soukromém) kódu začnu dělat jinak.

Nejsme přece žádní C#-sté nebo Javaři, abych nás víc zajímalo vidět 
deklarace než vidět kód.
Ale tím chci jen říct, že není důvod na tom lpět, nechci tím říct, že to by 
byl důvod pro změnu.

ALE:

Mám třeba Django model a v něm chci použít nějakou obecnou utilitu. A 
obecná utilita potřebuje jiný model ze stejného souboru.

Končím circular importem :(
Takže můžu:
1) předat model do utility parametrem [trochu hnusné]
2) naimportovat až v kódu metody (a nahoře si třeba napsat poznámku, že 
něco vynuceně importuju v kódu metody [dost hnusné]

A nebo můžu vše importovat na konci a circular importy nevzniknou.
To mi přijde minimálně stejně elegantní jako importovat nahoře.
A řeší to vážný problém.
Co myslíte .??

-- 
-- 
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/e42be17c-0c75-42fb-b6db-df34ecaf1ab4n%40googlegroups.com.

[django-cs] Importy v pythonu - filozofická a rebelská otázka

[MirekZv]

Proč se vlastně v Pythonu importuje na začátku souboru a ne na konci?

Vážně přemýšlím, že to ve svém (soukromém) kódu začnu dělat jinak.

Nejsme přece žádní C#-sté nebo Javaři, abychom nás víc zajímalo vidět 
deklarace než vidět kód.
Ale tím chci jen říct, že není důvod na tom lpět, nechci tím říct, že to by 
byl důvod pro změnu.

ALE:

Mám třeba Django model a v něm chci použít nějakou obecnou utilitu. A 
obecná utilita potřebuje jiný model ze stejného souboru.

Končím circular importem :(
Takže můžu:
1) předat model do utility parametrem [trochu hnusné]
2) naimportovat až v kódu metody (a nahoře si třeba napsat poznámku, že 
něco vybuceně importuju v kódu metody [dost hnusné]

A nebo můžu vše importovat na konci a circular importy nevzniknou.
To mi přijde minimálně stejně elegantní jako importovat nahoře.
A řeší to vážný problém.
Co myslíte .??

-- 
-- 
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/1456fc8c-1901-4655-ad37-21862e394ecan%40googlegroups.com.

[django-cs] Jak používat redis a globální proměnné v Djangu

[MirekZv]

Zdravím.
Je to trochu filozofická otázka, spíš jsem ji tak zkusil sepsat, i s 
pokusem o odpověď, abych si sám věci ujasnil.
Jestli někdo má trpělivost si to přečíst a má k tomu nějaký postřeh, 
samozřejmě vítám.

Šéf mi dal toto zadání [zdravím, šéfe]:

Produkty z různých skladů - chceme v redisu mít jejich celkový počet na 
všech skladech (ten pak vypisujeme v eshopu na obrazovku, kde je vždy 
několik produktů).

Neznalý zacházení s redisem jsem to udělal tak, že jsem pro každý produkt 
udělal jeden klíč, něco jako stock_.

Šéf pak řekl "ne-ne-né", my chceme mít jediný klíč a v něm dictionary 
{product_id: stock}.

Tak to teď předělávám.
Ale vylíhlo se mi tu plno otázek:

a) Mám-li u produktu nějakou funkci Product.get_stock() tak sice můžu v ní 
volat cache.get(),
u mého řešení 1produkt=1klíč toto ani nebyl problém,
ale tady tu celou velkou dict budu na stránce, kde je 20 produktů, z cache 
tahat 20x?

b) Tak bych si ji měl asi někam uložit. Ale kam?
Třeba bych si uměl představit, navěsit ji na request, jenže u metod modelu 
se asi k requestu nedostano snadno.

c) Nakonec by ani nebylo špatné mít to úplně trvalé, jako atribut nějakého 
globálního objektu. Jenže - je v Djangu něco takového? (napadá mě jedině: 
Product._meta)
Jenže stejně by zas byl problém, že se z toho stane taková další level 
cache a bude potřeba to nějak synchronizovat se změnami stavu.

Zkusím si nějak odpovědět:
Když něco řeším u produktu, nemůžu vědět, jestli to bude potřeba v rámci 
requestu nebo jinak (management command). Takže řešit obecně nějaké uložení 
na nějakou dobu je problém. Můžu leda tak zavést parametr stock=None, který 
když bude None, načte se cache.get() během té funkce. A tam, kde mám pocit, 
že by se opakovaná volání vyplatilo optimalizovat, můžu to načíst předem 
(např. na začátku view) a předávat už hotové tím parametrem.

Pozn.:
Na naplnění té cache chceme použít nějaký anotovaný queryset 
Product.objects.with_stock().
Ještě mě napadlo, že by bylo bezva, kdyby ten queryset vrátil ten stav 
skladu z Redisu, pokud to v tom Redisu už je.
Jenže to asi není možné z principu věci, protože queryset se vždy jen hrabe 
v databázi, že (?).

-- 
-- 
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/535fec5d-e3e7-4d4a-9ab6-d364c275d14bn%40googlegroups.com.

[django-cs] Používání redisu a globální proměnné v Django

[MirekZv]

Zdravím.
Je to trochu filozofická otázka, spíš jsem ji tak zkusil sepsat, i s 
pokusem o odpověď, abych si sám věci ujasnil.
Jestli někdo má trpělivost si to přečíst a má k tomu nějaký postřeh, 
samozřejmě vítám.

Šéf mi dal toto zadání [zdravím, šéfe]:

Produkty z různých skladů - chceme v redisu mít jejich celkový počet na 
všech skladech (ten pak vypisujeme v eshopu na obrazovku, kde je vždy 
několik produktů).

Neznalý zacházení s redisem jsem to udělal tak, že jsem pro každý produkt 
udělal jeden klíč, něco jako stock_.

Šéf pak řekl "ne-ne-né", my chceme mít jediný klíč a v něm dictionary 
{product_id: stock}.

Tak to teď předělávám.
Ale vylíhlo se mi tu plno otázek:

a) Mám-li u produktu nějakou funkci Product.get_stock() tak sice můžu v ní 
volat cache.get(),
u mého řešení 1produkt=1klíč to ani nebyl problém,
ale tady tu celou velkou dict budu na stránce, kde je 20 produktů, z cache 
tahat 20x?

b) Tak bych si ji měl asi někam uložit. Ale kam?
Třeba bych si uměl představit, navěsit ji na request, jenže u metod modelu 
se asi k requestu nedostano snadno.

c) Nakonec by ani nebylo špatné mít to úplně trvalé, jako atribut nějakého 
globálního objektu. Jenže - je v Djangu něco takového? (napadá mě jedině: 
Product._meta)
Jenže stejně by zas byl problém, že se z toho stane taková další level 
cache a bude potřeba to nějak synchronizovat se změnami stavu.

Zkusím si nějak odpovědět:
Když něco řeším u produktu, nemůžu vědět, jestli to bude potřeba v rámci 
requestu nebo jinak (management command). Takže řešit obecně nějaké uložení 
na nějakou dobu je problém. Můžu leda tak zavést parametr stock=None, který 
když bude None, načte se cache.get() během té funkce. A tam, kde mám pocit, 
že by se opakovaná volání vyplatilo optimalizovat, můžu to načíst předem 
(např. na začátku view) a předávat už hotové tím parametrem.

-- 
-- 
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/752008eb-cd75-4a2c-935a-20705ff8be0fn%40googlegroups.com.

Re: [django-cs] Volba cms nebo wiki

[MirekZv]

Díky za tip.
Já bych spíš chtěl přičlenit něco djangového ke Djangu, jako postranní věc 
k aplikaci. Možná je to trochu předsudek, nevím.
Takže bych rád zjistil nějaký názor na související django-xxx aplikace, 
kterou cestou se vydat.

Dne úterý 6. října 2020 v 15:24:12 UTC+2 uživatel Messa napsal:

> Pokud by to mohlo být samostatné řešení, tak hodně teď frčí 
> https://www.notion.so/
>
> Nebo prostě Github wiki :) Připadně Github discussions.
>
> Petr Messner
>
> út 6. 10. 2020 v 11:55 odesílatel MirekZv  napsal:
>
>> Ahoj,
>> chtěl bych si používat k projektu (nebo projektům) nějaký postranní 
>> systém na ne-databázově uspořádané informace - volné texty. Nějakou cms 
>> nebo wiki (na návody, znalosti, zkušenosti, diskuze).
>> Např. na url wiki/, zatímco na url / by byl hlavní projekt.
>>
>> Tuším, že jsou asi 3 běžné cms pro Django, potom django-wiki (zkusil jsem 
>> a nadšený nejsem).
>> Co ještě přehlížím? Nebo co byste z předchozího vybrali?
>>
>>
>>

-- 
-- 
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/889aeb4e-eb64-4b58-b909-53c757b795c5n%40googlegroups.com.

[django-cs] Volba cms nebo wiki

[MirekZv]

Ahoj,
chtěl bych si používat k projektu (nebo projektům) nějaký postranní systém 
na ne-databázově uspořádané informace - volné texty. Nějakou cms nebo wiki 
(na návody, znalosti, zkušenosti, diskuze).
Např. na url wiki/, zatímco na url / by byl hlavní projekt.

Tuším, že jsou asi 3 běžné cms pro Django, potom django-wiki (zkusil jsem a 
nadšený nejsem).
Co ještě přehlížím? Nebo co byste z předchozího vybrali?

-- 
-- 
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/5a346ab3-0203-44d2-a49d-1289b191cb81n%40googlegroups.com.

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

[MirekZv]

Zaujalo mě, že se tady vůbec neprobírá možnost použít Sites framework (ze 
základní instalace, contrib.sites).
Pak bys udržoval jeden kód, který by pouze v settings.py dělal: from 
konfigurace_tehle_firmy import SITE_ID, a kód by sis větvil: if 
SITE_ID=n:...
Resp. pokud v konfiguráku SITE_ID nemáš, tj. máš společný konfigurák pro 
více zákazníků, tak Sites framework určí SITE_ID podle domény (url).
Neboli, dávalo by Ti to možnost pro větší zákazníky mít extra instalaci a 
extra databázi.

Jinak s multitenant jsem si něco zkoušel, konkrétně s 
django-tenant-schemas, které mají každou kopii databáze jako jedno Postgres 
schéma a podle domény (např. podle domény 3.řádu: zakaznik.sluzba.cz) 
vyberou schéma, se kterým pracují.
Funguje to, zdá se dobře.
Seznam zákazníků si uděláš do své aplikace např. customer, do tabulky např. 
customers.Customer. Je otázka, jestli by to šlo směřovat přímo na djangové 
Sites, to asi ne (asi nebudou sedět pole, která má Sites a pole, která chce 
django-tenant-schemas), ale neměl by být problém nějak druhotně určit to 
SITE_ID, abys mohl větvit kód podle zákazníka, pokud má mít něco extra.

No a nebo to zkombinovat nějak jakkoli jinak: třeba nastavené SITE_ID by 
znamenalo produkční instalaci, přičemž ta by buď jela přímo (velký 
zákazník, vše pro něj extra), nebo s django-tenant-schemas + tabulkou 
Customers (malý zákazník, sdílí Postgres cluster).
Kombinace SITE_ID a customers.id by pak dávala unikátní klíč, který určuje 
zákazníka. Ten třeba pomocí nějaké tabulky centrální evidence zákazníků 
změnit na string, a větvit úplně obyčejně: if request.zakaznik='TESCO':...

Napsal jsem schválně request.zakaznik, protože takovou věc je asi vhodné 
přiřadit v middlewaru (=vždy).


Dne čtvrtek 17. září 2020 v 13:58:49 UTC+2 uživatel Messa napsal:

> Ahoj,
>
> pár nápadů:
>
> - je fajn si rozmyslet, jestli chceš provozovat pro každého klienta 
> samostatnou instanci (kontejner apod.), nebo to mít vše v jedné. Se 
> samostatnými instancemi je víc režie, ale zase je např. omezený blast 
> radius, pokud se něco u jedné z nich podělá. Samostatné instance bych asi 
> řešil jen pokud jich bude třeba do deseti. Na druhou stranu my třeba víc 
> instancí toho samého používáme pro škálování (sharding) a pro 
> speciální deploymenty pro "VIP klienty", ale všechny instance mají stejný 
> kód, jen jinou db.
>
> - chce to trochu software engineering :) Víc git větví bych nedělal, do 
> toho se můžeš zamotat, a nebo se v tom pak už nevyzná někdo, s kým bys na 
> tom případně spolupracoval. Spíš by tě mohly zajímat feature flagy, design 
> patterny pro pluginy, věci trochu víc zapouzdřit, než v Djangu bývá 
> běžné... Oddělovat věci do knihoven nebo modulů... Možná se nejdřív 
> zamyslet, jak bys to dělal, kdyby to byl normální softwarový projekt (který 
> začíná main funkcí a vše řeší explicitně), a pak přijít na to, jak to 
> udělat v Djangu :)
>
> - možná by stálo zato to rozdělit do komponent. Např. backend bude stejný, 
> frontend se může lišit u každého klienta. Btw. toto teď řeší Shoptet 
> Premium, vyšlo o nich pár podcastů, mají zajímavý přístup (ale neříkám, že 
> bych to dělal přesně takto).
>
> - asi by ses neměl bránit zlepšování se v devops praktikách :) Když děláš 
> takovéhle věci, tak to chce mít infrastrukturu, o kterou se můžeš opřít.
>
> - je otázka, jak naložit s databází (v podstatě pro ni platí ty samé úvahy 
> výše, jako pro celou aplikaci), to by chtělo vědět, co tam bude za data a 
> jestli/jak se mohou mezi klienty strukturně lišit. Tady mám třeba 
> zkušenosti s tím, že jsme na několika místech udělali 
> overengineered generalizovaný systém, který by měl teoreticky zvládnout 
> jakéhokoliv klienta (resp. jeho data) nějakým univerzálním způsobem, ale 
> pak to stejně shořelo na něčem, s čím nikdo vůbec nepočítal :) a takový 
> systém pak tvoří zbytečná omezení nebo dokonce hacky (což je paradoxně to, 
> čemu měl ten systém zabránit). Takže nakonec máme spíš kód, který na první 
> pohled vypadá duplikovaný (což triggeruje programátorské ADHD) ale zase je 
> triviálně přehledné, co to dělá a jak se logika liší mezi jednotlivými 
> klienty. Mimochodem mě se tady líbí nosql přístup, ve kterém se 
> můžeš vyhnout migracím a může být jednodušší pracovat s mnoha "malými" 
> databázemi/kolekcemi, včetně operations aspektů; ale nosql a django možná 
> není dobrá kombinace.
>
> Jako tohle jsou přesně věci, které když se pokazí, tak rozpočet, kvalita 
> kódu a použitelnost projektu jdou přes palubu :) Ale jestli to 
> programuješ sám, tak snad nebudeš moc trpět sunken cost syndromem.
>
> Petr
>
> so 12. 9. 2020 v 0:25 odesílatel stanisl...@gmail.com <
> stanisl...@gmail.com> napsal:
>
>> Zdravím,
>>
>> potřeboval bych poradit či navést na best-practice v Django, jak jeden 
>> projekt nasadit pro více firem, ale tak, abych v čase mohl dělat klientské 
>> modifikace. Aktuálně jsem vymyslel aplikaci a používají ji 2 moji klienti. 
>> Django aplikace běží na nGinx a abych mohl obě 

[django-cs] hlavně se nezbláznit

[MirekZv]

to je zas dneska den

-- 
-- 
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/2e62d2ea-1531-46bc-b8fa-512750816112n%40googlegroups.com.

[django-cs] Re: Dotaz začátečníka

[MirekZv]

A zkus si to nějak líp strukturovat, aby ses neopakoval, něco jako:

kl = "deravec"  
for i in range(3):  
if input ("Zadej klic: ") == kl:  
break  
else:  
raise Exception('unauthorized')  
print("Dobre") 




Dne středa 15. ledna 2020 16:40:46 UTC+1 Pavel Bechyne napsal(a):
>
> jj Děkuji už to jde. Ach jo...
>
> Dne středa 15. ledna 2020 15:52:00 UTC+1 Pavel Bechyne napsal(a):
>>
>> Dobrý den,
>>
>> nevíte prosím proč to stále nefunguje?
>>
>>
>>
>>
>> kl = "deravec"
>> name = input ("Zadej klic: ")
>> if name == kl:
>> print("Dobre")
>> else:
>> name = input ("Zadej klic: ") 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> if name == kl:
>> ^
>> IndentationError: unexpected indent
>>
>

-- 
-- 
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/98c73db0-4318-4ee7-ac43-ca2b07346e02%40googlegroups.com.

[django-cs] Lehká modernizace javascriptu

[MirekZv]

Chci začít nějaký nový vlastní hobby projekt, backend Django, frontend 
javascript - jen minimalisticky.
TypeScript - zásadně ne (nespamujte prosím na toto téma).
React, Vue - něco bych chtěl do budoucna, snad Vue, ale teď nedokážu najít 
čas se to naučit.
Takže asi jen jQuery a otázka k modernizaci je:
1) spouštět lokální nebo CDN/cloudovou verzi js knihoven?
2) je vhodné jít přes Babel a pracovat v nějaké moderní verzi 
js/ecmascriptu? Ve které? - což mi možná vyřeší i některou z následujících 
otázek?
3) jak nejlíp pracovat se šíleným javascriptovským this? Tady asi odpověď 
znám, jestli mě nenasměrujete ještě líp: (function() {..}).bind(this)
4) jak je dnes moderní a perspektivní js do html připojit? Jednotlivé js? 
Nebo bundlovat do velkého souboru a čím? Jak pracovat s externími jmény 
proměnných místo prastaré prasárny (jména z dříve spuštěných skriptů 
přístupná jako window.xxx). Používá se import? Nebo require?
... a jedna specificky Djangovská 5) jde se vždy přes 

[django-cs] django forms problém s typem hidden pole

[MirekZv]

Zdravím, lidi, mám takovouto potíž:


Stavem state_id řídím ve formsetech viditelnost checkboxu update_it,
ale checkboxy po selhané validaci zmizí kvůli problémům s typem state_id.

DETAILNĚJI:

class NejakejFormPouzivanyVeFormsetu(forms.Form):
update_it = forms.BooleanField(required=False)
state = forms.CharField(required=False, disabled=True)
state_id = forms.IntegerField(widget=forms.widgets.HiddenInput, 
required=False)

update_id je checkbox, který zobrazuju v každém formuláři toho formsetu
state_id/state souvisí s CHOICES=.., state_id=0,1,2, kdežto state je totéž 
textově: NEW, PARTIAL, COMPLETED

state_id má skrýt ten checkbox, jestliže není state==0/NEW

state_id jsem přidal jako hidden field, aby mi přežilo failed-validation

JENŽE:

po form-get je state_id Integer (protože ho tak nastavuju, shodně s 
.IntegerField)
po form-post-failed-validation je Char (v cleaned_data je samozřejmě 
správně Integer)

Takže test v templatě:
  form.state_id.value == 0
mi po selhané validaci selže - a checkboxy zmizí ze všech řádků, i z těch 
NEW, kde mají být zobrazeny


VYŘEŠIL JSEM TO JEDINĚ TAK,
že jsem state_id změnil na CharField a taky tu konstantu předávám templatě 
jako str(konstanta)


Přijde mi to ale takové protisrstné, 
Když 0,1,2 jsou Integer CHOICES.

Nemáte nějaký lepší nápad, jak to dělat?

- buď nechat rozdílný typ pro GET a pro POST, a nějak upravit ten výraz v 
templatě form.state_id.value==0, aby si poradil s oběma typy
- nebo ještě lépe: jak předat templatě jednotný typ Integer v obou 
případech?

-- 
-- 
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/a55a7393-4145-4984-bb39-bbd39e484927%40googlegroups.com.

Re: [django-cs] Vhodný upload widget?

[MirekZv]

No, hele, já ani moc nevím, co je widget nebo widget v django smyslu nebo 
widget v javascript smyslu.
Ale zkoušel jsem pár packages, které to prostě pomocí nastavení widget=... 
připojujou, což mi přijde docela elegantní. Např. se dá udělat 
formfield_overrides = {models.FileField: {'widget': XWidget}}
a mám to všude, a stejně snadno to zas můžu vyhodit nebo nahradit něčím 
jiným, jestli někdy něco přijatelnějšího bude.

Zatím laboruju s django-sticky-uploads, ale chtěl jsem vědět, jestli třeba 
něco podstatně lepšího nepřehlížím.

Co se týká funkce, potřebuju, aby se choval upload úplně stejně, jako 
ostatní inputy:
když do nich něco napíšeš a submitneš stránku s nevyplněným povinným 
údajem, tak to, cos tam napsal tam zůstane.
V případě uploadu to musí uživatel hledat znova po disku, což ho jistě 
potěší, když tam připíchnul třeba 3 soubory (nehledě na to, že jejich 
zmizení může přehlédnout).

Validace se provádí úplně standardně na serveru po submitu, na základě 
toho, jestli je pole definováno v modelu jako povinné.
Proprietárně si to fakt řešit nehodlám.




Dne středa 15. května 2019 12:52:54 UTC+2 JirkaV napsal(a):
>
> Asi necemu nerozumim, ale "aby prilozene soubory prezily submit + selhanou 
> validaci" prece neni otazkou widgetu, ne? To si musis zajistit ve formu 
> pripadne tam, kde validaci provadis.
>
> Co se tyka upload widgetu, jsem celkem spokojeny s 
> https://www.dropzonejs.com/ - ale je to pouze na strane JS, nemuzes to 
> napojit rovnou na FileField.
>
>   Jirka
>
> On Wed, 15 May 2019 at 12:39, MirekZv > 
> wrote:
>
>> Musím vybrat nějaký upload widget pro py3/dj2, tedy něco, co připojím na 
>> FileField pomocí widget=...
>> Zatím jde o dokumenty, samozřejmě, kdyby to mělo i něco extra pro 
>> ImageField, nezlobil bych se.
>>
>> Ale zásadní požadavek je teď jediný: aby přiložené soubory přežily submit 
>> + selhanou validaci a uživatel je nemusel zadávat znova.
>>
>> Trochu jsem pokoukal a něco vyzkoušel, ale situace se mi zdá skoro 
>> tragická.
>> Třeba jsem něco přehlédl, nemáte pro mě nějaký tip?
>>
>> Díky, Mirek
>>
>> -- 
>> -- 
>> 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 djan...@googlegroups.com .
>> Chcete-li tuto diskusi zobrazit na webu, navštivte 
>> https://groups.google.com/d/msgid/django-cs/3857364e-d6bb-48af-9327-8fa070c70c2f%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/3857364e-d6bb-48af-9327-8fa070c70c2f%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> Další možnosti najdete na https://groups.google.com/d/optout.
>>
>

-- 
-- 
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/e18872cc-7d3d-4cc1-82c3-b8f09440cf92%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Vhodný upload widget?

[MirekZv]

Musím vybrat nějaký upload widget pro py3/dj2, tedy něco, co připojím na 
FileField pomocí widget=...
Zatím jde o dokumenty, samozřejmě, kdyby to mělo i něco extra pro 
ImageField, nezlobil bych se.

Ale zásadní požadavek je teď jediný: aby přiložené soubory přežily submit + 
selhanou validaci a uživatel je nemusel zadávat znova.

Trochu jsem pokoukal a něco vyzkoušel, ale situace se mi zdá skoro tragická.
Třeba jsem něco přehlédl, nemáte pro mě nějaký tip?

Díky, Mirek

-- 
-- 
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/3857364e-d6bb-48af-9327-8fa070c70c2f%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] SITE ?

[MirekZv]

Ahoj,

prosím Tě, uvedl byste mě někdo spíš než jen vysvětlením nějakým příkladem 
uspořádání, co to je SITE=.. ?

Hledám totiž něco, co by mi umožnilo dělat něco jako ve Web2py 
common_filter.
common_filter ve Web2py pracuje tak, že mám pole v tabulce třeba idOrg, 
nastavím třeba idOrg=5, a všechny sestavené sql dotazy dostanou přidáno 
WHERE ... AND idOrg=5. Taky do každého nově vytvořeného záznamu se 
automaticky přidá idOrg=5. Neboli píšu soft jako by byl určen pro jednu 
organizaci, ale tímhle nastavením se mi stejné tabulky stejné databáze 
zafiltrují jen pro aktuálně zvolenou organizaci.

Předpokládám, že SITE je něco úplně jiného. Ale i tak bych to chtěl trochu 
pochopit.

A samozřejmě, jestli je nějaký nápad, jak v Djangu dělat výše uvedené 
chování, tak to bych si přečetl moc rád.

Díky

-- 
-- 
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/70ed76d6-d66f-4cd6-9740-f50a17937d2d%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: lokalizované url v templatě

[MirekZv]

Ok. Moje chyba.
Jeden odkaz šel z templaty - ten mě zmátnul, ale ten byl dobře.
Ale další ještě vytváří Javascript a ty jsou špatně (bez en/,..).
Takže to si musím v Javascriptu ošéfovat sám. Nebo...je nějaký doporučovaný 
postup i na url v Javascriptu?




Dne středa 17. dubna 2019 19:52:56 UTC+2 MirekZv napsal(a):
>
> Ahoj.
>
> V urls.py používám
>   from django.conf.urls.i18n import i18n_patterns
>   i18n_patterns(.., .., prefix_default_language='cs')
>
> V templatě mám {% load i18n %}, takže funguje {% trans ... %}
>
> Ale jak to mám dělat s {% url ...%} ?
> Mám třeba data-href="{% url 'admin:...' %}"
> na to skočím pomocí javascriptu
>
> .. a aktuální chování je,
> že chrome mi zůstane na /cs,
> firefox jde na /en
>
> Jak to můžu napravit?
> Díky...
>
>
>

-- 
-- 
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/6ffd6834-8a81-42e4-af3f-28596b0f5849%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] lokalizované url v templatě

[MirekZv]

Ahoj.

V urls.py používám
  from django.conf.urls.i18n import i18n_patterns
  i18n_patterns(.., .., prefix_default_language='cs')

V templatě mám {% load i18n %}, takže funguje {% trans ... %}

Ale jak to mám dělat s {% url ...%} ?
Mám třeba data-href="{% url 'admin:...' %}"
na to skočím pomocí javascriptu

.. a aktuální chování je,
že chrome mi zůstane na /cs,
firefox jde na /en

Jak to můžu napravit?
Díky...


-- 
-- 
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/51ada4fb-dcf3-4461-b8fb-ccf548f1bfd3%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: než se z toho Djanga zblázním: urls.py (moje otázka potřetí jinak)

[MirekZv]

Jdu od toho.
Zjistil jsem, že urls.py mám možná dobře. Podrobněji viz předchozí vlákno.

Z include() v hlavním urls.py jsem druhý parametr vyhodil úplně,
v includovaném aplikačním urls.py jsem zatím nechal app_name='cile' (místo 
'isms.cile').
Škoda, že v dokumentaci ke 2.x není lepší info k urls.py, když už se to 
nějak měnilo proti 1.x.

-- 
-- 
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/c776bae3-a1df-41ad-8307-f95a0339fc53%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: než se z toho Djanga zblázním: app_name, app_label, NoReverseMatch

[MirekZv]

Jdu od toho.
Zjistil jsem, že urls.py (hlavní i includovaný z aplikace 'cile') mám možná 
dobře,
ale ta náhrada admin.site.get_urls funkce v admin.py se dělá moc brzo.
Ve hře je tam nějaký URLResolver, který si teprve střádá položky a tu 
aktuální aplikaci tam ještě nemá.
Když ten zásah udělám do některé jiné předchozí aplikace, tak se ten 
problém přesune (pochopitelně) tam, ale ten pattern z chybové hlášky je 
kratší.
Neboli jsem zjistil, že chyba není v tom, že u aplikace 'cile' jako jediné 
includuji urls.py (a domníval jsem se, že tam mám něco blbě),
ale problém je v tom, že se asi nějak změnila logika a návod pro Django 1.x 
už nelze použít ve 2.x.

Jinak ten app_list nebyl z projektu, po likvidaci django-jetu nebyl ani z 
něj, ale je přímo v templatách admina.*)

Z include() v hlavním urls.py jsem druhý parametr vyhodil úplně,
v includovaném aplikačním urls.py jsem zatím nechal app_name='cile' (místo 
'isms.cile').
Škoda, že v dokumentaci ke 2.x není lepší info k urls.py, když už se to 
nějak měnilo proti 1.x.

Díky za pomoc.

*) kolega mezitím našel toto:
"This is caused most likely because you have a {% url %} tag that is trying 
to link to the app_list. It could be in your admin/form_change.html or in 
some other included/extended template.
This is usually caused by context that is not passed correctly such as if 
you have a tag that looks like {% url 'app_list' %} or {% url 'app_list' 
var %} and the var is empty."
(https://stackoverflow.com/questions/28777376/problems-extend-change-form-html-in-django-admin)

-- 
-- 
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/4260e293-6c35-4546-be5b-1dbc9cafc78e%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Re: než se z toho Djanga zblázním: app_name, app_label, NoReverseMatch

[MirekZv]

V okně browseru je ten traceback (3) kratší:

Environment:


Request Method: GET
Request URL: http://localhost:8000/

Django Version: 2.1.2
Python Version: 3.7.0
Installed Applications:
['dal',
 'dal_select2',
 'ajax_select',
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'django_extensions',
 'nested_inline',
 'adminsortable',
 'isms.base',
 'isms.dms',
 'isms.drp',
 'isms.cile',
 'django_smoke_tests']
Installed Middleware:
['django.middleware.security.SecurityMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware']

Traceback:

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/core/handlers/exception.py"
 
in inner
  34. response = get_response(request)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/core/handlers/base.py" 
in _get_response
  126. response = self.process_exception_by_middleware(e, 
request)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/core/handlers/base.py" 
in _get_response
  124. response = wrapped_callback(request, *callback_args, 
**callback_kwargs)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py" 
in wrapper
  241. return self.admin_view(view, cacheable)(*args, 
**kwargs)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/utils/decorators.py" 
in _wrapped_view
  142. response = view_func(request, *args, **kwargs)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/views/decorators/cache.py"
 
in _wrapped_view_func
  44. response = view_func(request, *args, **kwargs)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py" 
in inner
  223. return view(request, *args, **kwargs)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/views/decorators/cache.py"
 
in _wrapped_view_func
  44. response = view_func(request, *args, **kwargs)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py" 
in index
  491. app_list = self.get_app_list(request)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py" 
in get_app_list
  474. app_dict = self._build_app_dict(request)

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py" 
in _build_app_dict
  459. current_app=self.name,

File "/home/vagrant/venv/lib/python3.7/site-packages/django/urls/base.py" 
in reverse
  90. return iri_to_uri(resolver._reverse_with_prefix(view, prefix, 
*args, **kwargs))

File 
"/home/vagrant/venv/lib/python3.7/site-packages/django/urls/resolvers.py" 
in _reverse_with_prefix
  623. raise NoReverseMatch(msg)

Exception Type: NoReverseMatch at /
Exception Value: Reverse for 'app_list' with keyword arguments 
'{'app_label': 'cile'}' not found. 1 pattern(s) tried: 
['(?Pauth|base|dms|drp)/$']







Dne čtvrtek 3. ledna 2019 17:03:26 UTC+1 Honza Král napsal(a):
>
>
>
>
>
> On Thu, Jan 3, 2019 at 4:57 PM MirekZv > 
> wrote:
>
>> Cil._meta.app_label == 'cile'
>>
>> pattern ... ale "cile" se do toho nevejdou --- no jo, ale proč tam chybí 
>> a jak je tam dostat? Laděním jsem neuspěl, stack je asi 20-vrstvý, jen 
>> internals djanga a samé magic dvojpodtržítkové metody; fakt to nedávám, 
>> přes veškerou snahu.
>>
>>
> musis zjistit, odkud se ten pattern bere a proc nefunguje. Ja bych si 
> tipoval, ze ten pattern je z adminu a tim padem bych podezrival, ze appka 
> cile neni spravne nakonfigurovana pro admin, ale to je jen strelba naslepo.
>
> Musis se podivat jak ta chyba vznika, pri jake operaci a pak zjistis kde 
> asi je ten problem - zacinas tady od konce, tedy jak se chyba projevuje, 
> ale nevime co tu chybu zpusobuje... Cely traceback by se hodil, nebo 
> alespon popis problemu
>  
>
>> PS: viz též další vlákno (nezaregistroval jsem včas Tvou reakci a chtěl 
>> jsem to ještě nějak povzbudit a nahlédnout z jiného konce)
>>
>>
>>
>> Dne čtvrtek 3. ledna 2019 16:46:45 UTC+1 Honza Král napsal(a):
>>>
>>>
>>>
>>> On Thu, Jan 3, 2019 at 4:39 PM MirekZv  wrote:
>>>
>>>> Ještě jednou moje otázky stručně:
>>>>
>>>
>>> diky za zestrucneni, predtim jsem tvuj email preskocil protoze jsem 
>&g

Re: [django-cs] Re: než se z toho Djanga zblázním: app_name, app_label, NoReverseMatch

[MirekZv]

ls/deprecation.py(91)__call__()
 
-> response = response or self.get_response(request) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/core/handlers/exception.py(34)inner()
 
-> response = get_response(request) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/core/handlers/base.py(124)_get_response()
 
-> response = wrapped_callback(request, *callback_args, **callback_kwargs) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py(241)wrapper()
 
-> return self.admin_view(view, cacheable)(*args, **kwargs) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/utils/decorators.py(142)_wrapped_view()
 
-> response = view_func(request, *args, **kwargs) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/views/decorators/cache.py(44)_wrapped_view_func()
 
-> response = view_func(request, *args, **kwargs) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py(223)inner()
 
-> return view(request, *args, **kwargs) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/views/decorators/cache.py(44)_wrapped_view_func()
 
-> response = view_func(request, *args, **kwargs) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py(491)index()
 
-> app_list = self.get_app_list(request) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py(474)get_app_list()
 
-> app_dict = self._build_app_dict(request) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py(441)_build_app_dict()
 
-> model_dict['admin_url'] = reverse('admin:%s_%s_changelist' % info, 
current_app=self.name) 
 
/home/vagrant/venv/lib/python3.7/site-packages/django/urls/base.py(90)reverse() 
-> return iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args, 
**kwargs)) 
> 
/home/vagrant/venv/lib/python3.7/site-packages/django/urls/resolvers.py(623)_reverse_with_prefix()
 
-> raise NoReverseMatch(msg)

(3) se liší jen na 3.položce odspoda číslem řádku (místo 441):
  
/home/vagrant/venv/lib/python3.7/site-packages/django/contrib/admin/sites.py(459)_build_app_dict()
-> current_app=self.name,



Dne čtvrtek 3. ledna 2019 17:03:26 UTC+1 Honza Král napsal(a):
>
>
>
>
>
> On Thu, Jan 3, 2019 at 4:57 PM MirekZv > 
> wrote:
>
>> Cil._meta.app_label == 'cile'
>>
>> pattern ... ale "cile" se do toho nevejdou --- no jo, ale proč tam chybí 
>> a jak je tam dostat? Laděním jsem neuspěl, stack je asi 20-vrstvý, jen 
>> internals djanga a samé magic dvojpodtržítkové metody; fakt to nedávám, 
>> přes veškerou snahu.
>>
>>
> musis zjistit, odkud se ten pattern bere a proc nefunguje. Ja bych si 
> tipoval, ze ten pattern je z adminu a tim padem bych podezrival, ze appka 
> cile neni spravne nakonfigurovana pro admin, ale to je jen strelba naslepo.
>
> Musis se podivat jak ta chyba vznika, pri jake operaci a pak zjistis kde 
> asi je ten problem - zacinas tady od konce, tedy jak se chyba projevuje, 
> ale nevime co tu chybu zpusobuje... Cely traceback by se hodil, nebo 
> alespon popis problemu
>  
>
>> PS: viz též další vlákno (nezaregistroval jsem včas Tvou reakci a chtěl 
>> jsem to ještě nějak povzbudit a nahlédnout z jiného konce)
>>
>>
>>
>> Dne čtvrtek 3. ledna 2019 16:46:45 UTC+1 Honza Král napsal(a):
>>>
>>>
>>>
>>> On Thu, Jan 3, 2019 at 4:39 PM MirekZv  wrote:
>>>
>>>> Ještě jednou moje otázky stručně:
>>>>
>>>
>>> diky za zestrucneni, predtim jsem tvuj email preskocil protoze jsem 
>>> nemel dosta casu na delsi email, tohle je lepsi!
>>>
>>>
>>>> 1. Když aplikace v INSTALLED_APPS je 'isms.cile', jak psát 2.param. 
>>>> include() a app_name=.. v urls.py? 'isms.cile' nebo 'cile'?
>>>>   Je to někde v dokumentaci?
>>>>
>>>
>>> cile by melo stacit. Idealne jak to zjistit je naimportovat si nejaky 
>>> model z te aplikace a podivat se na
>>>
>>> MujModel._meta.app_label
>>>
>>>
>>>> 2. Odkud je sestaven řetězec za "tried:" v chybové hlášce:
>>>>   NoReverseMatch at /
>>>>   Reverse for 'app_list' with keyword arguments '{'app_label': 'cile'}' 
>>>> not found. 1 pattern(s) tried: ['(?Pauth|base|dms|drp)/$']
>>>>
>>>
>>> to je z urlpatterns ktery mas nadefinovany. Pokusil se najit nejake url 
>>> kde je skupina app_label. Jediny pattern do ktery by to teoreticky mohlo 
>>> byt mas tady ukazany, ale "cile" se do toho nevejdou. Protoze v tom url 
>>> jsou vypocitane jen jine moznosti. 
>>>
>>>>
>>>> -- 
>>>> -- 
>>>> E-mailová skupina dj

[django-cs] než se z toho Djanga zblázním: urls.py (moje otázka potřetí jinak)

[MirekZv]

Py 3.7, Dj 2.1

Ještě jinak formulovaná moje otázka z předchozího vlákna:


Když mám jen hlavní urls.py a v něm:
urlpatterns += [
path('tree/', ViewTreeGoals.as_view(), name='tree-goals'),
]
 tak to funguje


Když to nahradím: re_path(r'^cile/', include('isms.cile.urls', 
'isms.cile')),# nebo 2.par 'cile'; 'isms.cile' je jméno aplikace
a přidám cile/urls.py:
from django.urls import path
from .views import ViewTreeGoals
app_name = 'isms.cile'# nebo 'cile'; 'isms.cile' je jméno aplikace
urlpatterns = [
path('tree/', ViewTreeGoals.as_view(), name='tree-goals'),
]
. tak to začne padat chybou: NoReverseMatch at /   Reverse 
for 'app_list' with keyword arguments '{'app_label': 'cile'}' not found. 1 
pattern(s) tried: ['(?Pauth|base|dms|drp)/$']


Co dělám špatně?

-- 
-- 
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/96a1c975-ee2e-4c75-91fa-3827117a34f1%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: než se z toho Djanga zblázním: app_name, app_label, NoReverseMatch

[MirekZv]

Ještě jednou moje otázky stručně:

1. Když aplikace v INSTALLED_APPS je 'isms.cile', jak psát 2.param. 
include() a app_name=.. v urls.py? 'isms.cile' nebo 'cile'?
  Je to někde v dokumentaci?

2. Odkud je sestaven řetězec za "tried:" v chybové hlášce:
  NoReverseMatch at /
  Reverse for 'app_list' with keyword arguments '{'app_label': 'cile'}' not 
found. 1 pattern(s) tried: ['(?Pauth|base|dms|drp)/$']

-- 
-- 
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/700c170f-61c5-4aec-adb5-ffcbc66448e8%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Django 2.1 - jak udělat přidané pole ve StackedInlinu hidden?

[MirekZv]

Django 2.1.

class AnswerInline(admin.StackedInline):
model = Answer
form = AnswerForm
fields = ("question_answer_type", "answer_plain")
readonly_fields = ("question_answer_type",)

def question_answer_type(self, row):
return row.question.answer_type


Tohle běhá a v inline instancích přibylo pole "question_answer_type".

Teď bych rád to pole udělal hidden. (Např. z něj chci něco řídit v 
JavaScriptu.)

Vím, že existuje forms.widgets.HiddenInput (nebo se má používat 
forms.HiddenInput?? - oba jsou stejné objekty).
Ale jak to použít?
Pravděpodobné se mi zdálo něco jako widgets = {'question_answer_type': 
forms.widgets.HiddenInput()}, bohužel to nefunguje (ze zoufalství jsem 
zkoušel do AnswerInline, AnswerForm, class Meta i mimo).

Ach, proč je to Django tak moc intuitivní?

-- 
-- 
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/b34addf5-22bf-45a5-9e7d-963bedbb0fe8%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Záhadná chyba při pip instalaci z githubu

[MirekZv]

Vypadá to, že to funguje, jak píšeš. Připsat packages.

A ještě jsem přišel na to, že i bez jakékoli úpravy setup.py můžu 
instalovat: pip install -e git+
a bude to tam taky (zkopírováno do src/ ve virtual environmentu).





Dne neděle 25. února 2018 19:47:31 UTC+1 Messa napsal(a):
>
> Tipuju,  že problém bude v setup.py:
>
> packages=['db_file_storage'],
>
> Subpackage db_file_storage.management bohužel takto nebude zahrnut. Musí 
> se to vyjmenovat vše;
>
> -packages=['db_file_storage'],
> +packages=['db_file_storage', 'db_file_storage.management'],
>
> Anebo použít find_packages, příklad: 
> https://github.com/pypa/sampleproject/blob/master/setup.py
>
> PM
>
> Dne 25. února 2018 15:40 MirekZv <mirek@gmail.com > 
> napsal(a):
>
>> Nenasměroval byste mě někdo, jakou dělám kravinu?
>>
>> Do github.com/zvolsky/db_file_storage
>> jsem dodělal db_file_storage/management/command/files2db.py
>> Je to ve větvi 'migrate', ale i zamergováno do 'master'.
>>
>> - Na githubu adresář management/ vidím. Hurá.
>>
>> - git clone https://github.com/zvolsky/db_file_storage adresář 
>> management/ taky vytvoří. Hurá.
>>
>> - pip install git+https://github.com/zvolsky/db_file_storage.git něco 
>> nainstaluje (těžko říct co) a adresář management/ chybí :((
>>
>> Možná to dělá url=.. nebo download_url=.. v setup.py. Je potřeba něco z 
>> toho vyhodit? Přepsat?
>>
>> -- 
>> -- 
>> 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/daabbd05-8e70-463d-a7a9-c2e01b7afa99%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/daabbd05-8e70-463d-a7a9-c2e01b7afa99%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> Další možnosti najdete na https://groups.google.com/d/optout.
>>
>
>

-- 
-- 
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/7a932b71-f43b-4cd9-a629-55b0e3eaaa08%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: apache - python

[MirekZv]

Jardo, používání toho serveru má pro Tebe nějaké administrativní / 
institucionální / organizační důvody?

Co použít něco jiného? Konkrétně třeba Forpsi virtuál server za 370 Kč 
ročně, kam si dáš Debian+Nginx+.. Běhá to výborně (např. zřejmě mnohem líp 
než 4x tak drahý Wedos). Brzdou je leda jen 20G SSD disku.






Dne úterý 23. ledna 2018 9:33:43 UTC+1 Jaroslav Vysoký napsal(a):
>
> Ahoj všichni! 
>
> Momentálně jsem nucen pracovat na tomto serveru: 
> http://kraken.pedf.cuni.cz
>
> Vzhledem k tomu, že Python je pedf.cuni.cz popelkou, tak je pro mě 
> pozitivním faktem, že se vůbec někdo zabýval možností spuštění pythoní 
> webové aplikace na tomto serveru. Návod je tady: 
> http://kraken.pedf.cuni.cz/python/kotekl/hlavni
> (ve skutečnosti tam běží Python 3.5)
>
> Já té vazbě python aplikace - wsgi - web server moc nerozumím. Používám to 
> na pythonanywhere.com dle instrukcí zde uvedených, a všechno funguje, jak 
> má. 
>
> Tady to vypadá, že to řešení asi není úplně up-to-date, ale hlavně mi zde 
> chybí možnost provést reload aplikace (jako na pythonanywhere), takže mi tu 
> zůstávají různá rezidua dříve spuštěných aplikací. 
>
> Dokáže mi někdo poradit, zda existuje možnost, jak bych uživatelsky 
> zajistil reload aplikace? Nebo je třeba přinutit administrátory, aby dodali 
> nějakou takovou možnost? Nebo je třeba tlačit administrátory k nějaké 
> zásadnější změně? Jak by mělo vypadat "správné" řešení? 
>
> Díky předem i zadem za rady! 
>
> Jarda 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/615eb971-5d80-42bd-866b-a66a6f2404d1%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: apache - python

[MirekZv]

Vám závidím, že o tom tolik víte. To bych chtěl taky pochopit.

@Messa: Zdá se mi úplně zásadní to Tvoje "tvým úkolem je dodat Python 
funkci" - s tím se musím pořádně sžít, jinak asi wsgi nepochopím.

@Stařenka: Jo, ten normální stack, ideálně s nginxem. Nechtěl bys to někdy 
vysvětlit u piva?






Dne úterý 23. ledna 2018 9:33:43 UTC+1 Jaroslav Vysoký napsal(a):
>
> Ahoj všichni! 
>
> Momentálně jsem nucen pracovat na tomto serveru: 
> http://kraken.pedf.cuni.cz
>
> Vzhledem k tomu, že Python je pedf.cuni.cz popelkou, tak je pro mě 
> pozitivním faktem, že se vůbec někdo zabýval možností spuštění pythoní 
> webové aplikace na tomto serveru. Návod je tady: 
> http://kraken.pedf.cuni.cz/python/kotekl/hlavni
> (ve skutečnosti tam běží Python 3.5)
>
> Já té vazbě python aplikace - wsgi - web server moc nerozumím. Používám to 
> na pythonanywhere.com dle instrukcí zde uvedených, a všechno funguje, jak 
> má. 
>
> Tady to vypadá, že to řešení asi není úplně up-to-date, ale hlavně mi zde 
> chybí možnost provést reload aplikace (jako na pythonanywhere), takže mi tu 
> zůstávají různá rezidua dříve spuštěných aplikací. 
>
> Dokáže mi někdo poradit, zda existuje možnost, jak bych uživatelsky 
> zajistil reload aplikace? Nebo je třeba přinutit administrátory, aby dodali 
> nějakou takovou možnost? Nebo je třeba tlačit administrátory k nějaké 
> zásadnější změně? Jak by mělo vypadat "správné" řešení? 
>
> Díky předem i zadem za rady! 
>
> Jarda 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/b6bf549b-ccf9-43b9-bc2f-a06ad3543015%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: vícejazyčná aplikace se zdrojáky v češtině

[MirekZv]

>> Stařenka
Dík za názory.
Jasně, to jsem nějak neuvažoval a je to vlastně docela možné řešení, nechat 
ve zdrojákách prasáckou angličtinu a nechat překladatele, aby to udělal v 
poeditu pořádně.

>> Ing.Vladimír
Problém je, že to sice funguje, ale
- češtinu nemůžu nechat prázdnou, musím identické texty zkopírovat, jinak 
se mi místo nepřeloženého nacpe angličtina
- v poeditu se mi hlášky namíchají, takže se hodně blbě hledají ty texty, 
které je ještě potřeba přeložit -- tenhle problém možná myslel Stařenka, 
když psal o zachování duševního zdraví

-- 
-- 
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/ce68a3e5-d905-4dc8-856d-ed9d6e26d3ab%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: ověření dat - combobox

[MirekZv]

Tak co, jak jsi pokročil?
Nikdo nic neříká, a já Ti taky neporadím, protože jsem taky začátečník.
Možná by bylo dobře, abys nějak líp popsal ten problém nebo abys nějak 
začal to řešit a zeptal se už na něčem konkrétnějším.

Já jenom tuším, že
- jestli ten combobox má vybírat záznamy z druhé tabulky, neboli jestliže 
bude odpovídat ForeignKey v modelu,
tak v admin/ ti to bude fungovat samo od sebe, když v modelu u té druhé 
tabulky budeš mít def __str__() [případně def __unicode__ u py27]

Pak ještě tuším, že to je dáno tím, že je použitý default datový manager 
(tj. .objects).
Takže si myslím, že za tohohle předpokladu by to mělo fungovat i ve 
formulářích mimo admin/ (ale nevím, jestli je k tomu ještě něco potřeba 
zajistit)

Ale jak říkám 1) moje představy jsou víc než laické, 2) ze tvého dotazu 
není jasné, co přesně chceš.


Dne čtvrtek 4. ledna 2018 19:56:30 UTC+1 Jan Sekula napsal(a):
>
> Zdravím, 
> jsem nový samouk a potřeboval bych poradit.
> Chci ve svojí aplikaci použít combobox,
> který by čerpal data z databáze (Sqlite).
> Nemám ani model...
>
> Děkuju
>
>

-- 
-- 
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/e4409577-00a7-4b11-9751-6c46f63efa50%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: Jak se zorientovat v ManyToMany

[MirekZv]

Trochu shrnu, co jsem se dověděl.

Asi by pro začátečníka bylo dobré, kdyby trochu znal historii Djanga, která 
předpokládám byla asi takováto (?):

1. Nejdřív se zavedly ForeignKey a nic víc - pro m2m z toho vyplývalo 
obvyklé řešení s vazební tabulkou.

2. Pak někoho napadlo, že když ve vazební tabulce není nic, než 2 cizí 
klíče, tak ManyToManyField by byla hezká zkratka,
včetně toho řešení s definováním na jedné straně (což je zajímavá a asi 
bezva věc - jak píše Hynek).
Udělala se pro to i podpora do základního admin formuláře, ale jen na té 
jedné straně, kde se to definuje.

3. Pak někoho napadlo, že často v té vazební tabulce bude sloupců víc (než 
jen 2 cizí klíče) a udělalo se (s předchozím nepříliš kompatibilní) řešení 
s through=..
Od podpory v základním admin formuláři se upustilo.

Někde časově mezitím vznikly Inliny, což je jistě bezva věc, pro tento účel.

Teď by se asi dalo filozofovat, co dál, nabízejí se dvě věci:
- buď to nechat jak to je, a nechat lidi, ať si nad to dopíšou, co chtějí;
- nebo přikročit k:
4. Prohlásit řešení bez through= za obsolete, zlikvidovat ho v budoucích 
verzích Djanga.
Bylo by to asi trochu bolestné, nicméně veškerá další řešení, která by se 
nad tím dělala (v jednotlivých aplikacích i v nadstavbových balících) by 
byla jednotně koncipovaná.

 zatím všem vřelé díky 

-- 
-- 
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/ee405a62-9199-48c4-989c-6b8e4ce6e627%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Re: Jak se zorientovat v ManyToMany

[MirekZv]

>> a jak by měl ten Select s trough fungovat?

Ahoj Honzo,
Možností, jak vymyslet design/ovládání je jistě mraky, ale když už se 
takhle ptáš, tak jedna odpověď se přímo nabízí:

Měl by fungovat úplně přesně stejně jako TabularInline, akorát by měl být 
jako fieldset zamíchatelný kamkoli mezi fieldy/fieldsety té základní 
tabulky.





Dne čtvrtek 21. prosince 2017 11:09:51 UTC+1 Jan Bednařík napsal(a):
>
> Ahoj,
>
> a jak by měl ten Select s trough fungovat? V tom trough modelu může být 
> libovolné množství fieldů, které v selectu nemáš jak vyplnit. Pokud 
> potřebuješ trough model s fieldy navíc, tak to musíš hold plnit v adminu 
> toho trough modelu.
>
> Honza
>
>
>
> 2017-12-20 18:28 GMT+01:00 MirekZv <mirek@gmail.com >:
>
>> Díky moc za informace.
>> No, nepůjde mi to tak rychle, jak jsem si myslel.
>> V ORM API (nebo jak mám ten jazyk nazývat?) je to asi fakt symetrické, a 
>> slouží to (jestli jsem vás dobře pochopil) jako zkratka, aby nebylo potřeba 
>> zařazovat (v reálu ovšem vždy existující) vazební tabulku.
>> Bezva.
>>
>> Ale v adminu mi to moc symetrické nepřijde a ani podobné jedno druhému.
>>
>> Bez through=.. se zobrazí Select prvek, ale jen na jedné straně vazby, na 
>> té, kde je definováno ManyToManyField (našel jsem nějaký 5 let starý 
>> článek, jak ho přidat i na druhou stranu, a po nějakém úsilí ho doplnil pro 
>> py36/dj20 a zobecnil).
>>
>> S through=.. se mi Select nezobrazí vůbec, a při pokusu ho přidat pomocí 
>> explicitního seznamu fields=[.., ..] řve System Check, že to nelze.
>> Tak nevím, jestli je to vůbec přidatelné, nebo to vůbec nelze udělat. 
>> Pokud to přijatelné je, tak asi přidáním extra datových managerů k modelům 
>> na první i druhé straně (?).
>>
>> No, upřímně, čekal jsem, že to nebude taková dřina, a že v roce 2018 je 
>> to už trochu dále.
>> Když třeba budu mít knihu, je schéma (více autorů : více knih) úplně 
>> jasná věc, a zároveň je autor (resp. autoři) hlavním údajem knihy. Takže 
>> pod autorem mohu uživatelovi promítnout knihy v Inlinu, ale pod knihou 
>> promítat autory v Inlinu (a ne v Selectu na hlavní záložce) je prostě 
>> šílené.
>> Tak až zas zbyde nějaký čas, budu se dál snažit...
>>
>>
>>
>>
>> Dne středa 13. prosince 2017 11:31:23 UTC+1 MirekZv napsal(a):
>>>
>>> Nemohl byste mě někdo navést?
>>> Na všechno o Djangu jsou milióny textů, ale zrovna o tomhle toho je 
>>> minimum a nemůžu najít nic dobrého.
>>>
>>> Napřed jsem ani nevěděl, že je nějaká extra podpora (kromě Inlinů v 
>>> Adminu) a myslel jsem, že prostě do modelu přidám vazební tabulku 
>>> (minimalisticky se 2 cizími klíči).
>>>
>>> Pak jsem zjistil, že existuje v modelu ManyToManyField a sice ve 2 
>>> vzájemně nekompatibilních verzích:
>>> bez through=...
>>> s through=... (ten mi v Adminu negeneruje widget; dělám něco blbě nebo 
>>> to tak má být?)
>>>
>>> Obě pracují s vazební tabulkou, jen ve druhém případě k ní dělám model 
>>> vazební tabulky ručně.
>>> A jak se tedy varianta s through= liší od toho, když udělám jen tu 
>>> vazební tabulku a pole ManyToManyField nepoužiju?
>>>
>>> Mate mě taky to, že m:m relace není nahlížena symetricky, ale že si mám 
>>> vybrat jen jednu z těch dvou tabulek a do ní ManyToManyField přidat.
>>> API pro výběr je (prý) sice stejné, ale v té druhé tabulce nebudu mít 
>>> příslušný widget.
>>>
>>> Otázka tedy je:
>>> Kterou variantu si mám vybrat a proč?
>>>
>>> Nejde mi o jednoduchý příklad HlavniTabulka>=>> hodí ta easy varianta bez through,
>>> ale o složitější datová schémata s možností dlouhodobé udržitelnosti a 
>>> rozvoje (zesložitění schématu).
>>>
>>> Díky za případné nasměrování 
>>>
>>> -- 
>> -- 
>> 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/a766353f-ccf5-4177-aebc-eaef82d3812d%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/a766353f-ccf5-4177-aebc-eaef82d3812d%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> Další možnosti najdete na https://groups.google.com/d/optout.
>>
>
>

-- 
-- 
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/57d7b498-af85-4008-9e83-8b0856cefd87%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: České znaky Debian (Ubuntu?)

[MirekZv]

Díky všem.

Už znám důvod.
Instaloval jsem Deb9 z neoficiální repository s firmware. (což je s ohledem 
na následující blbost a je potřeba používat netinst.)

Neoficiální repository s firmware instaluje taky nepotřebné jazykové 
podpory včetně japanese keyboard, včetně package uim (input methods editor).

A v uim je bug, který rozbije czech/slovak/+? klávesnice v gnome aplikacích 
a v java aplikacích.




Dne úterý 10. října 2017 14:55:03 UTC+2 MirekZv napsal(a):
>
> Moc se omlouvám za věc nesouvisející s Djangem.
> Nerad bych kvůli hlouposti couval od čerstvě nainstalovaného Debianu 9 - 
> nevěděl byste někdo?
>
> České znaky v terminálu mi to píše perfektně.
> ˇCeské znaky háček+něco v grafické aplikaci (KDE) mi to píše takto debilně 
> (viz 1.znak) - rozložené na 2 znaky.
>
> Netušíte, kam sáhnout do nastavení?
> Nebo něco doinstalovat? Je to z netinst, dost "stručná" instalace.
>
>

-- 
-- 
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/dd065bab-f504-47a0-9118-34fc8828d84f%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] České znaky Debian (Ubuntu?)

[MirekZv]

dpkg-reconfigure locales -- jsem už zkoušel a nepomáhá.



Dne úterý 10. října 2017 18:29:59 UTC+2 Messa napsal(a):
>
> S tímhle jsem se v Debianu teda nikdy nesetkal :) 
>
> Co máš v env proměnných? Zkus sudo dpkg-reconfigure locales.
>
> PM
>
> Dne 10. října 2017 14:55 MirekZv <mirek@gmail.com > 
> napsal(a):
>
>> Moc se omlouvám za věc nesouvisející s Djangem.
>> Nerad bych kvůli hlouposti couval od čerstvě nainstalovaného Debianu 9 - 
>> nevěděl byste někdo?
>>
>> České znaky v terminálu mi to píše perfektně.
>> ˇCeské znaky háček+něco v grafické aplikaci (KDE) mi to píše takto 
>> debilně (viz 1.znak) - rozložené na 2 znaky.
>>
>> Netušíte, kam sáhnout do nastavení?
>> Nebo něco doinstalovat? Je to z netinst, dost "stručná" instalace.
>>
>> -- 
>> -- 
>> 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/fea2762d-4b13-4d18-88e1-f87c8180e470%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-cs/fea2762d-4b13-4d18-88e1-f87c8180e470%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> Další možnosti najdete na https://groups.google.com/d/optout.
>>
>
>

-- 
-- 
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/6728fe44-486a-4918-bc64-11e7d8a8f164%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Re: České znaky Debian (Ubuntu?)

[MirekZv]

Ještě jsem nenapsal, že jde o GTK/Gnome aplikace (Chrome, Leafpad,..). V 
QT/KDE je to taky ok.



Dne úterý 10. října 2017 14:55:03 UTC+2 MirekZv napsal(a):
>
> Moc se omlouvám za věc nesouvisející s Djangem.
> Nerad bych kvůli hlouposti couval od čerstvě nainstalovaného Debianu 9 - 
> nevěděl byste někdo?
>
> České znaky v terminálu mi to píše perfektně.
> ˇCeské znaky háček+něco v grafické aplikaci (KDE) mi to píše takto debilně 
> (viz 1.znak) - rozložené na 2 znaky.
>
> Netušíte, kam sáhnout do nastavení?
> Nebo něco doinstalovat? Je to z netinst, dost "stručná" instalace.
>
>

-- 
-- 
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/a421de23-69bb-49fd-95b9-3a7bc378f578%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] České znaky Debian (Ubuntu?)

[MirekZv]

Moc se omlouvám za věc nesouvisející s Djangem.
Nerad bych kvůli hlouposti couval od čerstvě nainstalovaného Debianu 9 - 
nevěděl byste někdo?

České znaky v terminálu mi to píše perfektně.
ˇCeské znaky háček+něco v grafické aplikaci (KDE) mi to píše takto debilně 
(viz 1.znak) - rozložené na 2 znaky.

Netušíte, kam sáhnout do nastavení?
Nebo něco doinstalovat? Je to z netinst, dost "stručná" instalace.

-- 
-- 
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/fea2762d-4b13-4d18-88e1-f87c8180e470%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.