Git za solo developere: zašto ga trebaš koristiti i kada radiš sam

Kroz godine rada i razvoja više desetaka softverskih proizvoda često sam se susretao s otporom prema korištenju Git-a kod, solo, developera.

Pod solo developerom smatram osobu koja je sama odgovorna za neki softverski proizvod, neovisno radi li se o freelanceru ili zaposleniku tvrtke.

Izgovor je gotovo uvijek isti: „Radim sam, znam što radim. Git mi ne treba. Git je gubljenje vremena.“

I mogu to razumjeti — barem kratkoročno. Ako si jedini developer, nema konflikata, nema pull requestova i nema potrebe za koordinacijom. Sve odluke donosiš sam.

Osim toga, i bez Git-a, previše je alata koje je tijekom razvoja potrebno koristiti da nije neobično neki od njih preskočiti. Ipak, gubljenje vremena, češće pogreške, ne zna se gdje je zadnja verzija i sl. problemi su koji bespotrebno nastaju takvim načinom rada.

Ali što se događa kada dođe do zaborava, brzopletih odluka ili problema koji se ne vide odmah? Tu Git prestaje biti “alat za timove” i postaje rješenje.

Git kao sigurnosna mreža

Ako ne koristiš Git, vrlo brzo se nađeš u poznatoj situaciji:

“Samo ću malo refaktorirati ovaj dio…”
“Ma zapamtit ću kako je bilo prije.”

Naravno da nećeš. I onda se nađeš u panici kako ručno vratiti ispravnu verziju.

Git ti daje mogućnost da u svakom trenutku kažeš: ovo je stanje s kojim sam zadovoljan. Commit je checkpoint. Ako nešto pođe po zlu, povratak traje nekoliko sekundi. Bez kopiranja foldera, bez ZIP arhiva i bez kreativnih naziva tipa projekt_zadnja_verzija_v3.

Pamćenje je nepouzdano

Danas znaš zašto si nešto napravio. Za tjedan dana — još možda. Za nekoliko mjeseci — vrlo vjerojatno ne.

Tu Git postaje više od alata za verzioniranje. Postaje dnevnik odluka. Dobra commit poruka ne bilježi samo što je promijenjeno, nego zašto. Nema nagađanja i gubitka vremena.

Razlika je ogromna:

Loše:

zadnja verzija

Bolje:

fix: popravak API endpointa za na login formi

Druga poruka ti i nakon pola godine daje kontekst koji iz koda više nije očit.

Primjeri commit poruka

Ne treba si nametati nikakav strogi standard. Dovoljna je jednostavna struktura u obliku:

<tip>: kratki opis promjene

Nekoliko tipova:

  • feat – kad se dodaje nešto novo feat: dodana autentikacija korisnika
  • fix – kad se popravlja bug fix: ispravljen krivi izračun ukupne cijene
  • refactor – kad se čistim kod bez promjene ponašanja refactor: pojednostavljena logika validacije
  • chore – tehničke i pomoćne promjene chore: update dependency-ja

Poanta nije u pravilima, nego u tome da se kasnije možete brzo snaći u povijesti projekta — bez pogađanja.

Korištenje commit poruka kao što je “zadnja verzija” ne govori ništa, nema smisla i poništava svrhu Git-a jer on nije mjesto za backup.

Lakše održavanje i rješavanje bugova

Kad se bug pojavi, a pojavit će se, Git povijest ti omogućuje da vidiš kada je problem uveden, što se točno promijenilo i u kojem kontekstu je odluka donesena.

Čak i git blame prestane biti neprijatelj. Istina, često pokaže prstom u tebe samog iz prošlosti, ali barem znaš gdje tražiti rješenje.

Jednostavan Git workflow za solo developera

Kad radiš sam, ne treba ti ništa komplicirano. Ovo mi se pokazalo sasvim dovoljnim:

  • main – stabilna verzija projekta
  • feature branch-evi po potrebi

Primjer:

main
 └── feature/login
 └── feature/payment

Flow je jednostavan: napraviš branch, radiš promjene, commit-aš male cjeline, merge-aš u main i obrišeš branch.
Čak i kad si sam, branch-evi ti daju slobodu da eksperimentiraš bez straha da ćeš razbiti stabilnu verziju.

Priprema za budućnost (i timski rad)

Možda danas radiš sam. Ali sutra se stvari mogu promijeniti kada projekt naraste, dođe novi developer ili klijent želi uvid u povijest rada.

Projekt s jasnom Git poviješću lakše je razumjeti, lakše održavati i djeluje profesionalnije. A čak i ako se ništa od toga ne dogodi — ti za šest mjeseci si već “drugi developer”.

Git kao profesionalna navika

Git je industrijski standard. Korištenjem Git-a i na solo projektima gradiš disciplinu, olakšavaš si kasniji rad u timu, a tvoji projekti izgledaju zrelije i promišljenije.

Repozitorij bez povijesti izgleda kao gotov proizvod bez konteksta. Repo s dobrom poviješću pokazuje proces i način razmišljanja.

Zaključak


Ako želiš biti ozbiljan developer, Git nije opcija – on je standard. Git je alat koji ti omogućuje da radiš opuštenije, sigurnije i dugoročno pametnije.

Napravi git init, piši smislene commit poruke i tretiraj Git kao svog najpouzdanijeg suradnika.

Dohvaćanje podataka s API-ja Sudskog registra data.gov.hr

Prije nekoliko godina objavio sam blog post o prikazu podataka API-ja Sudskog registra – pravosudje.hr.

API se tada nalazio na adresi https://sudreg-api.pravosudje.hr, dok će se od 1. travnja nalaziti na adresi https://sudreg-data-test.gov.hr/za testno tj. na adresi https://sudreg-data.gov.hr/ za produkcijsko okruženje.

Više o detaljima i razlozima prebacivanja API-ja na novu adresu možete saznati na https://data.gov.hr/ckan/dataset/sudski-registar.

Ukratko, to znači da se osim URL-a putem kojega će se pozivati API mijenjaju i parametri potrebni za pristup tim podacima.

“Portal otvorenih podataka Sudskog registra namijenjen je razvojnim inženjerima koji u svoja aplikativna rješenja žele preuzimati podatke Sudskog registra (https://sudreg.pravosudje.hr) u strojno čitljivom obliku.

Za pristup podacima potrebno je napraviti registraciju. Nakon uspješno predanog registracijskog obrasca korisnik će dobiti e-mail za potvrdu svog korisničkog računa. Verifikacijom računa korisnik će biti preusmjeren na stranice aplikacije te će mu se dodijeliti Client ID, Client Secret i link za dohvat tokena koji omogućuju pristup RESTapi sučeljima.”

Registracija i aktivacija

Prije registracije potrebno je prijaviti se, a to je moguća napraviti korištenjem e-građana te putem servisa Facebook, Google i Microsoft na linku https://data.gov.hr/ckan/dataset/sudski-registar i klikom na ‘Prijava’ u gornjem desnom kutu ekrana.

Portal otvorenih podataka

Nakon prijave mogu se vidjeti detalji o postupku registracije i što se njome dobije. Klikom na “Registracija” pokreće se postupak.

API sudskog registra

Klikom na “Registracija” otvara se jednostavna forma gdje se navodi naziv i opis projekta u kojemu će se koristiti API.

Forma API-ja Sudskog registra

Klikom na “Predaj zahtjev” otvara se sljedeći ekran gdje se vide detalji poput parametara Client Id i Client Secret koji će biti potrebni za slanje upita na API tj. dobivanje tokena.

Sudski registar API

Prije nego se prikazani podaci mogu koristiti potrebno je potvrditi tj. verificirati e-mail klikom na “Potvrdi”.

Sudski registar API email

Nakon toga preostaje još kliknuti na “Aktivacija” i to je to što se registracije tiče.

Sudski registar API aktivacija

I konačno, podaci su spremni za korištenje.

Sudski registar API podaci

Provjera rada API-ja

Kako je i navedeno u dokumentaciji API mogu provjeriti koristeći Curl (Client for URL) naredbu i to želim napraviti prije nego krenem s postavljanjem Angular forme.

Naredba se upisuje u naredbeni redak (CMD) u sljedećem obliku: curl -i -k --user ClientId:ClientSecret --data "grant_type=client_credentials" https://sudreg-data.gov.hr/api/oauth/token

Curl naredba Sudreg API

Iz navedenog mogu vidjeti u kojem obliku i koje parametre će mi API vratiti. U ovom slučaju najvažniji mi je parametar access_token koji će mi trebati prilikom pozivanja drugih API-ja.

Također vidim da token vrijedi 6 sati (21600 sekundi) od trenutka kreiranja.

Dohvaćanje tokena testirat ću i koristeći Postman.

Odmah ću, također putem Curl naredbe, isprobati jedan API u kojem ću proslijediti access_token da bi dobio podatke. Želim se uvjeriti da sve radi prije nego počnem s kreiranjem API servisa u Angularu.

Pokretanjem Curl naredbe curl --location "https://sudreg-data.gov.hr/api/javni/sudovi?expand_relations=true" ^ --header "Content-Type: application/json" ^ --header "Authorization: Bearer access_token" dobijem sljedeće:

Popis sudova API

Kako se može vidjeti iz gornje naredbe ovdje prosljeđujem samo dva parametara u headeru i već sam dobio “osjećaj” kako će funkcionirati svi ostali API pozivi.

Nadam se bez grešaka koje neki od njih trenutno imaju. 🙂

API detalji_subjekta

S obzirom da me API detalji_subjekta trenutno najviše zanima više ću pažnje obratiti na njega što se tiče dokumentacije.

Na adresi https://sudreg-data.gov.hr/api/OpenAPIs/OpenAPIJavni se nalaze sve dostupne API točke. Između ostalog tu je i detalji_subjekta.

Iz dokumentacije vidim da se radi o get metodi i koje obavezne parametre trebam slati.

API detalji_subjekta

Kreiranje API servisa

U servisu će se nalaziti dvije funkcije. Jedna će dohvaćati access_token, a druga podatke o tvrtki prema OIB-u ili MBS-u.

Obavezni parametri za dobivanje tokena:

  • Content-Type (string) / header – ‘application/x-www-form-urlencoded’
  • Authorization (string) / header – ‘Basic ‘ + btoa(‘ClientId:ClientSecret’)
  • grant_type (string) / body – client_credentials

Obavezni parametri za dohvaćanje detalja tvrtke:

  • Content-Type (string) / header – ‘application/json’
  • Authorization (string) / header – ‘Bearer ‘ + access_token
  • tip_identifikatora (string) / query – ‘oib’ ili ‘mbo’
  • identifikator (string) / query – 0000000000 ili 000000000

Angular forma

Forma će biti jednostavna. Nakon unosa OIB-a ili MBS-a popunit će se polja naziv, adresa i grad. API naravno dohvaća puno više od toga.

Što se funkcionalnosti tiče i s obzirom da je ovo samo demo prikaz neću ići previše u detalje.

Unutar ngOnInit() funkcije pozivam API za dohvaćanje tokena. U produkcijskom okruženju ne bih to radio na ovaj način nego bih spremio token i novi ne bih tražio sljedećih 6 sati dok trenutni ne istekne.

U praksi to izgleda ovako. Unosom OIB-a ili MBS-a poziva se funkcija za dohvaćanje detalja poslovnog subjekta.

API sudskog registra

Jednom kada access_token istekne dobit će se poruka

API neautorizirano

I to je to. Istovremeno vrlo jednostavan i vrlo koristan API koji može poboljšati funkcionalnosti nekog programskog rješenja.

Capacitor ili Cordova za razvoj Ionic aplikacija?

Ionic aplikacije razvijam od 2015. godine i sve do prije nešto više od godinu dana temeljio sam ih primarno na Cordovi.

Usput sam pratio razvoj Capacitora koji je sa verzijama 3 i 4 počeo “dobivati oblik” s kojim sam bio zadovoljan. Tada sam zaključio da može poslužiti kao temelj novih, ali i postojećih projekata.

Cordova pripada prošlosti

Ako se pogleda samo činjenica da je Cordova nastala 2009., a Capacitor 2018. više je nego jasno da među njima vrlo vjerovatno postoje dosta velike razlike. Bile one konceptualne ili praktične ipak su razlike.

Godinama je bilo gotovo nezamislivo pristupiti nekim značajkama mobilnih uređaja bez nekoliko Cordova pluginova u različitim stupnjevima razvoja i održavanja, a sada je stiglo nativno.

Također, kroz godine se povećavao naglasak na sigurnosti mobilnih aplikacija pa tako Google i Apple više neće pustiti bilo što u svoje trgovine aplikacijama. Pri tome održavanje postojećih, a pogotovo razvoj novih aplikacija temeljenih na Cordovi gubi svoj smisao.

Capacitor nije zamjena za Cordovu

Ovo je i najveća zabluda developera koji su toliko navikli na Cordovu da Capacitoru ne žele dati niti šansu jer misle da sada moraju sve mijenjati i raditi ispočetka.

Capacitor je kompatibilan sa Cordovom tako da niti migracija nije veliki problem i moguće ju je raditi postupno. Ako i dođete u slučaj da ipak trebate neki stariji Cordova plugin moći ćete ga dodati u postojeći Ionic Capacitor projekt.

Iako Capacitor i Cordova mogu raditi zajedno osobno mi je cilj u svim projektima postupno skroz napustiti Cordovu.

Prednosti Capacitora

Najveća prednost je skroz druga filozofija razvoja aplikacija, koja je više prilagođena današnjem tehnološkim potrebama. Ali da ne bi sve ostalo na filozofiranju evo i konkretnih prednosti koje mi se osobno sviđaju.

Brži i jednostavniji build/deploy aplikacija

Postavljanje na Google Play Store i Apple App Store nešto je čime završi svaki novi ciklus razvoja nove ili održavanja postojeće aplikacije. To je proces koji se ponavlja i kao takav je važno da bude što jednostavniji.

Capacitor omogućava brže i jednostavnije kreiranje produkcijskog builda. Kod Android aplikacija sve ide putem Android Studia. Kod iOS-a mi je isto kao i do sada, s tom razlikom da više nema problema s nekompatibilnosti verzija nekih pluginova.

Manja ovisnost o pluginovima

Capacitor donosi nativne funkcionalnosti, kao npr. Deep Link, za koje više nisu potrebni pluginovi što je bio slučaj sa Cordovom. Samim time manje toga je potrebno posebno ažurirati i usklađivati po pitanju verzija.

Svaki plugin manje donosi aplikaciju koju je lakše održavati.

Jednostavna migracija

Općenito kada se prelazi sa tehnologije na tehnologiju u dosta slučajeva su u pitanju toliko velike promjene da je jednostavnije sve raditi ispočetka. To nije slučaj kod Capacitora.

Iako donosi značajne promjene, Capacitor u prvoj fazi migracije može poslužiti samo kao temelj. Čak i kada se ostave postojeći Cordova pluginovi. Kada se savlada taj korak, onda lagano migrirati ili uklanjati plugin po plugin. Kod pluginova koji nisu kompatibilni sa Capacitorom potrebno je odmah planirati adekvatnu zamjenu.

Izrada nove aplikacije

Kada se kreira nova aplikacija u startu je sasvim lijepo vidjeti da više ne postoji ovisnost o config.xml-u. Platformske postavke su sada ondje gdje i trebaju biti – u datotekama pojedine platforme. Za Android je to AndroidManifest.xml, a za iOS Info.plist.

To je super. Jer koliko god se prije pisalo “programiraš jednom za sve platforme” u praksi to često nije bio slučaju kada su u pitanju razlike između iOS-a i Androida.

Zaključak

Iz svega navedenog meni je Capacitor jedini logičan izbor i jedva čekam vidjeti što će novog donijeti.

Implementacija CorvusPay kartičnog plaćanja koristeći Node.js, Express.js i Angular

U ovom blog postu možete saznati kako implementirati CorvusPay kartično plaćanje koristeći Node.js tj. Express.js i Angular Framework.

Kartično plaćanje provodi se kroz Corvus Form Service što znači da korisnik nakon odabira artikala bude preusmjeren na URL za autorizaciju kreditne kartice. Na tom URL-u ispunjava se obrazac s potrebnim podacima o kreditnoj kartici nakon čega korisnik ponovno bude preusmjeren na web shop gdje se najčešće prikazuje poruka o ne/uspješnoj kupovini.

Tijek transakcije kroz CorvusPay sustav odvija se na sljedeći način:

  • Kupac u web trgovini odabire proizvod ili uslugu koju želi platiti karticom.
  • Kupac se preusmjerava sa stranice trgovca na CorvusPay platnu formu (stranicu) gdje unosi podatke potrebne za realizaciju kartične transakcije.
  • CorvusPay šalje banci zahtjev za autorizacijom.
  • Banka šalje odgovor na zahtjev za autorizacijom na CorvusPay.
  • CorvusPay preusmjerava kupca na cancel ili success url kojeg definira trgovac ovisno o ishodu transakcije.

Moguća je i integracija tog obrasca unutar web shopa, ali u tom slučaju trgovac mora imati PCI DSS certifikat.

Tijek implementacije

Proces se istovremeno odvija u dva smjera. Prvi se tiče administrativnih poslova u kojima Corvus od trgovca prikuplja potrebnu dokumentaciju za pokretanje procesa aktivacije kartičnog plaćanje koju prosljeđuje prema bankama/kartičnim kućama.

Paralelno trgovac (web shop) postavlja obavezan sadržaj na web trgovinu (uvjeti korištenja i plaćanja, logo CorvusPaya,…), vrši implementaciju prema dostupnim uputama i testira sustav pomoću razvojnog certifikata. Nakon obavljenih testova postavlja se produkcijski certifikat čime se proces implementacije završava.

Uvod

Komunikacija između trgovca i usluge CorvusPay vrši se putem HTTPS POST web zahtjeva.

Svaki web zahtjev prema Corvusu treba obavezno sadržavati tri parametra, a to su:

Store ID
Secret Key
Client Certificate (.p12).

Dobiju se dva seta ovih podataka. Jedan set za testiranje, a drugi za produkciju.

Obavezni CorvusPay parametri

Obavezni parametri su: version, store_id, order_number, language, currency, amount, cart, signature i require_complete.

U slučaju greške pri kreiranju parametara prikazat će se sljedeći ekran:

CorvusPay greška
Vaš zahtjev ne može biti obrađen – CorvusPay

order_number mora biti jedinstven jer sustav će provjeriti i odbiti svaki upit na Corvus API ako narudžba s istim brojem narudžbe već postoji.

signature se kreira koristeći HMAC-SHA256. On se sastoji od svih obaveznih i opcionalnih vrijednosti (key-value field pairs), poredanih abecedno i spojenih bez razmaka.

To onda izgleda ovako:

na osnovu čega se dobije signature

signature = HMAC-256(key, key-value field pairs)

~ ključ: UNV3-i2otJw0rUWzA2lpcNRqTOYRWdAeTw
~ parametri:
– version : 1.3
– store_id : 2029
– order_number : 1537270065109
– amount : 10.00
– currency : HRK
– cart : kindle paperwhite
– require_complete : false
– language : hr

CorvusPay HTTPS POST
CorvusPay Integration Manual v5.1.0

Neobavezni CorvusPay parametri

Osim obaveznih parametara moguće je koristiti i neobavezne. U ovom slučaju to će biti parametri vezani uz plaćanje na rate.

Tri su načina pokretanja transakcije na rate:
• Fiksni broj rata
• Fleksibilan broj rata
• Samostalan odabir rata za određenu karticu

Napomene:
• Ako se za određenu platnu karticu ne pošalje parametar payment_brandName kartica neće biti dostupna za odabir
• Prvi znak parametra payment_ trebao bi biti jednak N ili Y jer to označava je li dozvoljeno jednokratno plaćanje ili ne
• Posljednja četiri znaka određuju raspon broja rata. Kupac može odabrati broj rata u rasponu između prvog dvoznamenkastog broja i drugog dvoznamenkastog broja

CorvusPay plaćanje na rate
CorvusPay Integration Manual v5.1.0

Web aplikacija (Angular)

Unutar forme pomoću POST metode poziva se API za pokretanje kartičnog plaćanja.

Sve navedene vrijednosti su promjenjive tako da ih prilikom svake promjene unutar .ts datoteke treba osvježiti i unutar forme </form>.

Parametri signature i payment_ mogu se kreirati na frontendu i backendu. U ovom slučaju oni će se kreirati na frontendu i prosljeđivati kroz formu na API.

Za potrebu kreiranja HmacSHA256 potpisa koristi se crypto-js. Uz to, unutar environment varijable nalaze se razvojni i produkcijski parametri secretKey i storeId.

Glavna razlika u ovom dijelu tiče se ukupne cijene tj. ovisno o tome prelazi li iznos od 500kn plaćanje na rate biti će odobreno ili onemogućeno. U oba slučaja kreira se različit signature.

Za ukupan iznos veći ili jednak 500kn koristi se sljedeće:

CorvusPay - plaćanje na rate

Dok se za iznose manje od 500kn koristi:

CorvusPay - jednokratno plaćanje

Backend API (Express.js)

Backend logika nalazit će se u server.js datoteci. Kako ju kreirati možete se vidjeti u blog postu “Izrada RESTful API-ja koristeći Node.js i Express.js“. Razlika između primjera iz tog blog posta i ovoga sada je što više nije potrebno koristiti body-parser.

Ova će se datoteka sastojati od tri krajnje točke (API endpoints).

Prva krajnja točka, '/corvusPay', preusmjerit će korisnika na formu za plaćanje.

Nakon unosa i obrade podataka o kartici

CorvusPay - obrada u tijeku
CorvusPay – obrada u tijeku

korisnik je preusmjeren na dodatnu sigurnosnu autentifikaciju kartice.

CorvusPay - sigurnosna autentifikacija kartice
CorvusPay – sigurnosna autentifikacija kartice

Ako je sve prošlo uspješno korisniku će se prikazati obavijest

CorvusPay - transakcija-uspjela
CorvusPay – transakcija uspjela

i na e-mail će dobiti obavijest o uspješnoj narudžbi.

CorvusPay - obavijest o uspješnoj narudžbi
CorvusPay – obavijest o uspješnoj narudžbi

Druga krajnja točka, '/corvusPaySuccess' , prihvaća odgovor od Corvusa kada je plaćanje uspješno provedeno.

CorvusPay - uspješno plaćanje

Treća krajnja točka, '/corvusPayCancel' , prihvaća odgovor od Corvusa kada je plaćanje neuspješno ili otkazano.

CorvusPay - neuspjelo plaćanje

DevExtreme Pivot Grid & Angular: prikaz i analiza višedimenzionalnih podataka

U ovom ću blog postu pokazati kako implementirati DevExtreme Pivot Grid UI komponentu u Angular projekt. Ona omogućava prikaz i analizu višedimenzionalnih podataka iz lokalne pohrane ili OLAP kocke.

Fokusirat ću se na prikaz podataka prema specifičnim parameterima te načinu na koji te podatke uređivati jer Pivot Grid nativno ne nudi takvu mogućnost.

Pivot Grid prikaz podataka

Prva i osnovna značajka Pivot Grida je prikaz i analizu višedimenzionalnih podataka.

U ovom ću primjeru koristiti strukturu podataka prikazanu u JSON-u kojega je moguće vidjeti ispod. S jedne strane biti će poslovnice, a s druge automobili. Cilj je prikazati količinu naručenih tj. isporučenih automobila ovisno o poslovnici.

Logika aplikacije nalazit će se unutar angular-devextreme.component.ts datoteke koja se temelji na PivotGridDataSource objektu. Za sada će se unutar njega nalaziti samo fields niz i store objekt.

Poslovnice će se nalaziti krajnje lijevo area: "row", a automobili na vrhu area: "column". Sve ostalo tj. narudžbe prikazuju se kao podaci area: "data".

Izgled sučelja biti će definiran unutar angular-devextreme.component.html datoteke.

Od Pivot Grid UI svojstva koristit ću ih nekoliko:

  • showBorders – želim da vanjski rubovi budu vidljivi.
  • showColumnGrandTotals – ne želim prikazivati ukupne vrijednosti za kolone. Ovo bi se inače prikazivalo krajnje desno.
  • showRowGrandTotals – želim na dnu prikazati ukupne vrijednosti.
  • Sve to zajedno na kraju daje sljedeće:

    DevExtreme Pivot Grid - osnovni prikaz

    Pivot Grid – promjena izgleda polja

    Ako želim dodatno prilagoditi prikaz određenih polja to mogu napraviti koristeći onCellPrepared metodu.

    U ovom slučaju hoću napraviti tri grafičke izmjene. Stupac “Naručeno” će imati sivu pozadinsku boju i podebljane brojeve, ukupne vrijednosti na dnu također će biti podebljanje, a vrijednosti koje za “Isporučeno” imaju null će imati crvenu pozadinsku boju kako bi bila uočljivija.

    Na ekranu bi to izgledalo ovako:

    Pivot Grid onCellPrepared

    Međutim, niti jedno polje nema crvenu pozadinsku boju. Razlog je što Pivot Grid sve null vrijednosti vidi kao 0 i zato uvjet e.cell.value === null nije zadovoljen. Ali ako stavim e.cell.value === 0 stanje će biti puno drugačije.

    Pivot Grid onCellPrepared

    Iz podaciDemo niza se može vidjeti da narudzba_isporucenakolicina može imati vrijednosti null. To znači da bi vrijednost za “POSLOVNICA VK” i automobil “Fiat Panda” trebala imati crvenu pozadinsku boju jer je narudzba_isporucenakolicina = null, a kombinacija POSLOVNICA VK” i “Kia Rio” ne bi trebala imati crvenu pozadinsku boju jer ima vrijednost narudzba_isporucenakolicina = 0.

    Pivot Grid – prikaz null vrijednosti

    Kako bi u PivotGridu mogao prikazati null vrijednosti i razlikovati ih od vrijednosti 0 koristiti ću calculateCustomSummary funkciju. Tu ću funkciju vezati uz polje dataField: "narudzba_isporucenakolicina".

    Sada se na ekranu može vidjeti da istovremeno imam prikazane vrijednosti za isporučenu količinu i kao null i kao 0.

    Pivot Grid calculateCustomSummary

    Omogućiti klik na odabrano polje

    Želim omogućiti klik samo na polje koje pokazuje isporučenu količinu, ali isključivo za poslovnice i automobile koji imaju unesenu naručenu količinu. Znači, ne želim da se u koloni sa isporučenom količinom može kliknuti na prazno polje jer nema smisla unositi isporučenu količinu ako ništa nije naručeno.

    Za to ću koristiti onCellClick funkciju.

    Iz prikazanog se može vidjeti da klik na prazno polje ne radi ništa, klik na crveno polje dohvaća vrijednost null, a klik na polje za unesenom količinom dohvaća tu vrijednost. U ovom slučaju ta vrijednost je 10.

    Pivot Grid onCellClick

    Pivot Grid dohvaćanje vrijednosti polja

    Pivot Grid je primarno kreiran s ciljem prikaza podataka tj. prema dokumentaciji nema mogućnost jednostavnog uređivanja podataka kao što je to slučaj kod Data Grida, barem ju nisam našao, ali sam znao da mora postojati neko rješenje.

    Za početak želim prikazati nekakvu formu unutar koje će se vrijednost polja moći urediti. Za to ću iskoristiti Popup UI komponentu. Unutar nje definiram dxTemplate što mi omogućava daljnju prilagodbu sučelja za uređivanje isporučene vrijednosti.

    Za dohvaćanje vrijednosti kliknutog polja koristit ću Drill Down.

    Klikom na polje isporučene količine prikazat će se sljedeće:

    PivotGrid DxPopup DrillDown

    Kao što se iz prikazanog može vidjeti dohvaćeni su podaci prikazani na vrhu blog posta.

    Pivot Grid uređivanje vrijednosti polja

    Popup iz gornjeg primjera je potrebno prilagoditi na način da se kreira input polje za izmjenu isporučene količine. Klikom na polje sa već unesenom isporučenom količinom ista će se prikazati unutar input polja. Ako je polje prazno isto će biti i input polje.

    U GIF-u se može primjetiti da uređivanje isporučene količine uredno prolazi, ali uz jedan problem. Prilikom svakog spremanja isporučene količine cijeli se Pivot Grid osvježi i vrati u krajnju lijevu poziciju. Naravno da to nije praktično. Uz to, prilikom otvaranja popupa polje za unos količine nije fokusirano (crvena podcrtana linija) nego je na njega prvo potrebno kliknuti.

    U nastavku ću pokazati kako riješiti oba problema.

    Pivot Grid uređivanje

    Osvježavanje samo uređenog podatka

    Jedan od problema koji se stvorio nakon što je omogućeno uređivanje podataka je to što se sada cijeli ekran osvježi i onda se svaki put iznova mora skrolati do točno određenog polja kako bi se nastavilo uređivanje. To nikako nije praktično i bilo je potrebno pronaći rješenje.

    U ovom će mi slučaju pomoći ArrayStore, ali tek kada prilagodim prikaziNarudzbe() funkciju. Kao što se može vidjeti this.podaciDemo se sada dohvaćaju upravo kroz ArrayStore. Kroz key parametar identificiram unikatnu vrijednost pomoću koje Pivot Grid može znati koju vrijednost će osvježiti.

    Podatke nakon unosa osvježavam pomoću update(key, values) metode unutar funkcija spremiKolicinuButton() i spremiKolicinuEnter().

    Uz to, kada se popup otvori polje za unos isporučene količine nije fokusirano i prije unosa potrebno je na njega kliknuti. To također nije praktično. Ovo se vrlo lako riješi kroz onShown funkciju.

    Na kraju to izgleda ovako:

    PivotGrid Reload

    Zaključak

    Naravno, ovo je samo dio mogućnosti koje DevExtreme Pivot Grid ima, ali dovoljno da pohvatate osnove i shvatite na koji način funkcionira.