Weblabor

Hát igen, ez már tényleg kifutott technológia ugyanúgy, mint a table, de ettől még nem hibás, csak egyszerűen már nem ajánlott, mert már vannak nála sokkal jobb megoldások.

Az a bajom hogy mindketten (Poetroval) elzárkóztatok a példámtól :-) Többféle regisztrációnál maradjunk.
Mitől lesz hatékonyabb a cég, ha a sitebuilder feladata lesz a megjelenés a projekt végéig? Tehát az én általam használt (Symfony által kreált) formok nem használhatóak. Tehát a templatek generálásáról nem is beszélhetünk. Hogy megy ez nálatok? Pedig általában egy form nem szokott túl bonyolult lenni, csak egy alkalmazásban van vagy 50-100 vagy több.

Az előre gyártott komponensek meg már tényleg betesznek egy zabolátlan sitebuildernek. Azokhoz általában van egy csomó elkészült template is. Most azokat is átírogatja?


Ilyet nem is állított senki. De épp ezért nehéz ezt a sitebuildernek megoldani. De ügye nem azt nehéz megoldani, hogy van egy div, amiben van a label és az input mező és ezt szépen egymás alá leírjuk egy konfigurációs állomány szerint? Szépen jelölve (class, id) hogy mi van benne a divben. Az a form elem szépen formázható. Ezen egyszer és mindenkorra túl lehet tenni magunkat. Mint ahogy azon is, ha ezt egy accordion vagy egy tabos megjelenítéssel csoportosítjuk. Ezt nem kellene minden egyes projektnél külön legyártani. Most teljesen mindegy, hogy a sitebuilder gyárt külön másikat, vagy én készítek külön másik template generálót. Az azért elvárható hogy egy projekten belül a formok legalább hasonlítsanak egymásra a felhasználó szemével.

A javascript sem hiszem hogy mindig rá tartozna. Most vegyünk egy autocompletert. De ne egy egyszerűt, hanem mondjuk töltse ki a teljes formot. Például egy szállodai szoftver, aminél a név kiválasztásakor a törzsvendég/elutazott vendég adatbázisból felkínáljuk a vendég összes adatát. Most nekem egyszerűbb kitennem magát a törzsvendég objektumot a templatebe, ahelyett hogy létrehozok valami tömböt. De nyilván a törzsvendég objektum nem fogja tartalmazni a teljes adatmennyiséget, esetleg lesznek kapcsolt adatok, tehát nekem úgymond a szájába kell rágnom hogy mi micsoda. Egy form sem feltételemül abból áll, hogy elemeket jelenítek meg, hanem lehet hogy az aljában egy log rész van, ahol leírom hogy eddig kik azok, akik módosították a record adatait. Na most oda megint kinyomni a sitebuildernek az adatokat egy tömbben, hiszen a log többnyire tartalmaz kapcsolt adatokat is. Semmivel nem vagyunk előrébb, ha én gyártom le a tömböt, és Ő templatet, ahelyett hogy tömbgyártások helyett mindjárt a templattel foglalkoznék. Ráadásul valami másik nyelven és templatekezelővel (smarty?)?

Tehát a példánál maradva, mit vár a suitebuilder a regisztrációs formnál a backend fejlesztőtől? Szerintem, amire nekem szükségem van, az egyrészt név szerint a tartalom, másrészt amire neki, azok a kapcsolt entitások. Tehát egy tömb valahogy így:
név => Kis Pista
Cim => Budapest
kedvenc szine => 12
És ügye kellene egy másik tömb, a színek:
11 => Sárga
12 => Piros
És mondjuk a cím közé legyen beszúrva a log, az még egy tömb (az első tömbben?):
Név => Admin János
módosítva => 2011-12-31

Mivel a megjelenítésért Ő felel, gondolom hogy sorrendbe is majd Ő rakja a színeket név szerint vagy bármi szerint. Meg nyilván a tömb is általa kerül megfelelő sorrendbe. Én arra vagyok kíváncsi hogy hol nyeri a csapat azt a sok időt, ha mégis Ő csinálja? Én azzal hogy kiteszem ezeket a tömböket már mínuszban vagyok az idővel. de nyilván erre is írhatok egy generátort és akkor ugyanott vagyok. De Ő hol van előrébb? Pláne hogy abból indulunk ki hogy nincs kész templateje, hiszen össze vissza cserélgeti a html elemeket.

Persze tudom hogy hol nyerünk időt. Ott, hogy önmagát nem szívatja meg az állandó változtatásokkal. :-)

De ne legyen sok ilyen kekeckedős kérdés, mert akkor úgy fog látszani mintha vagy pökhendiek lennének a kérdéssor összeállítói (akik a szakmai tudásukat fitogtatják, vagy nagyon gurunak akarnak látszani) vagy inkompetensnek fognak tűnni (akik azt se tudják hogy a fejlesztésben mi a fontos). Egy igényes emberke egy inkompetens kérdéssor esetén meggondolja, hogy esetleg ne ahhoz a céghez jelentkezzen - vagyis a pályáztató a rossz kérdéssorral akár még veszíthet is. (Bár manapság már minden munkalehetőségre ugranak a pályázók)

Ha IDE-vel szerkeszted, akkor kiírja az összes paraméter nevét... Nem értem miért kéne fejből tudnom egy 2 vagy több paraméteres függvény paraméter listáját. Eleve OO szempontjából nem is lenne nagyon szabad ilyeneket megengedni, mert egynél több paraméternél a sorrend már nem egyértelmű. Nem szeretem a PHP-t különösebben pont az ilyen örökségei miatt. A javascript sokkal közelebb áll a szívemhez, a java meg még közelebb...

Javascript-nél netBeans-ben sajnos nem működik a legjobban az automatikus kiegészítés, kíváncsi vagyok, hogy vajon más IDE-kben felajánl e valamit az általad említett esetnél. Ami megint csak érdekes, hogy én string darabolásra javascriptben mindig a slice-ot használom, szóval lazán odaírnám, hogy hibaüzenetet kapok. A substring-et tudtam, hogy létezik, viszont a substr-t azt nem... Szóval ezek alapján engem fel se vennétek :D (Bár lehet, hogy amúgy sem felelek meg a követelményeiteknek...)

Itt már az sem ér semmit, nem tudom görgetni, és kilóg a lista a képből :D

A {1} teljesen felesleges, az az alapértelmezett.