Razvoj web-stranica

Razvoj web-stranica - Rasprava

Entry Point pet 7.8.2020 08:51
Dex.pwn kaže...
Ma ništa puno, koliko vidim, najkompliciranije će biti napraviti te windowe. Plan mi je da index bude glavni, a svaki window je novi div u kojeg preko iframea stavljam drugu stranicu.

 To se ne radi već 20 godina. Nemoj to raditi, postoje daleko bolji načini za async operacije, od osnovnog ajax-a do socket-a. JS frameworkci imaju takve funkcionalnost built in.

Dex.pwn pet 7.8.2020 09:35

Znam da je iframe old school, al koliko vidim to mi je najlakše, a da dela. Ako se ne varam, svaki iframe bi bio vlastiti proces, a ne samo onaj aktivan(koji mi je prikazan).

Da idem na prazan div u kojeg ću trpati informacije koje AJAX daje(recimo requestam stranicu, on pošalje izgled(HTML), i to prikažem?)

Entry Point pet 7.8.2020 10:21
Dex.pwn kaže...
Znam da je iframe old school, al koliko vidim to mi je najlakše, a da dela. Ako se ne varam, svaki iframe bi bio vlastiti proces, a ne samo onaj aktivan(koji mi je prikazan).

Da idem na prazan div u kojeg ću trpati informacije koje AJAX daje(recimo requestam stranicu, on pošalje izgled(HTML), i to prikažem?)

 Najjednostavnije ti je s ajaxom pozivati funkcije koje ti vraćaju partial html-ove odnosno djelove stranice, ako baš ne žeiš da se stranice učitavaju skroz.

 

MrBlc pet 7.8.2020 10:41

Prvo, ako radiš s bazom, vanilla PHP ima smisla koristiti isključivo za neke masovnije obračune kod kojih je ovearhead frameworka značajan faktor, a podaci su već u bazi i znaš što možeš očekivati. Takve stvari najčešće vrtiš cron jobom, ali može se raditi i on demand složenijem izvještaju, pa onda framework koristiš za access control i inicijalizaciju svega, a heavy lifting radiš na razini PDO-a.

Drugo, nisam siguran koliko će ti takav koncept biti dobar po pitanju UX-a. Browser je prozor, pa onda imaš prozore unutar prozora. Mislim da to nije dobro iskustvo. Ok je imati, primjerice, popup u kojem dodaješ novog dobavljača tamo gdje ga odabireš, ali ako korisnik istovremeno želi imati otvoreno skladište i fakture, onda su to dvije odvojene stvari.

Treće, kad radiš single page aplikacije moraš dobro paziti da ne bi imao memory leak. Za isti možeš biti kriv sam ili može biti rezultat buga u frameworku. S druge strane, mogućnost da korisnik unutar iste stranice ima otvorenu hrpu prozora znači i da DOM može brutalno narasti, kao i broj evenata, DOM related objekata, što sve skupa može dovesti do sporosti i punjenja memorije i bez memory leaka...

Dex.pwn pet 7.8.2020 12:32

Ideja je kao start menu od windows 8(.1). Bile bi aplikacije za HR, Manufacturing, Projekt Management itd..
Svaka aplikacija bi imala dodatne tabove(kao što browseri imaju). Naravno da će se sve moći raditi unutar jednog taba, ali ako trebaš šaltati između boma i work ordera(u istoj su aplikaciji), onda otvoriš dodatni tab.

Radim to sebi za gušt više, a i da naučim ponešto o webu.

Budem onda svaku stranicu "fragmentiro", a preko AJAXa budem samo dijelove osvježavao.
A sad kako budem dodavao windowe, to budem vidio 😅 AJAX da dâ cijelu stranicu

MrBlc pet 7.8.2020 13:14

Stvar je u tome što bi za to postići morao overideati dosta nativnih kontrola, što je obično indikator loše prakse, a nisam siguran ni da je moguće. Recimo, ctrl+click će napraviti što? Otvoriti novi tab unutar prozora aplikacije, otvoriti novi tab u browseru, novu instancu browsera, nešto treće? Ctrl+N će otvarati što? Jednostavno, korisnik je navikao na ponašanje browsera koji to sve handla.

 

Jedino ako pakiraš aplikaciju u neki exe wrapper i želiš imati nativni look n' feel, ali teško ćeš to s webom postići.

fighterZu pet 7.8.2020 14:24

Da, malo mi to vuče na elemente loše prakse. Što se aplikacija tiče, ako ti korisnik ima pristup samo HR-u, on će imati prikazanu ikonu samo za to (naravno to moraš osigurati i na razini backenda i na razini frontenda sa UI strane). Tu bi ti općenito neki framework riješio bez pola muke nego da se manualno petljaš sa time i napraviš neki security flaw.

Što se tiče tabova, ne znam zašto želiš imati princip kao kod browsera, malo mi to čudno zvuči i pokušavam si to zamisliti na najbolji način. U biti tebi bi tab bio neka forma koju bi započeo ispunjavati, zatim bi otvorio drugu formu no mogao bi se vratiti  na prvu koja je dijelom već ispunjena, itd. Pretpostavljam da ciljaš na multitasking sa te strane (tu bi ti nekakav state managment sustav ili reactive library extension došao kao šlag na tortu, no dobro). I ako sam te dobro shvatio želis postići i to da kad editiraš jednu formu da su promjene vidljive na drugoj formi u drugome otvorenom tabu?

 

Dex.pwn pet 7.8.2020 14:52

Pa kad otvoriš HR "app", možeš ju jednom otvorit, a ako popunjavaš nešto, ako hoćeš vidjeti informaciju koja je izvan forme, možeš otvoriti novu karticu u app. To je za sad ideja.


Budem proguglao pojmove koje si napisao

veliki pero pet 7.8.2020 19:51
Nuclear_Phoenix kaže...

Leto gospodnje 2020. a mi pričamo o iframe-ima u novoj web aplikaciji...

 Pa i extra security za banke (secure by mastercard/verified by visa) rade u iframeu. Tako da ne vidim problem. Svima kao trebaju bloated fensi frameworks za najjednostavnije stvari, a koriste 10% mogucnosti istog. Da ne pricam o bloatu samih stranica. Ako vidis 100kB s tesku stranicu to je wow. Nekada si morao to drzati ispod 5kB. Kucaj rucno kod za maksimalnu optimizaciju

 

Odradio sam dosta web stranica za postene radne ljude mesare, pekare, automehanicare. Njima ne treba wordpress koji se slepa na 1/2GB RAMa, ne trebaju im fensi javascript framework. Stavis miks staticnih stranica i JavaScrpta i sve ide kao podmazano.

 

Kad ti dodje nadobudni menadjercic neke kvazi meta-kompanije urazvoju. Onda ukljucis sve zivo. net/python SAS za CSS angular.js, custom CMS i naplatis 100k eura i svi zadovoljni.

Nuclear_Phoenix pet 7.8.2020 22:16
veliki pero kaže...
Nuclear_Phoenix kaže...

Leto gospodnje 2020. a mi pričamo o iframe-ima u novoj web aplikaciji...

 Pa i extra security za banke (secure by mastercard/verified by visa) rade u iframeu. Tako da ne vidim problem. Svima kao trebaju bloated fensi frameworks za najjednostavnije stvari, a koriste 10% mogucnosti istog. Da ne pricam o bloatu samih stranica. Ako vidis 100kB s tesku stranicu to je wow. Nekada si morao to drzati ispod 5kB. Kucaj rucno kod za maksimalnu optimizaciju...

Znao sam da će naletit jedan ovakav, pa čovjek priča o ERPu a ne o stranici za frizera!!? Najbolje da sam napiše i web server? Kompajler? OS? Možda cijeli CPU da sastavi od nule?

 

Majko božja, Vue.js ima 33kb, jel to razlog da se patiš sa vanilla JS?

 

Najbolje da svi kucamo u assembleru.

Dex.pwn pet 7.8.2020 22:35

Mislim da je sustav banke koji koristi iframe(iskreno, tek kad je kolega iznad napisao, shvatio sam da login od Erste je frejman), a opet banka je osjetljivija od ERPa.

A i ovo je za mene prvo, a tek kasnije za druge.

Mada, budem još malo razmislio kako ću UX napraviti, vjerojatno neće trebati iframe već, ako treba multitaskat, otvorit će se novi tab u browseru.

Start screen i dalje bude bio, jedino ne znam kaj da stavim na "task bar". Imali tko kakve ideje?

Malo bi cp Windows, dole lijevo start ikonica(otvara start menu), desno dole sat/kalendar i noft ikonica. A po dužini? Jedan dio bude išao na searchbar, a za ostalih 75-85% duljine ne znam :D Još

 

Btw jQuery ima skoro 100kB

SebaOS sub 8.8.2020 07:20

Izmišljaš toplu vodu, nhf. Industrijski standardi su s razlogom takvi kakvi jesu, ako trebaš SPA, biraš Vue ili React. 100kb za osnovni framework koji sadrži sve što si tražio je đabe, ne slušaj ekipu koja hoće (SPA) sajt za 5kb jer je "tako bilo prije". 

 

 

MrBlc sub 8.8.2020 08:50

@veliki pero - za čisto statične stranice koriste čistog html-a u .php fileovima kako bi mogao includeati header i footer je ok.

Međutim, čim taj mesar ima potrebu korigirati cijene, vrlo brzo mu cms postane jeftiniji nego da tebi plaća da mu unosiš korekcije. Tebi su takve korekcije ionako tlaka, a on misli da ga time muzeš...

Entry Point sub 8.8.2020 09:30

Da skratimo priču. Pisanje svega od nule je vrlo loše. Imaš tone PHP framework-a (ako baš hoćeš php) koji će ti olakšati posao, i učiniti sve to skupa daleko sigurnijim. Pisati od nule znači i tona bugova i sigurnosnih rupa. Zato i postoje framework-i. Ja sam nekad koristio Codeigniter koji dan danas "is going strong." Odličan mali framework, moćan, i siguran: https://codeigniter.com/. Learning curve mu nije nešto, zato ga i preporučam.

 

Zaboravi win 8 izgled, korisnici će ti biti ekstremno zahvalni ako napraviš normalan klasičan dizajn: header - content - footer. Što se tiče logike, flow-a, dizajna, možeš koristiti neki js framework, ali i ne moraš. Možeš rokat jquery i neke njegove pluginove, bootstrap i bok. Bez puno filozofije. Mislim da ti za ERP ne trebaju Vue, Angular i ostale đinđe, jer imaš samo još jedan layer koji moraš održavati (i isprogramirati), a ne isplati se za takve sustave.

 

Zaboravi kopiranje OS izgleda, pokušavali su to prije 6-7 godina i drugi dizajneri i nije dobilo neku popularnost.Zna se što je web, a što je OS.

 

Eto, počni tako pa javi kako ide. 

 

 

 

 

Nuclear_Phoenix sub 8.8.2020 10:50
Entry Point kaže...
Mislim da ti za ERP ne trebaju Vue, Angular i ostale đinđe, jer imaš samo još jedan layer koji moraš održavati (i isprogramirati), a ne isplati se za takve sustave.

Pa što nije lakše raditi takve sustave (ERP, CRM i ostalo sa milijardu formi i polja) sa nečim što zna što je two way binding? Ok, postoje pluginovi za jquery za to ali nije zamišljen od nule za to tako da je u osnovi improvizacija... Zašto improvizirati ako postoji prava stvar?

Dex.pwn sub 8.8.2020 11:00

Me razumijem šta je taj two way biding? Ovak Sve forme budu prek AJAXa išle


Guglo, ali opet ne kužim.
Imam formu, nju popunjavam, i tek kad kliknem na save ili nešto, AJAX odradi svoje. Ne vidim gdje mi taj TWB može pomoć

Nuclear_Phoenix sub 8.8.2020 11:15

What is two way data binding

 

Zamisli da imaš formu za upis podataka o zaposleniku. Ime, prezime, adresa, grad, OIB, spol, odjel, manager, vrsta zaposlenja, zaštita na radu, posebni uvjeti rada, IBAN, email, telefon, mobitel, AD korisnik, reg pločice za parking, broj cipela... Imaš ovako iz glave 20 polja. Recimo da sa AJAXom povučeš sa servera svoje podatke. Kad se to učita, moraš napisati funkciju showEmployee() koja sve podatke iz objekta (modela) potrpa u HTML (view). To je 20 puta $("txtEmployee...").value = employee.fieldX. Kad se nešto promijeni (netko upisuje novog zaposlenika ili ažurira postojećeg) moraš napisati hrpu event handlera za svako od tih polja da bude employee.fieldX = $("txtEmployee..").val() tj. da se iz viewa updatea model. Na jednoj jedinoj bezveznoj formi ti treba 20 linija HTMLa, 20 linija za čitanje i 20 linija za pisanje. To je 60 linija koda ne računajući logiku za onChange(). 15 takvih formi - 1000 linija koda. Industry average je između 15 i 50 bugova po 1000 linija. Dakle, samo na formama ćeš si napraviti bar 20 bugova.

 

Što ne bi bilo ljepše da je to sve skupa automagično riješeno da imaš recimo <input type="text" bind="employee.name"/> i ona kad učitaš model on "sam" popuni taj HTML sa vrijednostima a kad netko promijeni vrijednost da se taj employee objekt "sam" updatea i kad netko klikne Save tvoj jedini posao je napraviti POST sa tim employee objektom bez razmišljanja da li si updateao objekt sa svim vrijednostima iz forme? 60 linija svedeš na 20. Tri puta manje koda.

Dex.pwn sub 8.8.2020 11:47

Okej, imamo Angular, Vue i ReactJS
Koji od njih je najsličniji jQueryu? Znači da imam HTML file koji izgleda isto, i da pored njega imam X file koji sadrži front end kod.

Nisam ljubitelj da moram front end pisati u HTML fajlu (mislim da je to Vue).

I koji je traženiji na tržištu rada? Također isto pitam i za PHP fwove(Laravel i ekipa)

SebaOS sub 8.8.2020 12:10

Kratki odgovor - isti vrag, nećeš pogriješit s ni jednim. 

 

Dugi odgovor: 

Angular je vjerojatno najbliže nečemu što si radio ako si radio bilo kakav MVC development, a spominješ odvajanje logike i viewa pa ajmo reć da kužiš. Angular je najveći, ali je tako najmanje fleksibilan i za razliku od druga dva koji su libraryji, Angular je više framework koji ima svoje načine za hendlat većinu situacija.

 

React i Vue su puno bliže čistom JS/TS kodu, gdje možeš sam odlučit kako ćeš strukturirat neke stvari, ali samim tim i daje više mjesta za zajebati. 

 

Nemam pojma službene brojeve, ali ovako iz pogleda nekog tko radi s tim svaki dan, React je najpopularniji, Vue raste na popularnosti jako, a Angular opada i sve manje se koristi. React pametno izdaje nove verzije, Angular voli kidat backwards compatibility, za Vue nemam pojma. Puno oglasa za posao vidim koji spominju React/Vue, nešto manje Angular, iako je i to nebitno, ideja iza svih je ista. 

 

Rekao bih da je React industry standard, ali će se sigurno nać netko i reći da je XY situacija bolje hendlana u XY frameworku, što je istina, ali Facebook stoji iza Reacta, koriste ga i sami na novoj verziji, kao i banke, ogromni sajtovi i appovi, mali sajtovi i appovi, TS podrška, ogroman community i bezbroj alata ga čine najkompletnijim rješenjem, makar nije u apsolutno svakoj situaciji najbolji. Uzmeš i naučiš radit oko nedostataka :) 

 

Sretno 

ministar sub 8.8.2020 18:40

React i Vue su tu negdje. Jako su slični i dosta uzimaju i popravljaju prema onome što drugi ubace.

 

Ako ideš na Laravel za backend, podrška za Vue je već tamo, ne moraš ništa sam dodavati i možeš odmah raditi.

 

I dodatak, Vue ima dobar backwards compatibility i TypeScript support koji će biti još bolji s verzijom 3.

Dex.pwn sub 8.8.2020 23:49

Kad je u pitanju vanilla PHP, koji je najbolji način (da nije zahtjevan za resurse, a opet da nije dosta posla) za napravit multi language page?
Za sad mi je palo na pamet da svaki php file ima svoj php file za jezik, i da varijable drže poruku. Recimo file A.php bi imao A-en.php, A-hr.php. Svi lang fajlovi bi bili u posebnom folderu

MrBlc ned 9.8.2020 09:12

To je najjednostavnije rješenje, ali, prvo ćeš imati puno duplih prijevoda, a vrlo brzo ćeš imati kao globalnih varijabli.

Funkcija za prevođenje koja će interno pri prvom korištenju neke kategorije povući file u kojem je definiran array prijevoda i držati ga dalje u memoriji (realno, tu će ti trebati ili neki globalni objekt ili dependency injection koji podržava singleton objekte).

Onda ćeš imati problem da ti možda neki prijevod nedostaje, a toga nisi ni svjestan. Zato frameworci obično imaju helpere za ekstraktiranje prijevoda.

Pa onda će ti sutra dosaditi da za svaku stvar ručno pišeš SQL, pa ćeš se pitati kako napraviti neki database layer koji to odrađuje, pa kako pojednostaviti validaciju podataka, pa kako omogućiti access control, pa ćeš skužiti da je isti daleko jednostavniji kad imaš routing preko index.php filea, nego ako imaš više entry pointa, pa ćeš tražiti kako s vanilla PHP-om napraviti najjednostavniji router... Vidiš u kom smjeru to ide?

pr0n_addict pon 10.8.2020 19:39
Dex.pwn kaže...
Kako keširat podatke? Jedino pronalazim kako keširati stranicu, cijelu. Meni treba da keširam postavke i slične stvari.
Nešto kao što postoji $_SESSION, samo na globalnoj razini.

Keširao bi gdje točno, na klijentu ili serveru?

Na klijentu se koriste Web Storage (local ili session) za key/value spremanje i dohvat objekata ili IndexedDB za kompleksniju strukturu podataka (vjerojatno je overkill ako ti treba samo cache).

Na serveru vjerojatno postoji nekakav memory cache library za PHP ili ga odabrani framework već ima ugrađenog (ne radim u PHP-u pa ovdje pretpostavljam).  Ako bi radije out-of-process cache onda ti je imho najbolji izbor Redis koji je opet overkill ako planiraš imati samo jednu instancu backend site-a (dakle nikakav load-balancing, monolitna arhitektura umjesto mikroservisne, ...) što je za manji novi projekt sasvim prihvatljivo jer se dodatna kompleksnost uvodi ako i kada se pojavi potreba za tim (počnu patiti performanse, održavanje codebase-a i slično). Očita pogodnost neovisnu o deploymentu sustava je što Redis cache "živi" i kada se tvoj site restarta/ugasi pa čak i site na kojem se vrti Redis-ov server (jer po defaultu periodički persista cijeli in-memory DB na disk). Sve ovisi o tome koliko ti je bitna robusnost cache-a.