Jak poznat, co vic zatezuje Joomlu?

Ahoj, spíš záleží na tom jak je to napsaný.

Jinak:

- modul se načte pouze, když se zobrazí
- content plugin se načte pouze v článku, který se zobrazuje
- system plugin pracuje neustále.

Řekl bych že, content plugin (tedy článkový plugin), který se načte pouze, když se zobrazí článek (nebo je ten článek v nějakým blogu) bude asi nejšetrnější (za předpokladu, že modul i plugin obsahují stejný kód)

Ale pokud se modul načte např. na jedné stránce pak je to v podstatě jedno - jestli modul nebo plugin pouze na jedné stránce.

Modul se vykreslí jen na těch stránkách na kterých je aktivovaný, tj. když bude přiřazen jedné jediné stránce (resp. položce menu), vykreslí se jen tam.

Tady jse spíš o to podívat se do debugu (zapnout debug informace), kolik se při načtení zabere paměti a jak dlouho se script vytvářel (je nutný to vyzkoušet víckrát, protože čas se může měnit podle různých podmínek)

Druhá věc je, co se tvoří v prohlížeči u uživatele a co se provádí na serveru.

Např. s tím flashem, pokud není zase tak velký, tak pro server to zátěž neznamená: Server jen nahraje (poskytne) ten flash soubor a k němu nějaké propojení (link na soubor, pár řádků javascriptu pro rozjetí flashe) a vše ostatní se už děje v uživatelově prohlížeči.

Tedy kolikrát je těžký určit, jak moc je co náročný, protože např. složitá věc může např. všechno tahat z externích serverů (např. jquery z jiného serveru, další script z jiného serveru) a pak v podstatě dochází k minimální zátěži serveru.

Ahoj, no právě, pocitově - záleží na tom, jak rychle se např. zpracuje javascript a flash v uživatelově prohlížeči, to v podstatě nemá s tvým serverem co společnýho.

Jde o to jakej je cíl:

a) snížit zátěž serveru - pak přes debug mode - jednou nahrát ten script v pluginu - zjistit údaje o MB a čase a pak ho nahrát z modulu a porovnat to (vícektrát) - to se bavíme jen o zátěži serveru - vlastně jen o tom, kolik toho musí poslat. Např. když se pár věcí tahá z externího sereru, někdo to může být rychlejší, někdy pomalejší ale pro server je to úleva. Příklad s fonty: tahat fonty z google font directory může významně šetřit server - otázka je, jestli to je rychlejší nebo ne - záleží, kterej server v daný chvíli bude rychlejší

b) co nejrychleji uživatelovi nahrát kompletní script - pak opravdu záleží na testech v prohlížeči, ale to už je v podstatě hodně těžko měřitelný (připojení k internetu, server, externí server, nějaká chyba na cestě, prohlížeč, výkon PC (např. pro běh javascriptu nebo flashe), program pro běh flashe, atd. atd.)

Pokud a) pak debug mode prostě řekne: v tomhle případě jsem musel poslat tolik a tolik MB a stálo mě to tolik a tolik času a v druhým případě to bylo o nějakej ten KB míň a časově o pár setin míň. Atd.

Nemyslím že si odporujeme

Modul se vykresluje pouze tehdy, je-li aktivní pro právě zobrazenou položku menu. Druhá věc je, jestli se pak vykreslí nebo ne. Může mít v sobě nějakou další zabudovanou logiku, která jeho obsah vykreslí v závislosti na právě zobrazeném obsahu (typicky např. související články, články z kategorie v dynamickém módu, nebo vlastně i modul nabídky).

Oproti tomu Content plugin dostane vždy a pro každý článek jeho obsah, a má možnost tento obsah upravit. Pokud jej upraví a jak, je už v jeho pravomoci.

Myslím že tedy hlavně záleží na tom, kde chcete příslušný obsah zobrazit.

Já bych se spíše ale klonil k modulu, protože Content plugin vždy bude muset dělat navíc nějakou kontrolu, zda obsah upravit nebo ne. Navíc pro stránky typu blog se Content plugin spustí tolikrát, kolik je na stránce článků, popř. i modulů se zapnutou možností Připravit obsah. Ano v něm být nějaká triviální kontrola, zda obsah upravovat nebo ne (podle kontextu nebo rychlým hledáním tagu v obsahu), ale vždy je to o trochu "zátěžovější" než modul (i když minimální).

Vyjímkou by pak mohl být např. plugin čerpající informace z právě zobrazeného článku - tam by modul musel provádět další akce a dotazy do databáze aby měl stejné informace jako plugin - v takovém případě by plugin byl asi vhodnější.

No tak nějak, modul spouští šablona (ve vzácných případech, jako je např. loadmodule plugin se spustí i jinak, ale to bych do toho nemotal). Šablona se mrkne na konkrétní pozici a vybere si moduly, podle jejich nastavení, které by se měly zobrazit. Pak je jeden po druhém zavolá.

Modul se pak sám rozhodne, jestli něco vykreslí, přidá nějaké CSS nebo JavaScript a apod. Zde už záleží na tom jak je modul napsán, ale první omezení lze zaručit již v Joomle, tím že se nastaví pro vykreslení jen někde.

Content plugin oproti tomu spouští komponenty (tedy většinou ). Např. komponenta pro články, při zobrazení jednoho článku si načte údaje pro článek nějak si je předzpracuje a pak je pošle všem Content pluginům, které jsou aktivní.

Content plugin dostane informaci o článku, o tom že se jedná o zobrazení jednoho článku (tzv kontext) a pak si může zase dělat co chce. Měl by správně obsahovat kontrolu na kontext (tj. aby se opravdu spouštěl jen tam kde má a nezatěžoval systém) a obvykle (pokud se jedná o plugin typu nahraď {graph} za můj graf) rychlou kontrolu na výskyt hledaného tagu (např. {graph}). Aź pak by měl provádět složitější záměny, přidávání JS a CSS apod. Zde už opět záleží na tom jak je napsaný.

Oproti modulu, který se na jedné stránce spustí jen jednou (resp. tolikrát, kolikrát tam je zveřejněn) se Content plugin spustí pro každý obsah na stránce, tj. pro zobrazení typu Blog se spustí např. 10 krát - nemusí to být však na škodu, tady by už se to muselo asi opravdu zkoumat detailně přes debug.

S tím dotazem "Kde zobrazovat" jsem myslel spíš umístění na stránkách (v pozici pro modul, v hlavním obsahu apod.) i když, když o tom přemýšlím je to v podstatě jedno, modul v obsahu lze zobrazit pomocí loadmodule, plugin v modulu zas pomocí "Připravit obsah".

Jasně 30 grafů - pak je lepší plugin, myslel jsem že se bavíme o jednom grafu. Otázkou ale je kde pak budou zadaný data, to už je na komponentu

Bootstrap žádný grafy nepodporuje pokud vím, existujou ale např. Google grafy, nebo rozšíření pro jQuery - myslím že cokoliv jiného než Flash by bylo přínosem