Új hozzászólás Aktív témák
-
syC
addikt
válasz Peter Kiss #13149 üzenetére
Tegyük fel, hogy van ez a php oldalam:
test.php
<form method='post'>
<input name='file' type='file' />
<button>submit</button>
</form>
<?php
if( isset($_POST['file']))
{
$f = fopen($_POST['file'],'r');
while(!feof($f))
{
$sor = fgets($f);
echo $sor;
}
fclose($f);
}
?>Minden olyan file-ra működik, amely a test.php-val megegyező mappában van. Azokra a file-okra, amik ezen mappa felett(nem belül) vannak, nem működik. Ezt lehetséges orvosolni valahogy?
Próbálkoztam olyannal, hogy jQuery-vel az input file változására írtam egy függvényt, ami kihalássza a mező értékét ( val() ), de az is csak a fájlnév.kiterjesztést adta vissza.
Ötlet?
•
-
Fájlokat a $_FILES super global-ban keressük, nem a $_POST-ban
move_uploaded_file()-lal odamozgatod, ahová akarod, vagy maradhat a helyén is, úgyis fel lehet dolgozni
HTML oldalról a <form /> tag-ből hiányzik az enctype="multipart/form-data"Interneten (például máris a php.net-en) találsz írásokat arról, hogyan kell kezelni a fájlfeltöltéseket.
-
Tele von Zsinór
őstag
válasz #68216320 #13150 üzenetére
Ha mysqli-t használsz, érdemesebb volna a prepared statement támogatását használni, de első lépésnek ez is jó. Hátránya, hogy könnyen elfelejthetsz valamit escape-elni, és akkor máris SQLi sebezhető vagy.
Kiírás előtt? Nem, query-be helyezés előtt kell ez neked. Az escape-elés annyit csinál, hogy query-biztossá teszi az inputot.
-
#68216320
törölt tag
válasz Tele von Zsinór #13153 üzenetére
Természetesen a query előtt gondoltam. Prepared statement még nem rögzült bennem.
-
addikt
Szerintetek mennyire elvárás manapság az MVC használata? Egyáltalán miért ragaszkodnak ennyire hozzá? A weblaboron volt róla egy vita, ahol kifejtették, hogy magát a modellt nem web-alapú (stateless) fejlesztésre találták ki, épp ezért nem is igazán alkalmas rá, de folyamatosan próbálják ráerőltetni. Ti mit gondoltok erről?
-
Abszolult igazuk van rá, így nem is értem, hogy miért tart már a 4. verziónál az ASP.NET MVC, illetve miért van 20 millió PHP framework, ami MVC mintát követ ráerőltetés nélkül. És az anyja mindenit, működik!
Egyébként is, hogy jön ide, hogy valami stateless-e vagy sem?
-
Dave-11
tag
Lehetséges hogy el kellesz készítenem egy webáruházat. Még ilyesfajta dolgon nem dolgoztam. Nem mondom hogy nagyon profi vagyok PHP-ból, de nagyjából átlátom a dolgot. Szerintetek hogyan érné meg jobban? Ha írok egy saját rendszert, vagy esetleg valamilyen meglévőt használok fel. (Így igazság szerint a saját jobban vonz, ugye nagyobb szabadság meg könnyebben tudnám javítani a hibákat.)
Tudnátok ajánlani valamiféle dokumentációt ehhez, hogy mikre figyeljek oda, hogyan kezdjem el, miknek kell meglenniük, ilyesmi?:D Semmi :D
-
-
Dave-11
tag
-
Speeedfire
nagyúr
válasz Peter Kiss #13160 üzenetére
2-3? Kicsit túlzol nem? Egy alap rendszer szerintem nem telik ennyi időbe egy normális framework-kel.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Siriusb
veterán
válasz Speeedfire #13162 üzenetére
Túlzás vagy sem, de mi értelme lenne saját webshopot fejleszteni, hacsak nem ujjgyakorlat céljából?
-
-
Sk8erPeter
nagyúr
válasz Dave-11 #13164 üzenetére
Ne viccelj már... csak gondold végig, mi mindent kell tudnia egy webshopnak. A manapság népszerű webshopokat is évekig fejlesztették, gondolj csak bele: biztonsági rések, plusz szolgáltatások, fizetési lehetőségek, AJAX-osítás, képfeltöltés, rendes kategorizálás, menürendszer (utóbbi kettő fastruktúrában), rendes admin-felület, jogosultságok, és még nagyjából egy órán át sorolhatnám.
Vannak különálló webshopmotorok, és vannak CMS-ekbe (Drupal, WordPress, stb.) beépülő webshopmodulok/pluginek is, igen nagy kódbázissal.
Könnyű végiggondolni, hogy egyedül egyáltalán nem megtérülő vállalkozás fejleszteni saját webshopmotort, de általában csapatban sem.
De egy új webshop kezelésének megtanulása is sok időt igényel, ha nem csak alapfeladatokról van szó.Sk8erPeter
-
Soak
veterán
válasz Speeedfire #13165 üzenetére
shop.example.com ...
-
Speeedfire
nagyúr
-
syC
addikt
válasz Peter Kiss #13152 üzenetére
Átnéztem, átírtam, minden működik.
Ezek szerint ez a szokás, hogy olvasás, stb. előtt feltöltöm a file-t és utána buherálok?
•
-
-
-
fordfairlane
veterán
válasz Dave-11 #13159 üzenetére
Egy webáruház rengeteg funkciót integrálhat magába. Alapesetben, ha nincs semmiféle varázslat, akkor is kell egy terméklista, kell egy shopping cart, amibe gyűjti a vásárló a termékeket, és kell egy checkout funkció, ami lezárja a vásárlási folyamatot. Ezt aztán a végtelenségig lehet bonyolítani különféle termék kategorizálási-, csoportosítási funkcióval, a különféle fizetési módokat kiszolgáló payment szolgáltatásokkal egészen odáig, hogy a számfejtéshez szükséges adatokat is megfelelő módon ki lehet nyerni belőle.
x gon' give it to ya
-
fordfairlane
veterán
Az MVC pattern alkalmazásfejlesztésre lett kitalálva. Pont fordítva látom a dolgot.
A web dokumentum-megosztó rendszernek indult, később egyre jobban kibővült, és manapság egy elosztott alkamazás támogató frameworkké nőtte ki magát. Ez tette szükségessé, hogy a különféle alkalmazásfejlesztési módszertanokat kezdik átvenni a web fejlesztők is.
Az MVC lényege a adatok kezelésének és az adatok reprezentációjának (nézet) szétválasztása, illetve az adatok kezelésénél is további részekre bontása, egyrészt az alkalmazás-workflow (ez a controller), másrészt a domain-logika (ez meg a modell) . A stateless-ségnek nincs semmi köze ennél a témánál.
x gon' give it to ya
-
Speeedfire
nagyúr
Adott egy link domain.hu/controller/action?valami=valami/megvalami
Ezt nekem a böngészőbe már így jeleníti meg:
domain.hu/controller/action?valami=valami%2FmegvalamiEzzel lehet valamit kezdeni?
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
őstag
válasz Speeedfire #13174 üzenetére
UrlDecode ha minden igaz megoldja (most nem tudom kipróbálni).
"Decodes any %## encoding in the given string. Plus symbols ('+') are decoded to a space character. "
[ Szerkesztve ]
-
Speeedfire
nagyúr
válasz vgyuri #13175 üzenetére
Igen ez volt az.
Más:
Hogy lehet 2 rendszert összekapcsolni? Feljött nálam is a shop kérdés.
Van már egy meglévő rendszerem yii alapokon, a yii bővítmények között találtam egy kész shop rendszert, amit csak át kell alakítani.
Viszont ugye ott saját felhasználói adatbázis van, de már nekem is van egy. Mi lehet ilyenkor a megoldás?Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
cucka
addikt
válasz Speeedfire #13176 üzenetére
Hogy lehet 2 rendszert összekapcsolni?
Nehezen. Vagy átalakítod az egyik adatbázist a másik formátumra, vagy készítesz egy köztes réteget, ami az egyik kérést átfordítja a másik rendszer számára.Mivel gyanítom, a két rendszer funkciólistája nem egyezik meg 100%-osan, mindkét megoldásban benne van a szívás rendesen, plusz mindkét rendszert tökéletesen ismerned kell.
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
válasz Speeedfire #13176 üzenetére
Migrálni a saját meglévő tábláid adatait az új táblákba, a kritériumoknak megfelelően, úgy, hogy az új webshopba megfelelően bekerüljenek a termékek, most így konkrétumok nélkül csak általánosságokban lehet tanácsot adni. Ha van a migrálásra/importálásra valami jóféle, rugalmas "keretrendszer" (mint a Drupalos Migrate modul), akkor az a legjobb. De nézz utána, van-e valami "híd" a két rendszer összehozására. Pl. Drupal esetén volt a Drupal saját táblái és a Gallery2 összehozása esetén, tudtommal ott kicsit gányolósan úgy működött, hogy minden felhasználói adaton történő változás mentődött a másik táblában is, ez mondjuk nem a legjobb megoldás, nem biztos, hogy egy hiba esetén szinkronban lesz a két adat. Szóval a legjobb talán az lenne, ha azonos felhasználói adatbázisban dolgozna a kettő.
Melyik webshop ez?
Sk8erPeter
-
modder
aktív tag
válasz Speeedfire #13176 üzenetére
Kijelölöd az egyik rendszer felhasználói adatbázisát, mint a felhasználói adatbázis, és közösen azt használod mindkét rendszernél.
A másik rendszer authentication&authorization rétegét le kell cserélned, hogy "az adatbázist" használja, ne a sajátját. Ez rendszertől függően lehet egyszerű és bonyolult is, de mindenképpen bele kell nyúlni a kódba, és módosítani kell, hogy amikor a másik rendszer egy felhasználót autentikálni szeretne, azt ne a saját adatbázisból próbálja meg, hanem "az adatbázisból".Többféleképpen lekérdheted a felhasználói adatokat "az adatbázisból":
-- kapcsolódhatsz közvetlenül az adatbázis kiszolgálóhoz
-- csinálhatsz egy service réteget ahhoz a rendszerhez, amelyiknek az adatbázisát használni fogod (SOAP vagy REST), és a másik rendszer ezt hívja minden egyes alkalommal, amikor egy felhasználót be kell jelentkeztetni/regisztrálni.Az előbbi egyszerűbb, szerintem, de ha változik az adatbázis struktúra egy update során, akkor kínos minden rendszer implementációját frissíteni, plusz nehezen megoldott az auditálás.
Az utóbbi azért jó, mert a kód könnyebben, módosítható, mint az adatbázis struktúra, és anélkül lehet az autentikáció implementációját változtatni, hogy a service interfészt megváltoztatnád. (pl. ha az adatbázis struktúrán változtattál). Én ezt választanám egy REST interfésszel. Arra ügyelni kell, hogy a két rendszer közötti kommunikáció SSL-en keresztül menjen.Amit még meg kell említeni, hogy a felhasználó azonosításán kívül valószínűleg be lehet állítani egy csomó más felhasználói preferenciát is a különféle rendszereken. Én ezeket megtartanám rendszerfüggően, az adott rendszer saját adatbázisát. Azon a rendszeren, amelyik nem a saját felhasználói adatbázisát használja autentikációra, a service hívásból visszajött valamilyen user id-hoz kötném ezeket az adatokat.
-
Speeedfire
nagyúr
Hogy kell elképzelni ezt az átfordítja a másikra?
Lényegében talán elég lenne csak átírni a shop user model-jét. Ha erre írok egy interface-t akkor elvileg nem is kell minden egyes attributomot átírni igaz?Csak, mert a 2 user táblában még a nevek is máshogy vannak.
Sk8erPeter: Van a yii-ben migrálás, de nem próbáltam még ki ezt a dolgot.Ugye van a saját rendszerem yii-ben és adott egy yii extension. Semmi extra, elég alap szerintem. Viszont nem a 0-ról kell kezdeni a fejlesztést.
Saját user tábla | shop user tábla:
Lényegében a shop user tábláját szeretném valahogy megoldani, hogy a saját rendszerbe mentse őket, úgy hogy közben egy db attributumot se kelljen átírni sehol sem.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz modder #13179 üzenetére
Igen, én is ezt szeretném, hogy egy adatbázis legyen csak inkább. Az authentikáció nem problémás, mert mind a kettő yii-re van írva, így ez menni fog.
A gondom, csak az, hogy nem tudom hogy álljak neki ennek az interface dolognak, mert csak ez lehet a megoldás rá szerintem. 2 táblában tárolni mindent felesleges lenne, mert elvileg meg lehetne oldani így a dolgot, de minek? Olvasok még erről, hátha van valami félkész megoldás, vagy nem tudom...elvileg a yii usermanager extension-nel együtt tud működni, szóval valami biztos van rá.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
modder
aktív tag
válasz Speeedfire #13181 üzenetére
Elég általános megoldást írtam, nem yii specifikus.
Jól értem, hogy nem akarod az egész adatbázist közösen használni, csak a user managementet? Sajnos nem ismerem a yii-t és az extensionjeit, de ha a két rendszer ugyanaz, akkor ugyanazt az adatbázis sémát használják. Így elvileg egyszerűbb megoldani, hogy az egyik webshop másik adatbázishoz kapcsolódjon közvetlenül, és onnan kérje le az adatokat. A gyakorlatban pedig vannak problémák:
1) lehetnek olyan join lekérdezések, ahol egy webshop táblát kapcsolsz össze egy user táblával. Ezt akkor szét kell választani kódban.
2) ha használ tranzakciókezelést, akkor a két adatbázis közötti elosztott tranzakciót inkább felejtsd el, hacsak nincs már erre megoldás yii-ben vagy PHP-ban.Egy rendszert általában egy adatbázisra terveznek. Kétlem, hogy annyira modulárisra csinálták volna ezt a webshopot, hogy egyszerűen le tudd cserélni honnan autentikálja a felhasználókat. Ha igen, akkor szerencséd van
Mindenesetre tényleg nézz utána, hátha ezt már valaki megoldotta, ha nem, akkor kezdd el nézegetni a kódot, hogyan van megoldva a user management, és hol tudnál belenyúlni, melyik réteget tudnád lecserélni úgy, hogy közös user adatbázist használjon.
A user management modullal együtt tud működni
Ha a user management modulnak meg tudod mondani, hogy melyik adatbázishoz kapcsolódjon, az jó. Ez azt is jelenti, hogy a webshop vélhetőleg nem függ adatbázis szinten a user tábláktól, úgyhogy nem lesznek 1)-beli esetek. A probléma viszont még fennáll, hogy a webshop saját user táblája, ahol a postázási címet meg ilyeneket tárol, ugyanazt az adatbázis hozzáférést akarja majd használni, mint a maga a webshop.A legnagyobb problémát szerintem az fogja jelenteni, hogy a webshop modult, mint egy egységet egy adatbáziskapcsolatra tervezték, így kétlem, hogy konfigurálással be tudnád neki állítani, hogy a termékeket a saját adatbázisból szedje, de a webshop user-t egy másikból. (mivel ha jól láttam a képről, a webshop user táblája össze van kötve a yii user táblájával)
[ Szerkesztve ]
-
Speeedfire
nagyúr
válasz modder #13182 üzenetére
Jól értem, hogy nem akarod az egész adatbázist közösen használni, csak a user managementet?
Nem teljesen. Lehet én fogalmazok rosszul.
Adott egy saját weboldal yii alapokon, szintén yii alapokon találtam egy extension-t, amivel shop-ot tudok készíteni. Viszont a shop-nak külön van egy user táblája erre a célra. Én a shop user táblája helyett a sajátomat akarom használni. Mind a 2 táblába nem akarok usereket felvenni.Viszont olyan megoldásra gondoltam, lehet hülyeség lenne, hogy a shop táblát lecserélem egy kapcsoló táblára, ahogy látom a kapcsolásokat, csak a shop user id részét használja.
Vagy ez így nagyon hülye megoldás lenne?
A mentés meg a törlés funkciókat felülírnám a sima User model adatival.mivel ha jól láttam a képről, a webshop user táblája össze van kötve a yii user táblájával
Nem, ott csak szemléltettem. A yii user a saját weblapom user táblája. A jobb oldali shopuser pedig a shop adatbázisa lenne.A shop táblája elég egyszerű. Nem egy túl bonyolult shop rendszer.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
modder
aktív tag
válasz Speeedfire #13183 üzenetére
Akkor szerintem elég, ha kicseréled a shop user tábláját egy view-ra, ami a saját user tábládból kérdez le, de a neve megegyezne azzal, amit a shop modul vár. De akkor a módosításokat mindenképpen az eredeti táblán kell elvégezni, mert azt ugye view-n nem lehet.
-
DeltaPower
őstag
válasz Speeedfire #13183 üzenetére
YiiShopCustomer táblába az userid-t honnan veszi? Nem véletlen úgy működik, hogy az alap user tábla adatait bővíti ez a tábla a cím, irányítószám stb. mezőkkel?
"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser
-
Speeedfire
nagyúr
válasz modder #13184 üzenetére
Hát, ezt a view-ot inkább kihagynám. Inkább az attributomoknál a sima user táblára hivatkoznék. Azt még nem tudom hogyan, de remélem reggelre megálmodom.
DeltaPower: Minden yii rendszerben a userid definiálva kell, hogy legyen. Elvileg ez valóban csak egy kiegészítő tábla lenne a postázási adatokkal, de ezt már az alap rendszeremben is felvettem, így nem akarom még egyszer felvenni. Annyi, hogy nálam nincs country, de itt MO.-n nem kell ez...még.[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
válasz Speeedfire #13186 üzenetére
Végül is egy felhasználónak lehet külön állandó lakcíme vagy levelezési címe, és egy szállítási címe... Semmi gond nincs abból, ha a kettő szinkronban van. A cím pont, hogy elég ritkán változik. Szerintem nem történik semmi tragédia, ha itt ennél duplikáció van.
Hogy nálad nincs country, az pedig könnyen pótolható. Legfeljebb mindegyiknél "hu" lesz a kód, aztán annyi.Amúgy ezt írják:
"Note that this Module does NOT handle User/Admin authentification. You have to do this by yourself, either by CAuthManager, CDbManager, the yii-user-management or the srbac Module. Instructions on how to integrate this Module with the Yii User Management Module will be available soon, it is already prepared"De amúgy biztos van Yii-hez más webshopmodul is, ezt amúgy is fikázzák páran a kommentekben, amennyit láttam, hogy gányolások vannak benne, megpróbálkozhatnál esetleg egy másikkal is, nehéz elképzelni, hogy ne lenne valami bevált webshop extension Yii-hez is, hátha van olyan, aminél normálisan leírják a felhasználók adatainak lazán csatolt kezelését.
Sk8erPeter
-
Speeedfire
nagyúr
válasz Sk8erPeter #13187 üzenetére
Hmmm...hmmm. Mondasz valamit. Akkor lehetne a shop user tábla a szállítási cím akár.
Hát, valóban nem a legszebb a kódja. Meg lassan is fejlesztik. Évente 1-2 commit van csak...
Sajnos csak egy másik ilyen rendszer van [link], viszont kevesebbet tud, mint ez.Inkább ezt a rendszert igazítgatnám, csinosítgatnám. Itt megvannak a kategóriák, termék specifikációk, fizetési és szállítási opciók. Szóval nem kellene nagyon sok extra funkció szerintem bele.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
#36268800
törölt tag
Üdv!
Arra lennék kíváncsi, hogy van-e olyan PHP kód, ami segítséget nyújthat a LAYOUT elkészítésében?
Szeretnék előre legyártani néhány LAYOUT mintát, hogy a következő elkészítendő weboldalak alkalmával már ne kelljen ezzel vesződni, vagy maximum nagyon keveset kelljen módosítani. Viszont ehhez szeretném a legjobb megoldást megtalálni.A W3 schools oldalán találtam HTML Layout-ot, ahol DIV tagekkel és CSS-el van elkészítve a LAYOUT. Arra lennék kíváncsi, hogy ez mennyire számít gagyinak?
-
válasz #36268800 #13189 üzenetére
Layout-ot alapvetően HTML elemekből áll, amelyeket CSS-sel cicomáznak ki. Ami plusz dolog jöhet akármelyik nyelvet is nézzük, az a dinamikus változók kiírása, dinamikus blokkok kijelölése, feltöltése. Template engine-ek léteznek, csak ezekkel szerintem az a baj, hogy a PHP maga már az, de pl. amit szoktak alkalmazni, azok a "HTML helper"-ek, ilyet magad is csinálhatsz, mert egyébként ki tudja, milyet tudnál használni (pl. legfaékebb és ocsmányabb megoldással van egy HTML osztályod, aminek pl. van valamilyen metódusa, pl. HTML::Img($src, $alt = ""), ami kitol magából egy full <img /> tag-et csak az src="" attribútumot megadva).
-
tildy
nagyúr
válasz #36268800 #13189 üzenetére
Nezz meg nehany template engine-t. Smarty pl egyszeru.
Mas kerdes: Zendben mit erdemesebb hasznalni az alabbi feladatra:
Git submodulekent van egy engine, ami kezeli a megjelenitendo adatokat JSonban. Az adatok tulkeppen widgetek. Zendben mit erdemes hozza irni?
View-helpert ? Servicet? netan Action helpert vagy resourcet?
Tobb helyrol el kell ernem ezeket az adatokat, de nem nem controllerbol.Jut eszembe, interfesz, elmagyarazna pontosan valaki ez mire valo ?
[ Szerkesztve ]
"Tartsd magad távol azoktól, akik le akarják törni az ambíciódat! A "kis" emberek mindig ezt teszik, de a nagyok éreztetik veled, hogy te is naggyá válhatsz" - Mark Twain
-
#36268800
törölt tag
válasz Peter Kiss #13190 üzenetére
Arra gondoltam, hogy például a PHP-ben van-e beépített függvény arra, hogy megnézze az aktuális felhasználó felbontását és aszerint változtassa meg az adott oldalfelépítést. Akár egy SWITCH elágazással meg lehetne adni, hogy ha pl.
'a esetben' 800*600 a felbontás, akkor használja a stíluslap1.css-t;
'b esetben' 1024*768 a felbontás, akkor használja a stíluslap2.css-t;
és így tovább...Szeretnék egy használható sablont készíteni a későbbi munkáimhoz.
Az lenne a lényeg, hogy szépen jelenjen meg a legtöbb felhasználó számítógépén.
A layout-ra kétféle megoldást találtam itt a fórumon, mindenki a következők valamelyikét ajánlja:
egy nagy táblázat, amely felosztása után újabb táblázatokat és esetleg div tageket használj
div tagek és css, csakúgy mint a w3 schools oldalán.A táblázatos megoldásról azt olvastam, hogy 'nem erre találták ki', a div tageket meg egyesek nem szeretik.
Van esetleg egyéb megoldás is, avagy ez a kettő a jelenlegi technológia csúcsa?
Én inkább szeretném az esetlegesen bonyolultabb div-es megoldást, ha az a jobb, később meghálálja az magát szerintem.Kérdés még, hogy a SEO szempontjából melyik ideálisabb?
-
Soak
veterán
válasz #36268800 #13193 üzenetére
PHP szerveroldali, nincs köze a klienshez. Nem tudod eldönteni, hogy mekkora a felbontás. Szerintem jobban jársz egy HTML szerkesztés vagy egy weblap készítés topikkal.
-
Sk8erPeter
nagyúr
válasz #36268800 #13193 üzenetére
Soakhoz csatlakozva ez innentől már erősen OFF topic, nem annyira PHP-s kérdés, hacsak még nem a szerveroldali kimenetgenerálásról, template-ezésről van szó.
De hogy választ is írjak:
A táblázatokat jogosan nem szokás ajánlgatni, mert macerás, kisebb rugalmasságot kínál legfőképp olyan esetben, amikor az oldal tele van ilyen-olyan lebegő-úszkáló elemekkel, blokkokkal; az egymásba ágyazott táblázatok kódja ráadásul gusztustalan, plusz a böngészőre felesleges többletrenderelési feladatokat ró. Erre az ember leginkább akkor jön rá, amikor már megpróbálkozott mindkét módszerrel, és látta, hogy összességében tényleg nem véletlenül ajánlgatják a dives megoldást, nem puszta hype-olásból. Ha megnézed, manapság a népszerű oldalak nem táblázatos felépítésben készülnek, nem véletlenül; ergo ez jobban bevált. (Nyilván nagyon sokan még mindig megrögzöttségből azt mondják, hogy márpedig a table is pontosan ugyanolyan jó, és hülye az, aki az új divatot nyomatja - nem kell rájuk hallgatni. Valószínűleg nem kellett még szopniuk undorító egymásba ágyazott táblázatokkal. Tényleg nem erre találták ki. Ettől függetlenül nagyon sokan sajnos túlzásokba esnek, és még a ténylegesen táblázattal megoldandó feladatokra is képesek diveket alkalmazni, és aztán CSS-sel ráerőltetni a display:table, display:table-row, display:table-cell, stb. kényszermegoldásokat, ami meg már megint nagyon gány. A layout tehát ne táblázat legyen, viszont ha neked tényleg egy táblázat kell a tartalmi részre (pl. adatok rendezett megjelenítésére), akkor az maradjon is táblázat.)
Jól gondoltad, azt sem két perc megtanulni, a sitebuild igazából külön "szakma". A sitebuilderek sokszor grides, pl. SASS-sal támogatott megoldásokat is igénybe vesznek a munkájuk gyorsítása érdekében (pl. Zen Grids, de kismillió példa van még). A layoutot valóban generálni szokás, de erre saját motort nem hiszem, hogy kezdőként megérné írnod. Max. ha gyakorlásnak szánod.Sk8erPeter
-
tildy
nagyúr
válasz Sk8erPeter #13195 üzenetére
Mi eddig mindenhol kezzel irtuka layoutot.
"Tartsd magad távol azoktól, akik le akarják törni az ambíciódat! A "kis" emberek mindig ezt teszik, de a nagyok éreztetik veled, hogy te is naggyá válhatsz" - Mark Twain
-
Speeedfire
nagyúr
válasz Sk8erPeter #13195 üzenetére
Ezt a sass-t lehet használni osztott tárhelyen? Ez valami micsoda?
Érdekelne a dolog, de ha osztott helyen nem megy, akkor nem erőltetem.[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
DeltaPower
őstag
válasz Speeedfire #13197 üzenetére
Egy css-hez hasonló szintaxisú leíró nyelv, lényegében a css-t egészíti ki változókkal, hierarchiával stb. és szabvány css a kimenete.
"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser
-
Speeedfire
nagyúr
válasz DeltaPower #13198 üzenetére
Ez oké, de tudom-e esetleg használni osztott tárhelyen? Kell-e valami csomagtelepítés vagy csak elég valami extension?
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
válasz Speeedfire #13199 üzenetére
Ez egy eszköz, mint a Notepad vagy a Netbeans.