Component develop tricky problem (JS)

Pozdrav,

evo jednog tricky pitanja, pa ponudite mišljenje …solucije …kako vi vidite rješenje problema.

Problem je sljedeći:
Pero Perić je web developer i razvija komponentu/modul koja će slušati response ajaxa, te će prepoznati da li u server odgovoru postoje poruke koje se trebaju prikazati korisniku. Ako postoje, prikazat će ih.
Pero je komponentu nazvao “serverListener”

(Da ne bude pomutnje sa nebitnim, server response zna da postoji komponenta serverListener na client strani…i oni imaju međusobno usklađeno kako su formatirane poruke unutar response-a)

Pero perić s toga nema puno posla…treba detektirati poruku u ajax responseu i prikazat je korisniku ako ista postoji.
No Pero ima jedan mali problem, s čime prikazati poruku?
On naime ne razvija modul samo za sebe…nego bi on htio da bilo koji developer može koristiti njegov modul na svojoj stranici na što jednostavniji način. (plug and play).

Pero tako postaje poprilično ograničen, jer je jedino siguran da svaka stranica podržava alert() metodu, a svjestan je da je alert “izumro” još davnih dana. Stoga bi on radije koristio neki moderan modal/dialog …ali tu je ograničen, jer ne želi “zagaditi” tuđe stranice sa svojom modal komponentom…koja povlači dependecy od raznih css-a do raznih JS librirya…(Pero naime pretpostavlja da drugi developeri već koriste neki modal)

Nadalje, Pero je svjestan da se njegov modal najvjerovatnije razlikuje u user-experience od modal komponente koju već koristi developer koji će koristiti njegovu serverListener komponentu, te ne vidi smisla da useri gledaju malo u jedan modal …malo u drugi. (A to naravno ne želi niti jedan developer koji drži do svog rada)

Pero vidi kao opciju da radi svoju komponentu unutar nekog gotovog frameworka koji već ima modal …ali i to mu je glupo, jer je onda ograničen da njegovu komponentu koriste samo developeri koji koriste taj framework. A to je daleko od globalnog plug and play.

To bi također značilo da će Pero napraviti svoju komponentu unutar frameworka A, a Ivo će napraviti neku svoju komponentu unutar frameworka B …i na kraju završavamo s time da svaka popularna komponenta mora biti napravljena unutar svakog popularnog frameworka. A to je puuuuuuno bačenog vremena zajednice koje je moglo biti utrošeno produktivnije. A stvari trenutno upravo tako izgledaju… podjela posla gotovo nikakava, svi rade sve.

S druge strane, Ivo radi uber moderan i napredan modal kakav ne postoji još niti u jednom frameworku. Njegov modal ima sučelje koje se otvara na desni klik gdje user može prilagoditi neke funkcije modala prema osobnim željama. Ništa komplicirano, osim jedne sitnice…za prikaz tog sučelja Ivi treba “dropdown” komponenta. Sitnica, ali niti Ivo nema pojma kako će njegov uber napredni modal biti kompatibilan drugim developerima…jer on nema blage ideje koji dropdown da koristi kako bi drugi developeri mogli koristiti njegov modal…bez da se susretnu s istim problemom koji ima i Pero.

Itd…itd. danas svaka komponenta zavisi od mnogo drugih komponenta.
Gornji primjeri su slikoviti pokušaj dočarati kako nas ta zavisnost ograničava da se fokusiramo na izradu točno specifične komponente…koja će rješavati točno specifičan problem…a da komponenta bude globalno jednostavno primjenjiva po principu “plug and play”.

Kakvo je vaše mišljenje na temu? Njušite soluciju problema ili niti ne vidite problem?

Ti kao autor komponente ne trebas uopste brinuti o vizuelnom prikazu odnosno nacinu ispisa poruke.Drugi developer treba imati na volju da li zeli to prikazati u bootstrap modalu, klasicnom alertu ili necemu desetom.

Znaci idealno bi bilo da tvoja komponenta ima neki API, koji krajnji korisnik (drugi developer) moze na sto jednostavniji nacin integrirati i prilagoditi izgledu kakvom on zeli.

2 Likeova

Ne vidim problem… Ti trebas napravit js componentu koja radi jednu stvar, dohvaca response s servera i vrati i nekakav data.
Onda ce drugi programer pozvati tvoju komponentu ovako ( bez obzira na framework):

var ajaxResponse = perinaKomponenta.getResponse(possibleData);

Ukoliko zelis vratiti datu kao HTML onda moras i takav API na komponenti slozit ( po mogucnosti s mogucnoscu modifikacije samog prikaza isto preko API-a). Npr.:

var pk = new perinaKomponenta();
pk.setHeaderClass('header-class);
pk.setBodyClass('body-class');
pk.getAsHtml(someData);
// ili nesto u tom stilu...

Yup, quite right.

Ivo treba da postavi Perinu komponentu u require dependencies ukol’ko se slaže sa licencom Perinog paketa.

@belmin @krcmar @tpojka

Bojim se da taj pristup funkcionira samo u jednostavnim slučajevima. Kada je zavisnost među komponentama malo dublja i kompleksnija, onda su stvari gotovo neraspetljive ili u najboljem slučaju: teško raspetljive.

Dalje, to više nije pristup plug and play. …jer koliko različitih izlaza ima Perina komponenta (ajmo reći, različitih metoda ponašanja koje zavise od drugih komponenti) …toliko onaj koji ugrađuje komponentu mora preštrikavati (konfigurirati) izlaze da ih uskladi sa svojim komponentama.

Što ako taj serverListener nudi vrste poruka koje su:

  1. neke će se prikazati u modalu, a modal će pri tome nuditi korisniku opciju: “Shvatio sam, ne prikazuj više ovu poruku”
  2. neki modal nakon što prikaže poruku se ne može više ugasiti, osim na gumb “Shvaćam”.
  3. neki modal je easy poruka, pa se može gasiti na gumb x ili na sjenu oko modala
    …itd …itd.

…puno je to logike koja se može stvoriti, i koju bi onda morao krojiti developer koji ugrađuje serverListener komponentu. Problem naravno može biti i takve vrste da modal koji koristi taj developer ne podržava opciju iz točke jedan: “Shvatio sam, ne prikazuj više ovu poruku”

Naravno, ja sam za primjer uzeo nešto najjednostavnije što sam mogao smisliti…u praksi interakcija među komponentama može ići poprilično složeno…i onda takvo štrikanje da se komponente usklade bi bilo daleeeko od “plug and play”.

Što ako Perina komponenta kroz modal dohvaća dropdown koji se pojavljuje u modalu? Koliko bi sada trebalo konfiguracije da se oni međusobno match-aju?

Velim, na jednoj dubini interakcije to postaje ne moguće za izvesti. …na toj nekoj dubini interakcije je razvoj današnje tehnologije stao. (Što se tiče miksanja komponenti)

Razmisljas krivo. Perina komponenta treba imati jednu funkciju, tj. raditi sto manje stvari. Perina komponenta dohvaca ajax podatke. Moze vratiti js objekt ili nekakav jednostavni html ako bas treba. Perinu komponentu onda mozes za potrebe svojestranice ugradit u sljedecu komponentu koja ce vratiti kompleksniji html koji ce mozda biti pogodan za angular aplikacije, ili modal ili nest trece. Netko drugi ce komponentu ugraditi u sidebar widget i tamo prikazati podatke. Nacin na koji ti pristupas ovome rezultirat ce spageti kodom.

To da komponenta radi jednu stvar (ili što manje stvari) …ajmo to nazvati da su takve komponente jednodimenzionalne.

Sada bi se moj upit s početka priče mogao reći na sljedeći kraći način:

Kako napraviti višedimenzionalne komponente, a da ne dolaze u konflikt sa postojećim komponentama…i da ih maksimalno iskorištavaju.

Prema tome, tvoj odgovor na moj upit glasi:

Nemoj raditi višedimenzionalne komponente, mogu se raditi samo jednodimenzionalne komponente…jer u suprotnome ne valja.

No ako ja inzistiram na višedimenzionalnim komponentama …onda rasprava odlazi u drugom smjeru…a to je:

Mogu li postojati višedimenzionalne komponente ili smo ograničeni sa jednodimenzionalnim?

Ja dalje ostajem pri svome da mogu postojati višedimenzionalne komponente i upravo vidim problem današnjice što smo ograničeni na jednodimenzionalne…jer kao što i sam kažeš, pokušaj dostizanja višedimenzionalnih završi u kaosu, špageta kodu. …nekompatibilnosti itd.

Ostajem pri svom pitanju: “Kako omogućiti višedimenzionalne komponente?”

Tvoj odgovor pri tome da je to ne moguće/ ne isplativo raditi višedimenzionalne …smatram da je to samo bjeg ka jednodimenzionalnim iz razloga što ne znamo način za višedimenzionalne.

Prednosti višedimenzionalnih su očite…zamisli jednostavnom instalacijom (plug and play) bez puno konfiguracije da se dobije jedna široka paleta funkcionalnosti. Nebo bi bila granica kakva bi nam se tada sve funkcionalnost ponudila gotova na slobodnom tržištu.

Nadalje, komponente sa širokom paletom funkcionalsnosti kada bi se mogle ukrižati sa drugim komponentama široke palete funkcionalnosti…rezultiralo bi takoreć sa cijelim malim svemirom kojeg možemo dobiti po principu “plug and play” da ga uključimo na našu stranicu.
To već na nekoj razini možemo nazvati da su plugin-ovi …kao što u WP recimo instaliraš plugin i dobiješ hrpetinu funkcionalnosti od njega…a ne tamo neki jednodimenzionalni parser iz responsa u HTML poruku.

Zašto bi se onda u kodiranju ograničili da nam komponente obavljaju neki usko definiran zadatak…mislim da je jedino bitno da nam obavljaju zadatak za koji su namjenjene. Koliko god taj zadatak bio kompleksan i dubok…

Sa svakim postom ove teme Perina komponenta dobija na funkcionalnosti.
Da bi se pravilno odgovorilo na pitanja trebalo bi znati šta ona tačno radi (ne insistiram već je nemoguće odgovoriti, a da odgovor ne bude apstraktan, na poprilično apstraktno pitanje).

Pa teoretski komponente mogu biti visedimenzionalne, ali onda ce uvjek biti ogranicene u okviru vlastite implementacije. Tj. recimo da perina komponenta otvara modal. Perina komponenta ce onda otvoriti svoj modal, sa svojim html-om i css-om. To ce mozda biti ok nekome, a nekome nece biti ok.
Fora svih tih komponenti je bas u tome da rade sto manje, ali opet s druge strane da obavljaju odredjenu funkciju bez da implementator mora previse kodirati.
Kako odabrati okvir djelovanja, tj. granicu na kojoj ce se komponenta zaustaviti je nesto sto programer mora odluciti s obzirom na to gdje planira da se komponenta koristi.
Moja preoruka je da uvjek sljedis unix-ovu filozofiju “Do one thing but do it good”. Ali ako ti je cilj napraviti komponentu koja ce imati mogucnost da se otvara u modalu, widhetu i negdje u tekstu, oda ti je moja preporuka da napravis dobar API s kojim ce drugi programer moci modificirati tvoj output prema svojim potrebama.
Ali imaj na umu sljedece. Napisao si da hoces da visedimenzionalne komponente budu sto vise plug&play. To znaci da lopticu kompleksnosti preuzimas ti, tj. jednostavnost primjene je dobro maskirana unutarnja kompleksnost. A to pak znaci da ces si kicmu polomit da bi napravio takvu komponentu.

Evo malo kompleksnijeg zahtjeva kojeg treba riješiti Perina komponenta:

Perina komponenta mora prepoznati postoji li u server responsu anketno pitanje korisniku. Ako postoji, treba korisniku postaviti to pitanje sa mogućim ponuđenim odgovorima. (Neka to bude dropdown putem kojega će korisnik odabrati odgovor)

(Server response i komponenta su opet naravno usklađeni…to je zapravo jedini API koji developer mora ispoštivati da bi koristio perinu komponentu)

Kako korisnik odgovori, odgovor se opet prosljeđuje na server sa ajax-om na zadani controler.

Zahtjevi i uvjeti:
Pero:

  1. Nema pojma kako stranica uopće implementira ajax komunikaciju. Nema pojma koristi li se jQuery ili kako već
  2. Nema pojma koji modal se koristi koji bi to pitanje mogao interpetirati korisniku
  3. Nema pojma koji dropdown se koristi putem kojega Pero želi ponuditi moguće odgovore korisniku

Pero želi da je njegova komponenta ugradiva doslovice untuar jedne jednostavne linije koda.
Developer koji ugrađuje Perinu komponentu, želi također ugraditi na što jednostavniji način Perinu komponentu.
Developer želi da dropdown kojeg će Perina komponenta koristiti izgleda identično njegovom. …također želi da modal koji će prikazati Perino anketno pitanje izgleda identično njegovom.
Developer znači vjeruje tvorcu komponente da je napravio dobar posao…ako je tvorac komponente birao modal, developer se nema tu što buniti. Developer jedino želi da komponente koje koristi Pero budu iste one koje on ima na stranici.

Ukoliko Pero jednog dana updejta svoju komponentu, te nakon toga updejta napravi da ista komponenta komunicira na neki elegantniji način sa korisnikom. Recimo Pero skuži da je dropdown bio seljačko rješenje…i odluči se na neku bolju inovativniju varijantu…
…onaj koji je ugradio Perinu komponentu, ako istu updejta …ne želi da mora mijenjati svoju logiku. Samo želi vidjeti kako je sada Perina komponenta bolja i modernija i ima bolji user-experience.

To su zahtjevi, da bude najbolje od najboljeg. :slight_smile: …sve ostalo vidim kao kompromis da se napravi drugačije jer se zahtjev nije mogao ispuniti.

Uvijet zadatka je da se tako ne smije pristupiti rješenju.
Gradnja po tom principu nebi bila skalabilna…znači ništa od svemir-komponente po tom principu.

Pa otvorio sam temu jer smatram da postoji elegantno rješenje. No da sam krenuo pisati rješenje…nebi me nitko shvatio. (Probao već tim putem i ostao neshvaćen …ne vjerujem da iz razloga što je rješenje kompleksno, prije bi rekao da ljudi nisu skužili koji problem rješavam)

Zato sam krenuo do problema, da se prvo zamisle oni koji čitaju i osvjeste problema…a onda ću dati soluciju.

Neznam iskreno kako bi ti znao kako izgleda dropdown od usera. Jedini siguran nacin je da on tebi preko api-ja da dropdown ili css. Drugacije ne ide na siguran nacin. Mozes ti trazit po css-u kod za button ili dropdown, ali pitaj boga da li je implementiran tako ili se koristi zasebna klasa ili ne.

Dat cu ti dva primjera koji ce ti nadam se demonstrirati da je to nemoguce nataj nacin napraviti.

  1. Google adsense. Da je moguce to napraviti tako kako ti kazes onda te google ne bi ni trazio da podesis izgled reklame, vec bi sam narihtao da reklama izgleda kao tvoja nativna komponenta.
  2. Wordpress. Wordpress te trazi globalne css stilove koje onda pluginovi mogu koristiti da izgledaju maksimalno u skladu s postojecom temom.
    Ako bi tvoj pristup bio moguc, onda bi vec netko od ovih giganta to rijesio.

Gle, uvodni post je dao ideju Perine komponente i Ivine komponente. Ta dva primjera tek ukazuju na problematiku.

Naravno da stvar nije ograničena niti sa funkcionalnošću Perine komponente…ni sa funkcionalnošću Ivine komponente.

Nego su oni tu da ukažu da treba postojati mogućnost usložavanja komponenti, koje se ne baziraju nužno na istim frameworcima…čak niti na istim tehnologijama. Dok god pričamo o JS kao fundementalnom dnu tehnologije na kojem te komponente nastaju.

Iako bi ista stvar vrijedila i za bilo koje druge programske jezike koji imaju zajedničko dno iz kojega su evoluirali…no zasad se držimo Javascripta.

E sad, ako imalo možemo apstraktirati što bi sve jedna komponenta mogla raditi unutar potpouno funkcionalne web stranice, onda je poprilično nespretno reći : “Hej, zašto Perina komponenta nebi radila samo to i to …da bi problem bio rješiv.”

Perina komponenta je samo znači simbolika…na svakome je da zamisli što težu i kompleksniju komponentu, koja mora komunicirati sa hrpetinom drugih komponenti.
Kojih?
Pa valjda ste čačkali malo po web stranicama, pošto ste developeri, … i primjetili da sve te stranice posjeduju uglavnom komponente iz nekog zajedničkog skupa komponenti.
E sad, ako bi sumirali sve stranice ovog svjeta dobili bi jedan vrlo konačan zajednički skup komponenti!
To bi mogli reći da je zadnja-stopa današnjeg razvoja komponetni…i to će svakako u budućnosti dalje rasti. No brojka je svakako trenutno konačna.
Treba primjetiti da unutar te konačnosti ima jako puno redundacije. A to su iste komponente (znači ista im je svrha) … a pojavljuju se pod različtiim imenom…i vrlo često različitom tehnologijom pravljene. (No dno je JS uvijek)

E sad, te iste komponente (nikada nisu u potpunosti iste) …ali imaju jedan veliki zajednički skup funkcionalnosti i to ih kategorizira kao iste. Unatoč različitim imenima…unatoč što im se i metode nazivaju različitim imenima.

Hoće li netko metodu nazvati .open() ili .show() …moramo biti svjesni da je to ista metoda…koja je u svojoj svrhovitosti ista stvar.

Nadalje, moramo biti svjesni da je to ista metoda pojavljivala se ona na modal-u ili na title-u. Znači, međusobno različite komponente također mogu dijeliti iste metode.

Uglavnom, pitanje je…kako napraviti komponentu koja će dobro funkcionirati sa tim morem komponenti? A da sami sebi ne postavljamo granicu u jednostavnosti te komponente…nebi li tako napravili realizaciju mogućom.

Evo jedan hint:
Kada instaliramo neku aplikaciju na mobitel …to je doslovice komponenta. (Sada nikako ne stoji ona priča da komponenta može raditi samo neku jednostavnu stvar …jer eto, cijeli app može biti komponenta koja će “usisati” komponente od androdida i sa njima uspješno surađivati. U ovom slučaju nema developera koji će tu išta konfigurairti…onaj koji konfiguira je doslovice korisnik tog mobitela.
I jedno od najbitnijih konfiguracija je zapravo koje permissione ćemo dati toj komponenti…hoće li ona smjeti koristiti komponentu “galeriju slika” , hoće li smjeti koristiti komponentu “telefonski imenik” itd.

Tako i u ovoj priči…Pero će sve napraviti što će raditi njegova komponenta…a developer koji će ju koristiti, jedino što će trebati Perinoj komponenti jeste dopustiti da koristi njegovu komponentu “modal”.

Jer kada nebi bilo tako, Perina komponenta bi jednog dana mogla samostalno odlučiti koristiti komponentu “email-sender” …i putem naše web stranice spamati u vlastite potrebe.

Možda sam malo jasniji sa zahtjevima barem? :slight_smile:

Ovo obožavam. :smiley: Ovom logikom nikada ništa novo nebi došlo…jer takva pretpostavka uzima da je ne moguće nečeg novog se sjetiti, jer se netko toga već morao sjetiti. (a po tebi…već i realizirati)

A gle, nije mi prvi puta da kada mislim o nečemu…da nekako paralelno ista stvar negdje nastaje u svijetu.
Ali to je zato što su ideje u cloudu. :smiley: …mi se samo trkamo tko će ih prvi realizirati i tako dobiti nagradicu svemira.

Uopće ne sumnjam da ovo što ću u konačnici napisati…da će biti prije ili kasnije realizirano. Znači, sumnja gotovo 0%.

Jedini problem je što ja osobno nisam dovoljno velik igrač da bi to mogao pokrenuti …tako da će nagradicu uzeti netko drugi. No, ono što ja mogu učiniti…to i činim. Piskaram tako po forumu…a u svojim projektima već koristim takav pristup. Doduše, tek radim to površno…ali i ta površnost mi je već prošilira obzore da vidim što ću i kako trebati kada se ozbiljno s tim uhvatim.
A i ne radim to zbog ičega drugoga, nikakva drugačija nagrada mi nije potrebna, samo želim povećati vlastitu produktivnost.

Uglavnom, gotovo sam siguran da je moguće …i bez brige, dijelim uskoro ideju :smiley:

Ok, moram priznati da sam se malo izgubio.
Mislio sam da kuzim, ali ne kuzim ili ti mene ne kuzis.

Ono kaj ti ja hocu reci je da ako kompnenta zadire u prikaz, onda mora ili imati api koji ce dozvolti konfiguriranje pojedinih djelova ili ce koristiti svoj css te ce si time ograniciti user base.

Sto se tice ovih stvari da moramo i dalje raditi makar veliki igraci nisu nasli rjesenje, naravno, tko ima vremena neka dela i istrazuje :slight_smile:, ali mislim da je to dovoljno velika stvar te da postoji nekakvo rjesenje, bilo bi rjeseno.

Morat ces dat nekakav konkretniji primjer da skuzim kaj hoces reci.

Ja stvarno nemam pojma je l’ ovo treba da zamisli Pero il’ Ivo iz primjera.
Problem ovde je što Pero (da bi znao šta i kako treba napraviti) mora znati šta je Ivo već napravio.
Zato postoje odredjene nomenklature poput Twitter Bootstrap-a, Zurb Fundation-a, Bulma-e, Materials-a etc.
Sa ovim da radi na svakom custom made frontend(/backend)-u good luck with that.
Ovde su u pitanju dvije komponente modal i API.
Pristup bi bio da Pero napravi integraciju za svaki od ovih fw-a a ostavi good ol’ alert k’o fallback varijantu.
Ali zašto bi neko uzim’o bloatware za n framework-a ako mu treba samo za Tw Bootstrap.
Mada se ja zadržavam na backend dijelu “Here is your JSON, Sir!” - tu se radi o nekoj vrsti ankete recimo.
I taj dio nema pretjerano puno veze sa JS-om. Taj dio treba da isporuči JSON koji može biti čitan od 95% programskih jezika. Da li će modal da koristi podatke iz JSON-a ili hard-coded je sasvim druga stvar kad se priča o izgledu modala. Ja to tako vidim.

Ovo me jako podsjeća na nešto. Dali si ikada probao angular CLI + PrimeNG recimo? To mi nekako izgleda opisom ono što želiš. Komponente koje su gotove, možeš ih koristiti, a i sam izrađivati.

Držim da se treba opredijeliti i slijediti programerske trendove koji rastu poput ovih, umjesto pokušati globalizirati sve

1 Like

Ok, valjda sam nespretno napisao.
Na vama je da zamislite što težu i kompleksniju komponentu koja bi mogla rješavati neki problem/zadatak s kojim se susreću web stranice. To znači nema ograničenja u dubini…mašta je granica.
Evo, hipotetski, neka danas-sutra bude komponenta tipa “voice web builder” …da korisnik priča u web stranicu…a kako joj on opisuje što da nastaje, tako se ispred njega stvara web stranica. Znači korisnik kaže: “Evo, tu ispod ovog zelenog gumba mi stavi dropdown, sa opcijama …” …i ono se pred njim stvori dropdown.

Ovo je sada visoka apstrakcija…ali hoće reći da nismo mi ti koji ćemo ograničavati što bi koja komponenta sve mogla raditi…mašta je granica. Perina i Ivina komponenta su bile tu samo da na što jednostavniji način dočaraju gdje je problem kod interakcije među različitim komponentama.
Problem naravno nećemo rještii na način da ograničimo da su komponente jednodimenzionalne…jer onda nikavka šansa da jednog dana “voice web builder” može kreirati stranicu točno u štihu u kojem je kompatibilna sa nekom drugom web stranicom. (Da im komponente budu sukladne…tako da se ne skuži da je jedna rađena ručno, a druga po istom kroju napravljena sa voice web builderom)

Točno tako, tu leži problem. No rješenje problema postoji!

To sam već spomenuo u uvodnom postu da je to jedan veliki gubitak vremena…koji trenutno zagušuje cijeli razvoj. Jer upravo se to dešava…svaki framework ima sve popularne komponente…

Poanta je da developer niti ne razmišlja hoće li to biti modal ili neki drugi način…tj. prepušta to komponenti dok god komponenta odrađuje zadatak za koji je namjenjena. To je jedino što zanima developera:

  1. imam problem
  2. Perina komponenta mi rješava problem
  3. Može, rješeno.
  4. Ako Perina komponenta nudi opciju developeru neku konfiguraciju da odabere hoće li se to odraditi ovak ili onak…super, to je onda dodatni feature komponente. Ali u startu polazimo od toga da developer ne mora raditi nikakvu veću implementaciju od koraka: install Perina komponenta + daj permissione komponenti
    Nikakvu logiku ne implementira developer, on je samo korisnik Perine komponente…kao što je korisnik mobitela korisnik aplikacije koju instalira na mobitel.
    Ako radi ikakvu konfiguraciju, to je samo iz razloga što mu je komponenta dala mogućnost odabira: “Hoćeš li ovako ili ćeš ovako?”

Sada više ne stignem gledati…ali budem. Njušim da se u tom pristupu krije odgovor na moje pitanje! :wink:

Do ovog aktera nismo ni stigli u temi. Da podsjetim komparacije u analogiji radi, to je onaj s početka posta što je vizitor Ivinog sajta a da ga se nismo ni dotakli u priči.
Ali pazi sad, zato Ivo mora po striktno zadanim pravilima da implementira vlastita rješenja koja bi mogla biti integrisana u mob. Dakle, ni lijevo ni desno, već postoji samo jedna komanda za škljocanje foto-aparatom. Samo jedna komanda za filter/listing imenika itd, itsl. Tu Ivo nema nikakvu slobodu već se mora povinovati zahtjevima OS-a. Slično ovde, ako želiš besprijekoran izgled, za Twitter Bootstrap ćeš koristiti klase twb-a jer ako koristiš bilo šta drugo nemaš twb izgled. E fora je u tome što moraš znati sve klase custom CSS-a što ti je @krcmar već pomen’o - mor’o bi imati sve njihove stilove. Pomen’o si open() i show() koji su da kažemo identične funkcionalnosti (mada uopšte ni ne moraju biti). A šta da se radi sa nazivima varijabli, metoda i CSS klasa i id-jeva koji nose isto ime ali potpuno druge stvari rade. Kako bi se komponenta izborila sa tim realnim problemom?

Ti ovde imaš jednu jednačinu sa dvije nepoznate što je po pravilu nemoguće riješiti. Može imati bezbroj rješenja ali to nije efikasno sa stanovišta da se posjeduje samo jedan život, jbg.

Ono što znam 101% je da se ništa ne može napraviti/popraviti (kako valja/treba) dok problem nije precizno definisan.