Re: [django-cs] amqp

[Petr Messner]

Ahoj,

pá 12. 2. 2021 v 0:38 odesílatel Vladimír Macek  napsal:

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

Pokud to bude mít ne moc velký traffic, nemohl by ten někdo spíš
nakonfigurovat webhook? To by pro vás hádám mohlo být pohodlnější.


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

Nějakou amqp knihovnu :) Asi jich je víc a v různém stadiu rozkladu, tahle
vypadá fajn: https://github.com/pika/pika

Myslím, že amqp počítá s tím, že u vás bude běžet něco permanentně a číst
zprávy, protože IMHO obvykle se tyhle věci používají právě kvůli nízké
latenci :) Ale spustit jednou za 10 minut něco, co se připojí a spořádá
všechny nahromaděné zprávy, by asi mělo být ok. Ale ujistěte se, že tam
nění nějaká expirace/TTL kratší než 10 minut.

Petr M.



> Diky,
>
> V.
>
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> django-cs ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li zobrazit tuto diskusi na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/3c047e1d-01b6-0992-5ac6-037a02fe5f9b%40sandbox.cz
> .
>

-- 
-- 
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/CAK9Q5BRn3RyUXoNFp3qFwja%2Bj3pmz-gz1h-%2BYE9kBLRAB294VA%40mail.gmail.com.

Re: [django-cs] emmett

[Honza Javorek]

Ahoj,

zkoušel jsi Pyramid? Já ne, ale přišlo mi to možná nejblíž tomu, co hledáš.
Myslím si, že Django je skvělá výchozí volba pro web a když máš důvod
potřebovat něco speciálního, už nyní existuje spousta jiných frameworků:
https://docs.python-guide.org/scenarios/web/#frameworks A to tam ani není
všechno kolem těch "nových" asynchronních přístupů, aiohttp, Sanic, atd.

Jestli má existovat více těch výchozích voleb, to nevím. Přijde mi fajn, že
nevymýšlíme stále znova kolo a komunita se soustředí kolem Djanga, doplňky
jsou django-něco a kdyby frameworky soupeřily, přišlo by mi to asi jako
škoda lidského potenciálu. Možná je to na úkor nějaké inovace, ale proč
inovovat za každou cenu, když problém "webový framework" je už roky
vyřešená věc? Jen kvůli tomu, že člověk X by preferoval nějaký přístup a
člověk Y by si to chtěl psát zase trošku jinak? To mi přijde jako slabý
důvod.

V Ruby máš hromadu let stejnou situaci, vládne tam RoR. V JavaScriptu se po
vynálezu Node.js vyrojily desítky frameworků (nutno podotknout, že ne
webových serverových, tam to táhl Express, ale spíš frontendových
renderovacích). Každý se tomu smál, ale když opadla ta inovační fáze,
ustálilo se to na Reac/Vue a tak je to roky. Dnes se to propojuje s
backendem a máš Next/Nuxt, kolem kterých se soustředí čím dál více lidí.
Není to hegemonie jednoho, ale dvou. Stále je to však hegemonie. JS
komunita je silná a velká, tak má energii udržovat dvě paralelní linie. V
Ruby nebo Pythonu lidé soustředí své síly do jednoho projektu.

Toť mých 50 haléřů.

Honza

On Thu, Feb 11, 2021 at 10:49 AM MirekZv  wrote:

> Do písmene souhlasím s tím, co autor píše ve Foreword.
>
> Byl by ovšem zázrak, kdyby se povedlo vytvořit fullstack framework
> konkurenční ke Djangu.
>
> Na druhou stranu něco jednou přijít musí. Protože jestli bude jediná volba
> Django, ohrožuje to podle mě samu podstatu volby Pythonu jako jazyka pro
> webové aplikace (ano, uznávám, trochu ze mě mluví včerejší frustrace (jejíž
> součástí je i jiný dotaz zde v diskuzi), která není každodenní).
>
>
> Foreword:
>
> 
>
> I really enjoyed writing code in Python, and after gaining some
> confidence, I faced the second "big decision": which framework to use to
> write my applications Looking at the Python scene, I (obviously) started
> looking at *django*, the most famous one, but after a while I found I
> didn't like it. It wasn't as user friendly as I had hoped. Then I found
> *web2py*, and I loved it from the first line of the documentation book:
> it was simple, full of features, and learning it was much quicker than
> *django*.
>
> Nevertheless, after some years of using *web2py*, inspecting deeply the
> code and logic, and contributing it, I started having a feeling. A need
> grew in my mind while writing applications, to write things differently. I
> found myself thinking "Why should I write this stuff in *this* way? It's
> not cool or handy at all," and I had to face the problem that doing what I
> wanted would involve completely re-designing the whole framework.
>
> With this nagging feeling in my mind, I started looking around and found
> that a lot of the syntax and logic in *Flask* were the answer to what I
> was looking for.
> Unfortunately, at the same time, *Flask* had a lacked many of the
> features I was used to having out of the box with *web2py*, and not even
> using extensions would have been enough to cover it all.
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/837e5398-60e1-4115-b0f8-800b2968dcdbn%40googlegroups.com
> 
> .
>

-- 
-- 
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/CAPAmg-cYszXwGP3Kw9zy9nU8oYFBtfnijgQOv2EGzYSOTNpV5A%40mail.gmail.com.

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

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.
>
> 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/07164ee

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.

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

[Pavel Cisar]

Ahoj,
nemuzu si pomoct, ale pripada mi, ze jde spis o nepochopeni podstaty django
admina. Je to skvely nastroj pro nahlizeni do struktury dat a dava moznost
urcitych modifikaci, ale primarne pro vnitrni potrebu.
V dokumentaci v podstate pisou, ze pokud chce clovek neco vic a nevejde se
danych mantinelu, je nacase si napsat vlastni interface a s tim musim
rozhodne souhlasit.
Pokud clovek vyslovene nechce psat neco vlastniho a rad by zmenit vzhled
nebo mel vice moznosti, tak bych ho odkazal na projekty jako:
https://github.com/django-admin-tools/django-admin-tools
https://djangosuit.com/



pá 12. 2. 2021 v 16:42 odesílatel MirekZv  napsal:

> Honza zatím mlčí, odpovím si sám.
> Samozřejmě, že admin/app_list.html se volá na 2 místech.
> Jedno místo popisuje Honza - to je "vhodné k přetěžování".
> Podruhé v nav_sidebar.html, tam opět žádný blok není, neboli další
> šablona, která "není určena k přetěžování".
> Ostatně, kdykoli když slyším slovo "přetěžování", tak už je mi jasné, že
> je něco špatně.
> Takže závěr: Django je jako vždy geniální, já jsem zase ten blbec, co ho
> chce použít k něčemu, k čemu není určeno.
> (sorry za tu mírnou jedovatost, já to tak nemyslím, jen toho mám trochu
> plné zuby)
> Dne středa 10. února 2021 v 18:45:24 UTC+1 uživatel MirekZv napsal:
>
>> PS:
>> Potíž je, že tím předchozím postupem nejen nelze i18n/trans, ale nelze
>> ani vsadit do html jakýkoli string, který bych si připravil předem.
>> Leda můžu v template/base.py místo `raise self.error(token, '%r must be
>> the first tag in the template.' % node,)` dát `pass`,
>> aby Django neprovádělo své přechytralé kontraproduktivní kontroly.
>> Jenže to už je zase patchování Djanga.
>> Ach jo, zlatej Cheetah.
>>
>> Dne středa 10. února 2021 v 18:15:18 UTC+1 uživatel MirekZv napsal:
>>
>>> Mezitím mám jedno řešení.
>>> Dokumentace Djanga je "doslovně" pravdivá: If you use {% extends %} in a
>>> template, it must be the first template tag in that template.
>>> To skutečně znamená, že extends může předcházet (nikoli následovat) html
>>> kód.
>>> To by mi celkem vyhovovalo. Jediné, co mě štve je, že nemůžu použít
>>> nejen {% include ... %}, ale ani i18n/trans :(
>>> Příklad viz obrázky.[image: rap1.png][image: rap2.png]
>>>
>>> Dne středa 10. února 2021 v 18:10:44 UTC+1 uživatel MirekZv napsal:
>>>
 Možná jsem Tě přesně nepochopil.
 Já umím extendovat admin/app_list.html, jenže je mi to k..h..u, protože
 ta v sobě nemá žádný {% block  %} - takže proč ji extendovat?
 Ale možná jsi myslel includovat. To by dávalo smysl.

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



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

> app_list.html neni urcena k pretezovani, proto na to neni zarizena.
> Nejjednodussi cesta je:
>
> nastav si custom sablonu na index_template (0). Ve sablone (ktera se
> nebude jmenovat admin/index.html) extenduj index.html a prepis {% block
> content %} kde misto admin/app_list.html naimportujes jinou sablonu, ktera
> byde extendovat admin/app_list.html
>
>
> 0 -
> https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite.index_template
>
> Honza Král
> E-Mail: honza...@gmail.com
> Phone:  +420 606 678585 <+420%20606%20678%20585>
>
>
> On Wed, Feb 10, 2021 at 5:22 PM MirekZv  wrote:
>
>> 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 te

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

[Jan Bednařík]

Ahoj,

s těmi mantinely se to má tak, že tam kde člověk narazí na limity rozumné
customizace adminu, tak snadno přihodí vlastní view, template, formuláře,
atp. A ten vlastní interface si dopíše do adminu. Což dává smysl, pokud se
aspoň kus či většina adminu využije.

Na customizaci vzhledu se mi osvědčil
https://github.com/fabiocaccamo/django-admin-interface který nedělá moc
velkou magii a spíš to přestyluje jen barevně.

Honza

pá 12. 2. 2021 v 21:52 odesílatel Pavel Cisar  napsal:

> Ahoj,
> nemuzu si pomoct, ale pripada mi, ze jde spis o nepochopeni podstaty
> django admina. Je to skvely nastroj pro nahlizeni do struktury dat a dava
> moznost urcitych modifikaci, ale primarne pro vnitrni potrebu.
> V dokumentaci v podstate pisou, ze pokud chce clovek neco vic a nevejde se
> danych mantinelu, je nacase si napsat vlastni interface a s tim musim
> rozhodne souhlasit.
> Pokud clovek vyslovene nechce psat neco vlastniho a rad by zmenit vzhled
> nebo mel vice moznosti, tak bych ho odkazal na projekty jako:
> https://github.com/django-admin-tools/django-admin-tools
> https://djangosuit.com/
>
>
>
> pá 12. 2. 2021 v 16:42 odesílatel MirekZv 
> napsal:
>
>> Honza zatím mlčí, odpovím si sám.
>> Samozřejmě, že admin/app_list.html se volá na 2 místech.
>> Jedno místo popisuje Honza - to je "vhodné k přetěžování".
>> Podruhé v nav_sidebar.html, tam opět žádný blok není, neboli další
>> šablona, která "není určena k přetěžování".
>> Ostatně, kdykoli když slyším slovo "přetěžování", tak už je mi jasné, že
>> je něco špatně.
>> Takže závěr: Django je jako vždy geniální, já jsem zase ten blbec, co ho
>> chce použít k něčemu, k čemu není určeno.
>> (sorry za tu mírnou jedovatost, já to tak nemyslím, jen toho mám trochu
>> plné zuby)
>> Dne středa 10. února 2021 v 18:45:24 UTC+1 uživatel MirekZv napsal:
>>
>>> PS:
>>> Potíž je, že tím předchozím postupem nejen nelze i18n/trans, ale nelze
>>> ani vsadit do html jakýkoli string, který bych si připravil předem.
>>> Leda můžu v template/base.py místo `raise self.error(token, '%r must be
>>> the first tag in the template.' % node,)` dát `pass`,
>>> aby Django neprovádělo své přechytralé kontraproduktivní kontroly.
>>> Jenže to už je zase patchování Djanga.
>>> Ach jo, zlatej Cheetah.
>>>
>>> Dne středa 10. února 2021 v 18:15:18 UTC+1 uživatel MirekZv napsal:
>>>
 Mezitím mám jedno řešení.
 Dokumentace Djanga je "doslovně" pravdivá: If you use {% extends %} in
 a template, it must be the first template tag in that template.
 To skutečně znamená, že extends může předcházet (nikoli následovat)
 html kód.
 To by mi celkem vyhovovalo. Jediné, co mě štve je, že nemůžu použít
 nejen {% include ... %}, ale ani i18n/trans :(
 Příklad viz obrázky.[image: rap1.png][image: rap2.png]

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

> Možná jsem Tě přesně nepochopil.
> Já umím extendovat admin/app_list.html, jenže je mi to k..h..u,
> protože ta v sobě nemá žádný {% block  %} - takže proč ji extendovat?
> Ale možná jsi myslel includovat. To by dávalo smysl.
>
> A pak taky nevím, jestli to, co píšeš, řeší, aby moje přidané položky
> byly všude: 1) Na hlavní stránce admina, 2) Na stránkách aplikací, 3) V
> sidebar menu během editace.
>
>
>
> Dne středa 10. února 2021 v 17:29:32 UTC+1 uživatel honza...@gmail.com
> napsal:
>
>> app_list.html neni urcena k pretezovani, proto na to neni zarizena.
>> Nejjednodussi cesta je:
>>
>> nastav si custom sablonu na index_template (0). Ve sablone (ktera se
>> nebude jmenovat admin/index.html) extenduj index.html a prepis {% block
>> content %} kde misto admin/app_list.html naimportujes jinou sablonu, 
>> ktera
>> byde extendovat admin/app_list.html
>>
>>
>> 0 -
>> https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite.index_template
>>
>> Honza Král
>> E-Mail: honza...@gmail.com
>> 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/a