Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Ja taky z javascriptu bliju a pro ruzne webove udelatka pouzivam primefaces.org - variantu pro JSF2.
Muzes ukazat priklad, jak s tim udelam tabulku, ktera se mi bude kazdou 1s aktualizovat novymi zaznamy z backendu? A pak bych rosil jeste jednou tu samou tabulku, ktera se mi aktualizuje nikoliv periodicky, ale az kdyz na backendu data zmenila, tzn. vyuziva to treba Websocket.
Tak jestli jsem te tim prilis nezaskocil, tak diky.
Na periodicke pollovani je tu primefaces Poll
http://www.primefaces.org:8080/showcase/ui/ajax/poll.xhtml?jfwid=90af5
Ne webfoctek standardni JSF2.3 <f:websocket>
https://stackoverflow.com/questions/3787514/how-can-server-push-asynchronous-changes-to-a-html-page-created-by-jsf/49852105#49852105
Ve starych Primefaces do verze 6.2 byla jejich interni implementace websocketu, tu odstranili, kdyz to zacala podporovat primo JSF
Sam jsem to nikdy nepouzil, nepotreboval jsem
Ma to fungovat velice jednoduse, ze na urvni XHTML page se websocket notifikace zachyti jako AJAX event, na ktery pripojim update prislusne komponenty, napr <p:datatable> se zobrazenim dat
Divam se na to a nechapu, v cem si pomuzes oproti Vue.js. Vzdyt budes mit napsane vesmes to same. Akorat ze kolem nebudes mit tu tucnou vrstvu javovske abstrakce. A ten poll - umi to vubec upadovat i tabulku, tzn. aplikovat ty data jako foreach template?
<h:form>
<div class="card">
<p:dataTable var="product" value="#{dtBasicView.products}" id="testtable">
<p:column headerText="Code">
<h:outputText value="#{product.code}" />
</p:column>
<p:column headerText="Name">
<h:outputText value="#{product.name}" />
</p:column>
<p:column headerText="Category">
<h:outputText value="#{product.category}" />
</p:column>
<p:column headerText="Quantity">
<h:outputText value="#{product.quantity}" />
</p:column>
</p:dataTable>
</div>
</h:form>Co myslis pod "moderni javascript"
jako javascript obecne, protoze vznikl relativne "nedavno"
nebo nejakou ECMA?
Protoze ja porad jeste musim pracovat na platforme, co podporuje jenom ECMA 5 a vetsi shit proste neni.
Takze ja v javascriptu delam a prave proto ho intenzivne nenavidim.
Ale ja se v mladi ucil Pascal a assembler, tak ja vam mladym uz nerozumim.
Jinak co si myslet o jazyku, kde vsichni reknou, "ono kdyz se to umi a kdyz pouzijes TypeScript, tak se to osefuje".
tak jazyk 1 potrebuje jazyk 2, aby byl seriozneji pouzitelny (tim nemyslim vytvoreni zeleneho tlacitka na www strance"Nechapu, jak nekdo muze preferovat Javu pred modernim Javascriptem.
modernim javascriptem myslim to co podporuji dnesni prohlizece a nodejs. Typescript nepotrebujete, typove anotace jdou psat do komentaru. Typovy system je mnohem mocnejsi nez ten v Jave.
Nechapu, jak nekdo muze preferovat Javu pred modernim Javascriptem.
Ja taky z javascriptu bliju a pro ruzne webove udelatka pouzivam primefaces.org - variantu pro JSF2.
Muzes ukazat priklad, jak s tim udelam tabulku, ktera se mi bude kazdou 1s aktualizovat novymi zaznamy z backendu? A pak bych rosil jeste jednou tu samou tabulku, ktera se mi aktualizuje nikoliv periodicky, ale az kdyz na backendu data zmenila, tzn. vyuziva to treba Websocket.
Tak jestli jsem te tim prilis nezaskocil, tak diky.
Možná bydlet v ČR, ale pracovat v Reichu.
Rozhodně nezůstávat v tomhle marastu tady.
Když si REICHU naspoříš ten základní miliónek třeba za 4 roky, aby ses nemusel moc omezovat, bude se ti na té vesnici mnohem lépe začínat. A nic tě nebude omezovat dál pracovat v zahraničí.
EDIT: Dokonce i v Praze jsou programátoři, zkušení, s praxí, po škole, ale hlavně PRACOVITÍ, kteří mají problém naspořit řekněme 300 tisíc ročně. Naspořit si 1 mega za 4 roky je v ČR pro rybízka po škole celkem SciFi. V Reichu to díky dobré pozici, šetření nákladů a drobným brigádám SciFi není.
971 ms Loading
13791 ms Scripting
36149 ms Rendering
7187 ms Painting
4322 ms System
4115 ms Idle
66534 ms TotalCitaceA kdy bys je chtěl jako mít? Na čtyřech místech?Jsou dvě možnosti. Buďto to nemá vliv na kvalitu aplikace. Pak ať ji mají programátoři kde chtějí.Anebo to má vliv, který popisoval Pavel. Pak je Tvoje výtka podobná, jako kdyby zedník říkal: a to jako po mne chceš, abych dával to okno do vodováhy? Jak si programátor zajistí konzistenci DB a zdrojových kódů je na něm. Ale nemá tím "otravovat zákazníka".
Samozřejmě, logika v DB je pro programátora (obzvlášť toho, co s tím neumí pracovat) problém a prodražuje to vývoj, zesložiťuje deploy atd. atd.... Takže se prodává spousta programů "bez voken ve vodováze" a na spoustě míst - spoustě zákazníků - to stačí. Na tom není nic špatného.
Jen prostě je třeba vědět, že to není jediný správný model baráku, a že někde je ta vodováha prostě potřeba, a pak se programátor nemůže vymlouvat na svoji "lenost". Jo, může a má si to nechat zaplatit (ale zas, má to umět, pak se to neprodraží tolik).
====
A ad k denormalizaci: správný postřeh IMHO je to, že denormalizace jsou často defakto materializované pohledy. A IMHO to i osvětluje, jak se k potřebě denormalizace (která někdy nastane) postavit.
To se netýká jen práce s databází. Často jsou celé aplikace psané tak, že se na nich nedá výkon škálovat.
Programátoři se neradi zajímají o takové "detaily", že server je jen stroj, má jen určitou paměť, počet jader procesoru. Nezajímá je, že nelze nastavit např. PHP tak, aby byl povolený běh scriptu desítky sekund a zároveň, že se nezahltí FPM a nepřestane přijímat další požadavky (v lepším případě).
Programátoři by podle mě měli vědět, že existují limity technologií, jaká je náročnost algoritmu, jak se dá škálovat a jak optimalizovat (třeba v budoucnosti). Netýká se to jen SQL.
Pocit, ať to napíšu, jak to napíšu, bude to fungovat, a když ne, tak se zaplatí vyšší výkon serveru, prostě není platný. Co funguje dobře v malém a bez dat, nemusí vůbec jít škálovat do velkého. Pokud script běží 100 ms, za sekundu jich prostě neobsloužíte víc jak 10 x počet jader, a to ještě v úplně ideálním případě. Pokud chcete vyřešit i střední odezvu, tak mnohem méně.
Programátor nemusí umět spravovat server, nastavovat databázi, umět dokonale určit vhodné indexy. Ale měl by umět poznat, kde je potřeba se zeptat - správce serveru, SQL specialisty, a dalších. Problém tedy není v tom, že neumí vše, ale že ani neví o tom, že to někdo jiný umět může a dokáže poradit.
Toto nezachráníte žádnou magickou technologií, ale širším přehledem - celkově, vzděláním v oboru.
Práce s relačními databázemi má aspoň tu výhodu, že tam ten prostor pro optimalizaci obvykle nějaký zůstává a někdy i obrovský. U jiných vám nezbude, než škálovat horizontálně, což taky není žádný med, zbytek aplikace na to musí být připravený (což třeba běžná aplikace v PHP prostě není ani vzdáleně).
PanVP to ze PHP je pre patlaly su strasne kecy. Najdes patlalov aj v Jave aj ASP. V tvojom svete je to tak ze cim kompilovanejsie tym lepsie? Minule som sa bavil s jednim kolegom ktory ma na vsetku silu presviedcal podobne ako ty. Resp. mal rovnaky nazor a nakoniec s neho vypadlo ze PHP je zlo lebo to moze pisat aj "franto od lopaty" ale Javu tak lahko nedas. Argument ako prasa. Zaujimave je ze taky FB si tiez ide PHP. To znamena ze je tam patlalovo? Casto krat ide o to ako rychlo vies dodat riesenie zakaznikovy a s pohladu firmy o to najst kvalitnych ludi ktory pisu rychlo, dobre a lacno.
Zkratka je to porad nejlepsi a postupne se doiterovavame k vynalezeni kola, viz Typescript, cop Jave ze zadnice vylezl.
Jak říkám, nomen omen. Typescript používá typový systém založené na úplně jiné filosofii, než Java (a podobné jazyky).
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.