Malování přímo v editoru Joomly

Ty obrázky na tom ukázkovém webu jsou jako stvořené pro SVG.

Podpora editorů v CMS asi ještě nebude 100% (vložení SVG různými metodami), ale v hodně blízké budoucnosti to bude standard. Dokonce jsem teď někde viděl prezentaci, kdy SVG nahrazuje hodně vlastností CSS3 nebo s ním spolupracuje.

A SVG pravděpodobní splní i tvé požadavky: vložení kódu místo bitmapy, šetříš místo na FTP ( i když to je takovej lichej argument, protože jak databáze tak soubor jsou v konečným důsledku uložený na serveru ve stejné velikosti)

a to SVG máš na mysli tvořit přímo v editoru v Joomle?

No, pokud umíš číst kód Matrix a podobné věci, pak není problém psát SVG přímo do editoru, např. kruh napíšeš takto:
Výška a šířka celého SVG je 120, kruh začíná na souřadnici X = 60, Y = 60, jeho průměr je 56, ohraničen černou čárou tlusou 3 a vyplněn červenou barvou.



Jak jsem psal, nevím, jak je to momentálně např. s editorem tinyMCE, jestli náhodou tag SVG nemaže (pokud ano, buď už to bylo opraveno, nebo v nejbližší době bude.

Jinak samozřejmě jsem to myslel tak, že si obrázek namaluješ např. v Inskape a CTRL C + CTRL V SVG kód přímo do článku.
A když se zkombinuje CSS a SVG, pak se pohybujeme úplně v jiným, pak tvý obrázky můžou dostat jednoduchý animace a jsme zase úplně někde jinde. A kominace s javascriptem - to je zase o jinel level výš.

www.hongkiat.com/blog/svg-animations/

zpetr napsal: Kód možná ano, ale pokud jde o použití souborů svg v Joomle zatím to smrdí další bezpečnostní dírou ;o) - zajímavé vlákno issues.joomla.org/tracker/joomla-cms/4674

Jen uvedu na pravou míru, že v tom vlákně se píše o uploadu SVG souboru do Joomly!, já psal o vložení kódu SVG přímo do článku.

Joomla! při uploadu kontroluje obsah souborů, a nahrání SVG zapřičiní falešný poplach. A řeší se to jestli udělat speciální pravidla pro SVG nebo ne. Protože kdyby se udělala speciální pravidla, mohl by být SVG upload potencionálně nebezpečnej - protože když se povolí použití kódu v souboru, bylo by těžké kontrolovat jestli je ten kód OK nebo škodlivěj.

Je to o uploadu. Ale pokud si vytvoříš vlastní SVG, například červené kolečko: s největší pravděpodobností budeš vědět, že neobsahuje např. javascript kód, a jiný škodlivý kód. I kdyby to měl být složitější útvar - jako např. vlajky, apod: www.phoca.cz/cssflags/ - vlajky zobrazené pomocí SVG v CSS kódě), který si např. sám nakreslíš v Inscape, pak s největší pravděpodobností (blížící se 100%) budeš vědět, že Inscape ti do SVG žádný škodlivý kód nevložil.

Mimochodem taky zajímavá možnost jak vložit obrázek (SVG):

<div class="obrazek1"></div>

a v CSS jen přidávat obrázky. Tohle je například německá vlajka

base64 se používá pro zjednodušení zápisu do CSS

SVG kód: převeden to base64:

Takže napíšeš článek:

A v CSS jen měníš kód obrázku. Výhodou je pak snížení počtu HTTP požadavků.

Ale zpět k SVG souborům. Pokud si vytvoříš vlastní soubory SVG a nahraješ si je na web pomocí FTP, pak není problém používat SVG soubory - i např. přes normální IMG tag: <img src="abc.svg" />

Těch možností je opravdu hodně a tu jednu, kterou jsme diskutovali, tedy nenahrávat pořád obrázky na server a ukládat je do databáze, může být vložení SVG přímo do článku.

Externí služby a cloudy jsou nevyzpytatelné. Tam může ze dne na den příjít limit v nějaké funkci a zbortí se ti veškerá funkčnost na tvém webu. Krásný příklad je Picasa, tam to nešlo sice ze dne na den, ale zajímavý to bylo:

Picasa - byla zrušena a změnila se na Google Plus
Google Plus - tam začaly už nějaká změny, i v API a např. nešlo propojit web s privátními alby - klíč se musel generovat ještě ve starém API Picasa
Google Photos - změnilo se API v albech, už nebyly privátní a veřejné. Privátní už nešlo vůbec propojit. A veřejné, jen ty, co jsi vytvořil dříve. V Google Photos není možnost udělat nové ablum veřejným a a tak vlastně nemůžeš propojit web s novými alby (možnost tam je, vytvořit nějakou placenou aplikaci, co to dokáže, a pod., ale to je velmi omezené)

Jde o to, co bude hlavní funkcí:
- neukládat soubory na server, pak vkládat SVG přímo do kódu
- pokud se bude obrázek často měnit, pak je asi externí soubor lepší (otázkou je, jestli se bude obrázek opravdu často měnit a zda je lepší jeho kód měnit někde v externí službě, nebo rovnou při editaci článku)

Například pro mě by externí malování a přepisování daného obrázku nemělo význam, já si ukládám změny v obrázcích zvlášť, tedy kdybych vytvořil novou variantu obrázku, musel bych ji uložit pod jiným jménem a už by mi nefunguval ten efekt, že bych nemusel měnit cestu k obrázku v článku - protože by byl pod jiným názvem.

Výhodou vložení kódu do článku je jednoznačně rychlost načítání, snížení http požadavků, možná animace (zrovna u těch tvých příkladů se dokážu představit jednoduchou animaci), apod. Podívej se sem (je to trochu jiný případ, protože screenshoty v SVG dělat je nesmysl, uvádím jen jako příklad načítání):
www.phoca.cz/phocacart
Tady jsou obrázky natahovány z externího serveru. Zobrazení všech obrázků na stránce je hodně na dlouho