Pozdrav,
Imam jedan zahtjevan zadatak kojeg proucavam.
Trebam napraviti ispis ponude iz browsera, javascript. Dakle trebam popuniti tablicu dobivenim objektom i poslati ju na print.
Mora biti lijepo i profesionalno. Moze biti neki vanjski javascript library iako sam istrazivao, a nisam nasao nista jednostavno.
Ima tko prijedlog na koji nacin da to napravim.
može biti i HTML to PDF nešto pa prilagodim.
Iskoristi @media print i @page u css-u. Podesi i margine u tim pravilima za ispis (da se na ispisu ne prikazuje footer i header od browsera poput url-a, vremena kad je ispisano, naslova stranice…)
Ne znam što te konkretno muči pa ti nemrem dat još info 
htio bih napraviti zaglavlje gdje je logo i neke informacije, i muči me ako je tablica duža od A4 kako da ju lijepo oblikuje na više papira.
Mislim da ću za print morati napraviti poseban layout koji prvo trebam pokazati korisniku pa da on stisne print? Ideja je bila da korisnik stranice ne vidi uopće ponudu nego da u layoutu koji ima u svom korisničkom sučelju stisne print i da povućem podatke koje je odabrao i smjestim ih u drugačiji layout i pošaljem na printer.
Nisam htio da korisnik nužno vidi layout ponude na ekranu.
Čuo sam za @media print ali nisam siguran kako točno funkcionira, nisam ga još koristio. Idem potražiti dokumentaciju da vidim kako funkcionira. Pitam se dali postoji neki prikaz (kroz dev toolse u mozili ili cromeu) u kojem mogu vidjeti kako će izgledati završni papir kada se koristi @media print.
Nemožeš izbjeći da korisnik vidi layout prije ispisa. Prilikom ispisa browser poziva ispis od operativnog sistema, a ti preko web-a i skripte na web stranici ne možeš to izbjeći (ako bi i mogao - pronašao bi sigurnosnu ‘rupu’).
Ja sam to riješio tako da imam zaseban file za ispis (npr, ponuda se unosi na stranici ponuda.php, pa kada na toj stranici klikne gumb “Ispis” otvara se stranica ispis-ponude.php, gdje su elementi poslagani za ispis i u kojoj pozivam css za prikaz elemenata i dodatni css u kojem se nalaze @media pravila).
Generalno ti to i nije problem. Pravi problem dolazi kada uzmeš u obzir da na ponudi može biti stavaka više nego ih stane na jedan A4 papir, pa trebaš moći nastaviti ispis na drugom listu papira gdje također mora biti header i footer kao i na prvom…
Razumijem načelno logiku kako si objasnio. Ja ću vjerujem napraviti slično, ali ne kroz php nego kroz angular, no to i nije toliko bitno jer u browseru je rezultat isti.
Mislim da će mi ovo stvariati pain in the ass, jer na svakom papiru upravo i trebam postaviti header i footer. Dali si to nekako uspio riješiti?
Nije bitno sa čime radiš, logika je bitna.
Uspio sam napraviti kroz JS i CSS. Ima računanja visine dokumenta, visine headera sa logom i podacima tvrtke i footera, visine div-a u kojem je tablica, i onda “rezanja” te tablice na dva ili više dijelova (mogu biti i 3-4-5 stranica, nikad ne znaš), korištenje page-break u css-u (unutar @media print), malo uštimavanja i to je to. Al moram reć da sam se “istelio” dok nisam riješio. Uglavnom može se.
Jep, tu je kvakica …zato bi ti mogli biti od pomoći alati namjenjeni za to.
Ja sam problem rješavao na beckend strani, i tu mi je pomogao iTextSharp …on ima već evente na sebi poput:
.onStartPage
.onEndPage
…onda se ti pomoću tih evenata lako kačiš na ono što ćeš renderirati na početku svake stranice, ili na kraju. A on računa za tebe gdje će što cjepati i ubacivati.
Ako ćeš raditi sve sam, onda si definitivno moraš složiti svoje evente koji su ti kasnije od pomoći.
Ja sam koristio iTextSharp koji je imao svoju verziju za C#, a nešto mi u sjećanju da je imao i verziju za PHP.
Nego, zašto nebi rješio problem na backend strani?
Kada ga jednom rješiš na beckend strani, onda si možeš napraviti servis koji prima strukturirane podatke prema dogovorenom standardu koji si kreiraš, a ti kao response pucaš natrag posloženi dokument u pdf-u. I onda imaš poprilično univerzalno rješenje da bilo koji set podataka napucaš u PDF i generiraš si izvještaj pogodan za spremanje ili print.
Ovo je naravno ograničeno kompleksnošću potrebnih izvještaja …jer teško ćeš standarizirati ispis za sve varijante layouta koje omogućava HTML, jer HTML jeste upravo taj standard. Ali dok imaš tablične prikaze izvještaja, vrlo lako ćeš uvidjeti da gotovo uvijek iste strukture podataka se trebaju prikazati nekakvim tablicama. (Naravno, ako ti to treba, jer nisam siguran da li želiš bilo koji HTML pretvarati u PDF, ili samo tablične prikaze)
Zapravo, nevjerovatno ako već ne postoji servis koji se requesta sa nekakvim setom podataka, a on vraća pdf dokument kao response. Ako nema, to bi mogao biti pravi proizvod …
Vidi ovo:
https://www.stimulsoft.com/en
Report desinger, a koji podrzava i php.
Kad se kreira report i napravi export, struktura reporta se zapise u json i dobije se parser u js koji cita json i prikazuje report na stranici, onakav, kakav je u desingeru.
Isprobao sam alat i radi super, jedina mana je sto nije besplatan, cijena ide od $700 nadalje, ali vrijedi svakog centa.
Vidi paše li od ovog štogod (svaki od odgovora je anex nekom prethodnom):
Inače, “php js css page break”.
Sory @tpojka, ali danas ozbiljna aplikacija bilo web ili desktop ne može bez reporta, a reporte je najjednostavnije raditi kroz neki desinger i ne moraš se zajebavat sa ničime.
Dizajniraš report, ugradiš u aplikaciju i vozi, a da ne kažem da si brzo gotov s time da imaš i napredne funkcije za reporte od filtera nadalje, pa onda gotov export u pdf, excel itd.
Sad zamisli da moraš dizajnirat preko 100 različitih reporta, kako bi ti bilo jednostavnije i brže?
Dugo sam tražio alat za reporte za php i mislim da ovaj gore je jedan jedini za php , gdje se reporti dizajniraju kroz desinger
<div header>Logo i ostatak</div>
<div table-holder-koji-se-cijepa-na-stranice>
<table>lista artikala ili čega već</table>
</div>
<div footer>Footer dokumenta</div>
Nemre jednostavnije. Jednom kad složiš JS i CSS koristiš ga kroz ostatak dokumenata. Imam tako složene i račune, ponude, primke, liste računa…
Također funkcionira i sa PDF ispisom (u php-u).
Zakaj plaćati nečije djelo umjesto napraviti vlastito rješenje?
Sve super, ali svaki novi račun ili ponuda ili report, header je drukčiji.
Ok, može biti dinamički ispis, tipa, ako je ponuda ili račun i sl., može dinamički header.
A što kad imaš 100 i kusur reporta u app i svaki ima drukčiji header?
Sa report desingerom si brz i jednostavno je bilo što napraviti, ne moraš se zaj. sa dizajnom.
A povrat investicije je jako brz.
Zanimljiva cijena, a sada zamisli koliko ljudi treba takav alat.
Ako stvarno nemaju pravu konkurenciju, zašto im ne postati konkurencija? 
Mislim da sve što se koristi uzduž i poprijeko svijeta, ako ima konkurenciju, onda će konkurenti svesti cijenu takvim alatima na “svega par” dolara.
Jer ako ti je tržište toliko ogromno, onda ćeš i kroz nekoliko dolara po licenci naplatiti uloženo vrijeme u proizvodnju alata.
Stoga, nekako sam mišljenja da svi oni koji prodaju svoje alate po osjetnijim cijenama, da su time potpisali: “Ja nemam konkurenciju.” …i dali jasnu poruku gdje ima prostora progurati se na neko specifično tržište.
Dobra strana firme gdje ćeš možda doći, jeste da su i oni upravo motivirani takvim načinom poslovanja. A imaju dovoljan kapital da odrade marketing i sve ostalo na svjetskoj razini.
Pišem ovo namjerno na glas, da se i @costlyDeveloper -u bubice stvaraju u glavi. Znam da je sada zadovoljan tamo gdje jeste…ali neka se pacaju ideje, sve u svoje vrijeme.
Takav alat trebaju svi koji u svojim aplikacijama imaju reporte, BI, big data itd.
Jednostavno neki desingeri imaju ugradjen skriptni jezik, funkcije itd, sto jos vise olaksava posao. Isto tako filteri, export u pdf, excel itd., sve automatski ugradjeno.
Recimo za .net postoje devexpress komponente koji kostaju u tisucama $, imaju konkurenciju, ali su najbolje. U ponudi firma ima i report desinger.
Ovaj alat ne podrzava ruby on rails,za rails sam gledao da li ima sto slicno, nema.
Ima nekih report generatora, ali gdje sve rucno kucas opcije i sl.
Svaki hotel, kuhinja … trebaju report. Svaki web developer koji je na usluzi hotelima, treba im ponuditi nekakve reporte.
Svakom developeru se neda zahebavati sa time da pravi svoj alat, a ako nema dostupnijih od 700$ …onda prostora ima.
Ja sada pričam malo napamet, stvarno nemam pojma što se sve nudi i za kolike pare. Ali primjetio sam da ovi alati koji omogućavaju kreiranje nekakvog PDF-a, oni zapravo i dalje nisu gotovi proizvod za ovu primjenu.
Gotov proizvod je puno bliže svrsi kojoj je namjenjen. A ovdje je svrha generirati tablične izvještaje za određene strukture podataka. To je ipak dosta specifičnija svrha od all-round mogućnosti kreiranja bilo kakvog PDF-a.
Issati jeste ga zakomplicirali i opet napravili problem ni iz čega
Svaki malo bolji develper napravit će ispis na A4 i export u pdf za max. 2 dana, i to prilagođen svojim potrebama.
Kasnije napravi lib za taj ispis i koristi ga u svojim budućim projektima.
Sve je na tome koliko je desinger praktičan. Ako imaš designer, unutar kojega ti moraš kršiti DRY pravilo ne bi li uvijek iznova dobivao iste stvari. …po meni nije dobar.
Također, ako si formatirao 100 različitih reporta sa nekakvim standarnim paddingom između polja, neka taj padding bude 5px …i ako nisi u mogućnosti na jednom mjestu promjeniti taj padding sa 5px na 10px …opet bi rekao da si poprilično ograničen sa takvim designerom.
Taj problem u ovoj domeni nije lak…ali koliko sam vidio, neki vizualni designeri ga ne rješavaju. (Ali generalno nisam siguran kako pristupaju rješenju problema)
Osobno bih rekao da rješenje problema leži u tome ako standariziraš kakva struktura podataka se slijeva u kakav oblik reporta. Tada, developer treba samo prosljeđivati podatke koje želi prikazati u reportu i birati željeni format da tu strukturu podataka prikaže reportom.
Kako će to konačno vizualno izgledati? Neka ovisi od onoga tko je provider pretvorbe podataka u report.
Ako taj vizualni identitet neće biti dobar, on će uvijek moći evoluirati i postati bolji. Developer tako neće niti primjetiti da ista struktura podataka koju sada napuca u report, da će se odjenom prikazivati u ljepšem reportu, a nuditi informacijski isti smisao onome tko koristi taj report.
Na taj način, svi reporti koji su već ranije postavljeni da se mogu dinamički kreirati…evoluirat će u novi bolji dizajn.
A da su ti raniji reporti oblikovani putem alata, gdje je sve konačno definirano…onda te ranije reporte ne može dotaknuti evolucija, bez da ručno ideš kroz svaki designer i prepravljaš stare reporte na bolji novi dizajn.
Stoga, i u ovoj problematici treba jako biti svjestan DRY koncepta i kako zadržati totalnu kontrolu u rukama na samo jednom mjestu.
Ako vas ovo slučajno podsjeća na normJS, nije slučajno. Jer radi se o identičnom konceptu.
-> prepoznaj svrhu
-> prepoznaj standarni oblik koji može hraniti tu svrhu
-> uvjetuj koji smisao iz toga treba proizaći
Ovo gornje fiksiraj putem standarda, a provider koji će ti rješavati taj problem…neka on evoluira koliko god želi i kako god želi. Ti se onda lako prebacuješ sa jednog providera na drugi i uvijek se služiš onime koji rješava problem na najbolji način.
Totalni DRY.
A može još globalnije. Imati lib za zajednicu…gdje onda nitko neće trošiti ta svoja dva dana. A vrijednost od ta dva dana će se salijevati ka onome tko ti je uštedio ta dva dana.
Pri tome, ono što ćeš ti napraviti u ta dva dana…ne može se mjeriti sa kvalitetom onoga što je nastalo u malo više vremena od ta dva dana i sa malo više mozgova.
Naravno, i ne tvrdim drugačije.