Příspěvky

A co posílat informace ze serveru na klienta, kolik dat se už poslalo? Na serverové se ví, kolik dat přiteklo, takže pomocí něakého identifikátoru, který si client/server vymění, posílat informace skrze WS kolik toho bylo přijato.

Nebo potom použit XMLHttpRequest, který to umí :-/

Ahoj všichni,

obecná otázka, má smysl dneska ještě zapínat query cache na MariaDB/Mysql pokud jsou data pouze v InnoDB (a vlezou se do RAM) a jede to na vícejádrovém procesoru? Není zapnutí kontraproduktivní?

Na produkci jsem ji vypnul a nevidím žádné zhoršení (poměr read/write je 70/30). Na vývoji mám "on demand" ale vlastně je to hloupost, protože stejně se musí DB dívat do cache zda tam něco není (přičemž SELECT SQL_CACHE se v aplikaci nachází vyjímečně).

Jde mně o bottlenecky způsobené sdílením prostorem query cache.

Díky za odpovědi

Omlouvám se za trochu offtopic, ale vzpomněl jsem si na kolegu, který na všechno psal regexpy. Na co DOM, json, Xpath, vytahnu to regexpem!

To se ta diskuze teda rozjela.. Eshopy dělám dlouho a zatím mne vychází ze nejlepší je evidovat jako hlavní cenu tu bez DPH, jakékoliv převody totiž dal jsou jednoduší (do cizí měny, vývoz zboží do EU, reverse charge, OSS). Stejně tak, když se mění sazba DPH tak přecenění zboží je jednoduší. A zároveň evidovat u tu sazbu a cenu s DPH pro některé případy, aby se s tím dobře pracovalo a pohlídat si, aby vždy v DB vše sedělo, pak je to ideál (i z pohledu dalších věcí jako, dát nějakou slevu pokud obj. je nad X částkou (a ta je zase někdy s a nekdy bez DPH).

PS: řeším to z pohledu, že systém umí vystavovat doklady (a rozlišovat jednotlivé položky a členění DPH s návaznosti dále - intrastat, dovoz a vývoz). Samozřejmě tohle menší eshop neřeší, tam to nějak udělá dal účetní - pokud tyto případy vůbec nastanou..

current() má i XSLT 1.

Jinak lze celý výstup zabalit do proměnné a pak projet for-eachem. Nevím jak to má Saxon, tam se zdá to funguje by-default, jinak použít node-set()

https://xsltfiddle.liberty-development.net/6r5EJSU/24

Na rychlost ohledně for-each VS apply-templates se musím podívat, jak to vychází..apply templates právě moc nepoužíváme (ale máme malé XMLka), někde by se to mohlo hodit...

Počkat.. vy chcete udělat jen group by Row/ItemCode a následně projete všechny ItemCode? postupně?

Nebo přímo ve for-each:

https://xsltfiddle.liberty-development.net/6r5EJSU/21

Kód [Vybrat] Rozbalit


<xsl:for-each select="ResultSet/Row[not(preceding-sibling::Row/ItemCode=ItemCode)]">
  <xsl:copy-of select="." />
</xsl:for-each>


Příklad s "if", sedí to?

https://xsltfiddle.liberty-development.net/6r5EJSU/20

Kód [Vybrat] Rozbalit


<xsl:for-each select="ResultSet/Row">
  <xsl:if test="not(preceding-sibling::Row[current()/ItemCode=ItemCode])">
    <xsl:copy-of select="." />
  </xsl:if>
</xsl:for-each>


Porovnání ItemCode=ItemCode je zjevně nesmysl, XPath procesor nemůže vědět, že tím jednou myslíte ItemCode z kontextu před spuštěním XPath výrazu a podruhé ItemCode v rámci XPath výrazu.

Doplním, že pro tyto případy lze použít funkci current(), která kontext určí přesně. Takže podmínka pak jde použít nějak takto:

ItemCode=current()/ItemCode

Používám běžne pro for-each, kdy chci rozlišit zda hodnota se vztahuje na data uvnitř for-eachu, nebo vně.

to je zase flame..

Není v tabulce headers sloupec ID zbytečný? Jeden soubor asi nemůže mít více stejných hodnot, pak bych PK volil (id_file, key).

V prvním případě je funkce sdílená napříč všemi instancemi (v prototypovém řetězci). V druhém případě se anonymní fce (uložená do proměnné starne) vytváří pokaždé znova.

Já mám za to, že responsive vznikl na základě lenosti programátorú/koderů, zkrátka se nechtělo dělat samostatné weby pro různá zařízení...

No, to máte za to špatně. Důvodem pro responzivní weby je, že separátní weby se mají neustále tendenci rozjíždět, pořád se řeší, že v desktop verzi chybí něco, co je v mobilní nebo naopak, nebo hůř, že tam je jedna věc implementovaná různým způsobem, část uživatelů to mate a chce to sjednotit, část zuřivě brání současné řešení. Plus se i přes sdílení kódu nevyhnete duplikování práce... Peklo. Proto je tlak na to, aby to byla jedna aplikace s maximálním sdílením kódu a lišil se jen styling. Ne vždy to jde a i tak se některé věci musí implementovat 2x, protože mobilní verze je příliš odlišná, ale přesto je to lepší cesta.

A dalším, IMHO hlavní motivací bylo a je to, že není jeden mobilní web. Ale je jich asi padesát. To chcete dělat padesát různých webů?

BTW: Lenost je někdy dobrá vlastnost :-)

Nevím zda si rozumíme. Já říkám udělat mobilní web, který bude perfektně fungovat vč. toho, že se bude dobře zobrazovat na malých i velkých displejích (takže lehce responziv) a to stejné pro desktop. Pak je výsledek nejlepší možný. Lenost je někdy dobrá vlasnost, o tom žádná Ale, nemělo by to být na úkor kvality (a ano, jsou weby kde se to nevyplatí a stačí "nějaký" responsive, ať to nějak funguje na všech zařízení a hotovo).

Já mám za to, že responsive vznikl na základě lenosti programátorú/koderů, zkrátka se nechtělo dělat samostatné weby pro různá zařízení...

No, to máte za to špatně. Důvodem pro responzivní weby je, že separátní weby se mají neustále tendenci rozjíždět, pořád se řeší, že v desktop verzi chybí něco, co je v mobilní nebo naopak, nebo hůř, že tam je jedna věc implementovaná různým způsobem, část uživatelů to mate a chce to sjednotit, část zuřivě brání současné řešení. Plus se i přes sdílení kódu nevyhnete duplikování práce... Peklo. Proto je tlak na to, aby to byla jedna aplikace s maximálním sdílením kódu a lišil se jen styling. Ne vždy to jde a i tak se některé věci musí implementovat 2x, protože mobilní verze je příliš odlišná, ale přesto je to lepší cesta.

To říkáme oba dva to stejné, jenom každý trochu jinak. Duplikování je peklo, ale tím že udělám responsive, ten problém přesunu akorát jinam a částešně i na návštevníka...a pak je otázka, co je horší.

Responsive si nese negativa: nikdy nemůže být tak dobrý na ovládání jako mobilní/desktopová verze, která je na míru. Tahá se hromada kódu navíc, obecně má ve WebVitals horčí skóre a pak se to vše projevuje na tržbách (pokud je to e-shop). Jsou to drobnosti, ale ve výsledku to udělá hodně.

Já mám za to, že responsive vznikl na základě lenosti programátorú/koderů, zkrátka se nechtělo dělat samostatné weby pro různá zařízení a tak zkouší takto. Někdy to funguje dobře, vetšinou však ne..

Za mně: pro mobil je nejlepší mobilní web, stejně jako pro desktop desktopový. Responsive bych nasadil na obě verze webu (mobil/desktop) pro případy, kdy je rozlíšení různé (malé velké displeje/monitory) - pak je to ideál pro návštevníka, vždy to má přesně tak, jak potřebuje. (viz třeba alza, která má mobilní web..)