Moduláris fejlesztés

Internet: PHP, CGI, stb.

Sziasztok!

Tudtok-e valahol lehetőleg magyar leírást, hogyan kellene elkezdeni, vagy hogy hogyan kell megalkotni egy olyan keretrendszert, amit utána modulokkal bővíthetek. Elsősorban most PHP-ban írt programhoz kellene, de később ezt felhasználnám java és egyéb programokhoz is.

Persze az elvet ha megértem, hogy hogyan kell megoldani, hogy a programba betöltött plugin az működjön(pl. joomla), hogyan kell megírni az alapot, utánna már menni fog a többi programnyelvben is.

Előre is köszönöm a segítséget.

  • 4463 megtekintés

( Yorirou | 2010. 02. 08., h – 15:10 )

Drupal működéséről olvass cikkeket, helyenként nézz bele a kódba, nagyon hasznos, sokat lehet tanulni. Ha ragaszkodsz a PHP OOP szintaxisához (nem cél a PHP 4 kompatibilitás), akkor nézd a 7-es kódját, már kezd készen lenni.

Csak a Drupal forráskódját ne ajánld tanulásra, mert nem szép :)

http://rubyonrails.org/
http://kohanaphp.com/
http://www.concrete5.org/

Szerintem ebben a sorrendben, a Concrete5 egy kész CMS, a többi framework. Ha később másra is akarja használni a tudását, akkor ezekhez hasonló MVC felépítésű kódokat kell ajánlani.

--
http://sandor.czettner.hu

Nem feltetlen a kod jolformaltsagarol beszelgetunk.

Egyebkent meg:
- a PHP fajl vegerol elhagyni a ?> -t... hat nem tudom, ez elsosorban 1) php parser bug, fixalni kene... 2) miert is tartozik ez a reszlet a programozora? 3) Ha mar van nyito tag, sok IDE megkoveteli a zaro taget, kulonben alahuzza az egesz kodot, es nincs szintaxisellenorzes (ez persze a legrosszabb eset, de erre is fel kene keszulni).
- TRUE, FALSE: Minden normalis nyelv a kisbetust preferalja. Mert azt konnyebb beirni, es mert azok nem teljesen konstansok, inkabb a nyelv reszei.
- en tiltanam a shell stilusu valtozo include-olast (echo("Foo: $foo");), mert rontja az olvashatosagot, es mert nem szep.

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

- a PHP fajl vegerol elhagyni a ?> -t... hat nem tudom, ez elsosorban 1) php parser bug, fixalni kene... 2) miert is tartozik ez a reszlet a programozora? 3) Ha mar van nyito tag, sok IDE megkoveteli a zaro taget, kulonben alahuzza az egesz kodot, es nincs szintaxisellenorzes (ez persze a legrosszabb eset, de erre is fel kene keszulni).

Ehhez csak ennyit.

PHP File Formatting
General

For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it´ prevents the accidental injection of trailing white space into the response.

Note: Important: Inclusion of arbitrary binary data as permitted by __HALT_COMPILER() is prohibited from PHP files in the Zend Framework project or files derived from them. Use of this feature is only permitted for some installation scripts.

Innen: http://framework.zend.com/manual/en/coding-standard.php-file-formatting…

Ujra: PHP parser bug, fixalni kene. Peldaul ettol a dologtol nem lesz valid XML egy XHTML PHP fajl. Es mi az, hogy egy zaro tag _nem szukseges?! Akkor a nyito miert szukseges egy csak PHP kodot tartalmazo fajlnal? Ez most kivagta a parser errort. Tessek nekem megindokolni, akkor elhiszem, hogy jo dontes volt. Addig azonban bug marad, akarmilyen szepen is irjatok le, kedves PHP fanok.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

> Es mi az, hogy egy zaro tag _nem szukseges?!

Van, hogy az EOF megfelel zárótagnak. Pld manapság már nem kötelező minden szöveget tartalmazó sort LF-el lezárni, a szöveg utolsó soránál elmaradhat a sorzárótag, megfelel az EOF is. A gcc pld ír egy warning-ot, de azért feldolgozza az ilyen szöveget is. A DOS-os copy parancs kitesz egy fájlzárótagot amikor szöveg fájlokat fűz össze, de az már nem elvárás, hogy minden szöveg fájl végén kötelezően ott legyen ez a zárótag, mert megfelel az EOF is.

Szóval több évtizedes hagyománya van a zárótagok elhagyásának.

? A gcc konkretan sikoltozik, ha egy fuggveny zaro } jelet lehagyom (syntax error at end of input)! Azon felul, sem a gcc sem a DOS copy nem kezel, es nincs is koze XML-like dolgokhoz, a PHP-val ellentetben, ahol pl XHTML-t is irhatok, marpedig az XML is egyben. Szoval itt elkezdett keveredni a szezon meg a fazon, a ketto nem ugyanaz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igyál egy kávét légyszi, mert néha úgy tűnik, nem vagy képben.
Itt senki sem beszélt a {} jelekről, hanem a PHP blokkot lezáró ?> jelről van szó, és pontosan oda van írva, hogy miért. Az XML-t és az XHTML-t pedig megint nem értem pontosan, hogyan keverted ide, itt most tiszta PHP kódot tartalmazó fájlokról van szó, amelyek nem tartalmaznak HTML-t, és semmi mást. És mivel csak PHP van benne, értelemszerűen egy lezáró tag lenne, az is a fájl végén.
Aztán hogy te magadnak mit és hogyan keversz össze, az már a te dolgod.

For files that contain only PHP code...

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Ez a kontextus nagyon nem volt akkor ertheto:
"... a szöveg utolsó soránál elmaradhat a sorzárótag, megfelel az EOF is. A gcc pld ír egy warning-ot, de azért feldolgozza az ilyen szöveget is. "
Itt konkretan mire gondoltal?

Egyebkent pedig a php modulkodoknal en mindenkeppen csak ketfele megoldast tartok elfogadhatonak:
1) konzekvencia - nincs kulonbseg a csak PHP-t tartalmazo kod, es a HTML-t is tartalmazo kod kozott, mindkettonel megkovetelni a zarotaget
2) specializacio: azon kodok, melyek tisztan modul kodok, feleslegesen kezdodnek <?php taggel. Egy megfelelo extension valasztassal el lehetne hagyni ezt a taget.

Barhogy is, a jelenlegi allapot totalis inkonzisztenciat tartalmaz; es olyan erzest kelt, mintha valaki lustasagbol nem akarna kiirni a ?> -t, es erre nem scriptet irt, hanem a php ertelmezot keszitette fel az o lazy szovegbevitelere.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Azt a hozzászólást nem én írtam, de szerintem egyszerűen a sorvége jelre gondolt.
Azt pedig, hogy téged frusztrál a jelenlegi helyzet, ne vetítsd rá a PHP-re, és pláne ne a Drupalra.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

> Itt konkretan mire gondoltal?

Pld: http://www.valentina-db.com/bt/view.php?id=438

"When importing a text file with ImportText, the last record will not be imported if there is no trailing linefeed at the end of the file."

Te mindig oda szoktál figyelni, hogy az utolsó szövegsor végén is ott legyen a sorvégjel? Vagy jobb, ha nem kell odafigyelni, mert anélkül is jó?

Ha IDE-ben dolgozok, az IDE van olyan kedves erre (is) odafigyelni, ha pedig nem IDE-ben, akkor altalaban osszejon annyi ures sor, hogy a fajl vegen sokszor nem is csak egy ures sor figyel. Egyebkent meg tudtommal van erre vim modul is, szoval en nem szoktam ilyeneken aggodni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"a szöveg utolsó soránál elmaradhat a sorzárótag, megfelel az EOF is. A gcc pld ír egy warning-ot," hogy epp labon lotted magad.
ha epp egy header file-ban kovetsz el ilyet, es epp egy makro definicio az utolso sor, akkor a kovetkezonek include-olt c file elso sora is bekerul a makrodefinicioba. optimalis esetben emiatt lehany teged a gcc, de elofordulhat olyan szelsoseges eset is, hogy a behuzott sorral egyutt is ertelmes marad a makro, le is fordul, aztan segfaultol.

Nem php fanok irtak le, hanem a php fejlesztői. Másreszt meg azért, hogy ne rakjál html kódot a php kódba. Tehát ha include-olsz egy filet amiben csak html van akkor elszáll parse error-ral, kényszerítve hogy ne csinálj ilyet. Persze ha kirakod a záró taget akkor nem történik semmi.

Alapban igen, de a drupal is hasonlo dolog miatt ajanlja és itt erről van szó hogy ha tisztán OOP kódot irsz, akkor ne rakjal záró taget és hrgy84 ebbe kötött bele. Senki nem mondta hogy ha kevert kódot írsz, akkor is hagyd el. Ezért drupal coding standrads és nem php coding standards.

LOL, write only mode? :)

Gondold már végig és vonatkoztass el attól, hogy nyitó és zárótag, az csak jelzés értekű. A PHP értelmező minden sorra echo-t hív meg. Ha megadod neki, hogy <?, akkor átkapcsol értelmező módba, ?> -ra pedig visszakapcsol. Ennyi, nem varázslat. Ez a lehetőség megvan Perlben, Pythonban, Rubyban is, az a PHP sajátossága, hogy defaultban így szállítják.

--
return 0;

Igen, amde szerintem total egyszeru egy olyan eloreolvaso mechanizmus, hogy ha a parsolando fajlban a tovabbiakban mar csak ures sorok vannak, akkor azokra nem kell echo-t hivni. Es ezt persze eleg mondjuk az apache modul eseteben fixen bekapcsolni, ahol ugyebar nincs igeny whitespace scriptbe embeddelt php-t futtatni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( hrgy84 | 2010. február 9., kedd - 8:07 )
Ujra: PHP parser bug, fixalni kene. Peldaul ettol a dologtol nem lesz valid XML egy XHTML PHP fajl
@

Miiiii vaan? Miert kene xhtml validnak lenni egy php fajlnak? Mert az eger pupos, vagy miert? Ez olyan mint h aki nem tud uszni, ne masszon fara, mert eluti a villamos! Kb annyi koze ezeknek egymashoz. Ugy tunik a Microsoft evangelistai kiadtak embereiknek, akik ismernek olyan szavakat mint xhtml, valid, stb, azok fikazzak jobbra balra a PHP -t, ettol remelve, hogy tobb fejleszto es megrendelo fog atterni az o termekeikre. Mar ha ertelmet keresunk, akkor ez johet szoba talan...

Ez kicsit paranoid. A PHP nagyon elterjedt, ennek az okát nem nagyon értem, vannak nála sokkal jobban használható és átláthatóbb nyelvek. És hogy lásd, nem a microsofttól jöttem: ruby, python, perl.

Viszont próbálja meg valaki megmagyarázni egy pizzéria tulajdonosának, hogy az 500Ft-os tárhelyet, amit kinézett nem lesz jó, mert csak PHP-t tud :) A létjogosultsága itt van. A neve is "hypertext preprocessor", nem éppen CMS-re vagy webáruházra lett kitalálva a nyelv. Csavarhúzóval is be lehet ütni egy szöget.

Nade: minden pistike ismeri (tud benne gányolni olcsón). A legolcsóbb tárhelyen is alap. Melyik megrendelő hallott másról?

--
http://sandor.czettner.hu

( zoner | 2010. február 10., szerda - 0:05 )
Ez kicsit paranoid/.../Nade: minden pistike ismeri (tud benne gányolni olcsón
@

Ez meg kicsit sztereotip :) Pistike barmely nyelven tud ganyolni! Ez nem nyelv specifikus!

( zoner | 2010. február 10., szerda - 0:05 )
nem éppen CMS-re vagy webáruházra lett kitalálva a nyelv
@

De pont arra :) Amugy herotom van mar az effele vitaktol.Mert nehez azzal vitatkozni amikor valaki kijelenti, hogy miert lett kitalalva egy nyelv, es ebbol aztan vegso kovetkeztetest von le. Mert mi van akkor ha nem erre lett kitalalva, de kozben alkalmassa tettek ra? Persze, pusztan csak elmeleti megfontolasbol vagyok ra kivancsi. Szal nagyon sablonos dolgok ezek, php vs. java, mysql vs. postgresql, alien vs. predator...

"Mert mi van akkor ha nem erre lett kitalalva, de kozben alkalmassa tettek ra?"

Épp az a bajom, ahogy alkalmassá tették rá. Persze ettől még használom, mert kell, a megrendelőnek szüksége van rá, épp ezért látom át az összes hibáját.

Nekem az a furcsa, amikor valaki szépnek találja a PHP-t és nem értem, hogy miért van ez. Nem tudom elképzelni, hogy valaki nem próbálkozott mással. Ha már ez a szakmája, hobbiból miért nem próbál ki egy Ruby-t vagy Python-t

--
http://sandor.czettner.hu

szerintem 3 fazis van a PHP tanulasban:
az elso az, amikor el tudsz benne kezdeni dolgozni, es latod hogy mindenre jo, ezert sztarolod a nyelvet.
a masodik fazis az, amikor rajosz, hogy ugyan nagyon sok dologra jo, de nehanyra vannak sokkal hatekonyabb eszkozok, ebben a fazisbol kerulnek ki a php-t leglelkesebben fikazok (azok kozul, aki mas nyelvbol jott, sokan egybol ide kerulnek)
es van a harmadik fazis, amikor mar egyutt tudsz elni a hibaival, mert mar zsigerbol tudod hogy hol kell alanyulni, ha valami nem megy, es tudod hogy mit nem PHP-ben fogsz csinalni.

Tyrael

Minden csak annak a fuggvenye hogy hogy hasznalod. Igaz rubyba nem astam igazan bele magam csak megnezegettem par video tutorialt ami fent volt a hivatalos oldalon (marmint itt most ruby on railsrol beszelek leginkabb), ahol az urge nekiallt ruby hivasokat rakni meg a template htmlekbe is. Szerintem meg ez nem szep. Lehet mashogy is csinalni? biztos, de o most csak tutorialt mutogatott, ez van. En peldaul elegge megkedveltem a spring frameworkot mikor javaval dolgoztam, es most hogy megint phpval dolgozom, nekialltam azt a technikat/strukturat kovetni amit ott hasznaltam, tobb-kevesebb sikerrel (inkabb tobb). template oldalon meg osszedobtam egy view kezelo classt ami nagyjabol tudja amit az alap JSTL Core tag lib, aztan ha nosztalgiazni akarok akkro azt hasznalom. Igy legalabb a view majdnemhogy cieplheto a 2 kozott.
Mindenben lehet ronda kodot irni, es szerintem mindenben lehet szepet is irni. phpban leginkabb az egyszeruseget szeretem, foleg tombok teren. Aki szenvedett mar egymasba agyazott hashmapekkel javaban az tudja mire gondolok

Meg lehet oldani szepen is, csak egy tutorial nem arrol szol, hogy hogyan dolgozzunk szepen. Ami fenn van a neten 15 minute tutorial, az abba levo technikak jo reszet nem alkalmaznam mar eles siten, de arra jo volt, hogy az ember megtanulja, hogy is mukodik a dolog.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( zoner | 2010. február 10., szerda - 11:17 )
Ha már ez a szakmája, hobbiból miért nem próbál ki egy Ruby-t vagy Python-t
@

Nemi prekoncepcio azert felfedezheto abban, hogy szerinted aki szepnek talalja a PHP -t az meg hobbi szinten sem probalt mast! :)
Gondolom itt abbol indulnak ki az emberkek, hogy van valamilyen megoldasuk egy feladatra akkor megis minek kene masik megoldast keresniuk? Persze ez szinten nem nyelvspecifikus, ugyan ugy ervenyes Ruby, Python fejlesztokre is. Toluk is megkerded, hogy miert nem probaljak azokat a feladatokat amikre mar van kesz megoldasuk, megoldani mondjuk PHP -ben?
Masik nyelvnek akkor lesz jelentosege igazabol, amikor egy adott nyelven nem letezik elerheto megoldas [mindegy h milyen okbol: kompetencia, kulso policy, stb] egy feladatra. De ha egy fejleszto ceg szempontjabol is nezem a dolgot, akkor a cegnek sem erdeke, hogy olyan megoldasokat preferaljon amik indokolatlanul hasznalnak kulonbozo megoldasokat a kulonbozo projekteknel azonos feladatra. Es ez nem csak a nyelvek kozotti valasztasra igaz, hanem meg az egy nyelven beluli megoldasokra is.

( zoner | 2010. február 10., szerda - 0:05 )
próbálja meg valaki megmagyarázni egy pizzéria tulajdonosának, hogy az 500Ft-os tárhelyet, amit kinézett nem lesz jó, mert csak PHP-t tud :)
@

Kepzelem a szamitasi kapacitast, funkcionalitast amit egy pizzeria honlapja igenyel...LOL. A pizzeria tulajdonosanak legyen mar jo az 500 Ft -os php -s tarhely. Ha mar neki sem, akkor megis kinek lenne jo?

neha ijeszto vagy. :)
a vicc az, hogy hup-rol tobb ilyen mentalitasu embert (ertsd: infos vagyok, ami nem ugy mukodik, ahogy en csinalnam, vagy elso ranezesre nem ertem miert ugy van, az szar.)
mit szolsz hozza, hogy js-ben nem kell ; a parancsok vegere, mert az ujsor is jo, es bashben?
alahuznad azt is vastagon?
halisten/sajnos a nyelveket a piaci igenyek alakitjak, nem pedig a hozzad hasonlo megmondoemberek igenyei.
a fajl vegen ugyis leall a php parser, ezert nyugodtan opcionalissa tehettek a nyelv iroi a zaro ?> kitetelet.
es sok editor be szokott rakni minden megnyitott fajl vegere egy ujsort, amire ha nem figyel az ember es amugy ott a lezaro ?>, akkor kimenetkent a kepernyore kerul, es mokas dolog az ilyet debugolni.

Tyrael

"ki mit sporol meg ezzel a ket karakterrel?"

szerintem egy csomo fejfajast probalnak megsporolni
a zaro tag elhagyasa azt jelenti, hogy akarhany whitespace lehet a file vegen, a parser eof-ig dolgozik, es nem fog semmi kikerulni a kimenetre, amig le nem futott minden ami az adott file-ban van
arrol viszonylag egyszeru gondoskodni,hogy a nyito tag a legelso karakteren kezdodjon, a zaro tag utani whitespace-t kiszurni mar nehezebb
es ha csak egyetlen enter is kikerult a kimenetre, lottek a cookiek beallitasanak, headerek kikuldesenek, atiranyitasnak, sessionkezelesnek, stb.
ezert kezdodik nalam az index.php ugy, hogy <?php ob_start(); es minden mast innet include-olok

( Yorirou | 2010. február 8., hétfő - 23:11 )
tényleg elég gáz bugokat tud okozni
@

Milyen 'gaz bugokat' konkretan [vagyis _nem_ peldaul]?

Mert ha hasznalsz zarotagot es utana van egy ures sorod es includolod ezt a fajlt, akkor kinyomja a fejleceket mivel az mar output lesz.
Ezt konnyen meg lehet szivni.

"- a PHP fajl vegerol elhagyni a ?> -t... hat nem tudom, ez elsosorban 1) php parser bug, fixalni kene... 2) miert is tartozik ez a reszlet a programozora? 3) Ha mar van nyito tag, sok IDE megkoveteli a zaro taget, kulonben alahuzza az egesz kodot, es nincs szintaxisellenorzes (ez persze a legrosszabb eset, de erre is fel kene keszulni). "

Tudod milyen idegesítő, mikor egy ?> után maradt szóköz vagy enter miatt szív az ember?

1) Nem bug.

2) Miért kell C#-ban kirakni a {} -ket? Az is csak nyelvi elem.

3) Az, hogy fos az IDE, arról nem a PHP fejlesztői tehetnek (melyik volt az az IDE?)

3.1) Inkább a nyitó taget el kellene törölni. Most vagy PHP kódot parseolunk, vagy mást.

----------------
Lvl86 Troll

Szia!

A ?> záró részt azért kell elhagyni, hogy még véletlenül se kerüljön whitespace karakter a fájlban a php kód mögé. (Mert akkor később már nem tudsz headert beállítani, és a hibát debuggolni sem olyan egyszerű, ha sok fájlod van.) Egyébként ennek semmi köze szerintem a kód átláthatóságához.

( kisg v | 2010. 02. 09., k – 14:11 )

Szia,

Én mindenképpen javasolnám a Zend Framework-öt. Nagyon sok olyan tervezési mintát használ, amik más rendszerekben is hasonlóak.

CMS részről én is javasolnám a Drupalt, szerintem a 6-os sem csúnya, könnyen átlátható.

PHP perzisztencia rétegnek nagyon kellemes a Doctrine. Az összes ORM minden platformon hasonlóan működik, tehát már csak-e miatt is érdemes megismerkedni vele. A Drupal 7 DB:TNG sem tűnik rossznak az előadások, dokumentációk alapján.

Csúnya, "ezt így ne csináld" kódnak pedig a vTigert ajánlom.

Nem tudom, hogy milyen feladatot akarsz megoldani, de a 0-ról, vagy akár egy frameworkből indulás helyett lehet, hogy pl. Drupal-ból kiindulva jobban jársz:
- sokkal többet tudsz a feladat érdekes részeire koncentrálni, ha olyan dolgokat, mint pl. formkezelés nem kell újra feltalálni.

Üdv,
Gergely

( kisg | 2010. február 9., kedd - 14:11 )
Én mindenképpen javasolnám a Zend Framework-ö/.../ olyan dolgokat, mint pl. formkezelés nem kell újra feltalálni
@

Nos ZF -t persze szokas dicserni...miert is? Mert hasznal tervezesi mintakat?...vagy a f@sz tudja. Attol meg eleg silany dolgok vannak benne. Raadasul tul van bonyolitva..Mert pl a Zend_Form -ot nyugodtan ujra lehetne irni! Talan a sajat interfaceivel kompatibilisnek kene maradnia!
Mar eleve tok rohej, hogy ugy kepzeltek el a beviteli mezok csoportjanak [group] egyuttes validaciojat [pl password password-ujra egyezes a regisztracional], hogy a csoport egyik mezojenel beallitott szabalynal kene isValid fgv. -ben a validationContext -bol kibanyaszni a tobbi a elemet. Apro szepseghiba, hogy igy a tobbi mezore beallitott filterek mintha nem is lennenek, vagyis igy csak a raw ertekekhez lehet hozzaferni, de ez mind semmi ahhoz kepest, hogy a Zend_Validate_Interface nem is engedi isValid fgv -nekl a masodik (validationContext) parametert. Az meg mar csak hab a tortan, egyben a PHP szegenysegi bizonyitvanya, hogy ennek ellenere elerheto a func_get_args() meghivasaval. LOL :DD

( kisg | 2010. február 9., kedd - 14:11 )
CMS részről én is javasolnám a Drupalt
@

Oszinte reszvetem! En mindig megremulok, h vannak akik ilyesmik hasznalatara kenyszerulnek. Ugy vagyok ezzel a drupal nevu izevel, mint a Tina Magazinnal. Nem kell hozza ismernem, hogy tisztaban legyek a nivojaval. Eleg amit lattam belole anno...egy eletre elment a kedvem tole:
user jogosultsagok sessionben valo tarolasa, kulonbozo adatok serializalt tombkent valo tarolasa az adatbazisban, stb..

Ugy vagyok ezzel a drupal nevu izevel, mint a Tina Magazinnal. Nem kell hozza ismernem, hogy tisztaban legyek a nivojaval. Eleg amit lattam belole anno...egy eletre elment a kedvem tole:
user jogosultsagok sessionben valo tarolasa, kulonbozo adatok serializalt tombkent valo tarolasa az adatbazisban, stb..

Ez mikor volt? A szerializált adat miért baj? Mármint szerinted.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( nevergone | 2010. február 10., szerda - 8:32 )
A szerializált adat miért baj? Mármint szerinted.
@

Gondoltam ez nyilvanvalo, de akkor megprobalom elmagyarazni. pl Egy szep napon megker a fonokod, h exportaljad ki az akarmilyen site felhasznaloinak adatait excel tablazatba. Erre lelkesen elinditod a kedvenc adatbazis kezelo alkalmazasodat, a kivant tablahoz navigalsz, majd megdobbenve tapasztalod, h a felhasznalok tulajdonsagai serializalva vannak tarolva egy mezoben. Ami igazan meglepo, ellenben a legkevesbe sem mulatsagos. Suru anyazasok kozepette nekiallhatsz kodot irni...Es ezen tapasztalat aztan a kesobbiekben meglehetos ovatossagra int, ha pl olyasmi kerul szoba, hogy egy Javaban irt webszerviz turkaljon drupalos site adatbazisaban...
Azert bizonyos esetekben akar megengedheto lenne, hogy nyelvspecifikusan taroljanak le adatokat, teszem azt pl temporary dolgoknal, cachenel. De egyebkent ez alapveto tervezesi prolemakra utal.

Az elobbi konkret eset volt (de ezen kivul is lattam serializalt adatokat). Lovesem nincs a verziorol. Es csak annyibol van jelentosege verzionak, hogy a drupal fanok akik szerint a drupal a kiraly CMS, hirtelen ugy valtoztathassanak velemenyt, hogy drupal a kiraly CMS az x.y verziotol. :-D

Értem. Amúgy elárulom, hogy a belső változótól és a cache-tól eltekintve mindent rendesen, saját táblában tárol. Szóval nem tudom, hogy te melyik verzióban és mit akartál machinálni, bár a Drupalnak van szép és jól dokumentált API-ja direkt azért, hogy azon keresztül kérd le az adatokat.
Részemről ennyi ez a thread.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Nyilván, de erre meg azt mondom sarkítva, hogy ha van API, akkor mi köze ahhoz, hogy a rendszer mit és hogyan tárol, amíg megbízhatóak és gyorsan végzi a dolgát? Nyilván ebben az esetben is többféle (rész)igazság létezik.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

eleg mazochista lehetsz, ha megirod a zend formjaidhoz a validatorokat is.
en hamar leszoktam errol, inkabb egyesevel validalom a $_POST-bol kibanyaszott mezoket, es igy legalabb egyszeruen meg tudom kulonboztetni az add es az edit eseteket. a decorator-ok is egy nagy hanyas, nem lehet ertelmesen stilusozni vele az elemeket. legalabbis nekem nem sikerult, es a neten is hiaba kutattam helloworldnel bonyolultabb peldak utan.

( barii | 2010. 02. 28., v – 14:18 )

Sziasztok!

perpillanat 2 dolog foglalkoztat a témával kapcsolatban:

Mondjuk, hogy megvan egy hírek modul, meg van egy blog modul, meg van egy commentek modul külön-külön. .../news/show/21-re a 21. hír jelenik meg, /blog/show/12-re a 12. blog, de anélkül akarom alá tenni a kommenteket, hogy bele keljen nyulni a darabokba. Akkor ezt megcsinálhatnám pl úgy, hogy van egy osztály, ami nézegeti, hogy milyen modult akarok betölteni, és ha olyat, ami kommentezhető, akkor alá teszi a komment medult. De akkor ezt hogy? Egy XML-be vagy php tömbbe kéne tennem, hogy melyik modul melyik metódusa alatt kéne, hogy megjelenjen melyik "kiegészítő modul", mint pl komment vagy szavazás? Elég furán hangzik.

Egy modulnak több megjelenése van, pl itt a hup-on a fórumnak van a téma lista, altéma lista, a konkrét thread, a jobb oldali utolsó hozzászólások, stb. Akkor hogy érdemes? Több modulra bontani, és külön modulokba tenni a listákat, a thead-et, jobb oldalt? ez nem tűnik ésszerűnek. Vagy egy közös kontrollal több view fájlal? vagy egy osztályba, ahol több view metódus van?

a drupalben nem akarom megnézni, mert nem látom át, és nem is oo. Más CMS-eket szeretnék nézni, már megvolt. _Ti_ hogy csináltátok?
---
dropbox tárhely igénylés: https://www.dropbox.com/referrals/NTMwMDYwODE5

( asch v | 2010. 03. 04., cs – 11:38 )

Ha nem csak PHP körben, hanem általánosságban is érdekelnek a modul keretrendszerek, akkor nézz utána az OSGI keretrendszernek, illetve az Eclipse extension mechanizmusának. Mindkettőről nagyon jó cikkeket lehet találni neten.

( penztar v | 2010. 03. 04., cs – 12:29 )

Hello!

Bocs hogy beleronditok a topicba ,de én is szakdolgozat meg php cipőben járok. Fentebb valaki megjegyezte hogy userid-t nem igazán jó dolog $_SESSION-ben tartani. Én pont azt a tanácsot kaptam hogy a felhasználó kezelést ilyen módszerrel oldjam meg. El tudná valaki mesélni hogy miért nem egészséges?Hátha a topik indítónak is a hasznára válik majd.

Üdv.
ps: Én nem webshopozom hanem hup like hirportált csinálok. Persze csak az ötlet azonos.

Random generált és elég hosszú userid esetén nem gond szerintem. Maga a fő probléma hogy adatot kell tárolni a user gépén ami ha nem elég furfangosan van kitalálva, egy támadó személy ki tudja játszani. Sarkítok: Cookie-ban átírod a userid-t 0-ra -> admin user. Badarság, de azt hiszem jól szemlélteti a problémát.

Mi köze a $_COOKIE-nak a $_SESSION-hoz? Cookieban _semmit_ nem tárolunk egy session ID-n kívül.

Sessionban annyit érdemes még eltárolni, hogy mi a session ID-je az usernek, mikor új sessiont nyit.

Így nem lehet megjátszani azt, hogy ellopod valakinek a session ID-jét és beírod a böngésződbe (session hijacking). (Mondjuk én tárolom még az IP és az user agentből készült hasht is).

----------------
Lvl86 Troll

( junior013 | 2010. 03. 05., p – 09:53 )

Szintén hasonló cipő, egy web alapú CMR rendszernek szeretnék nekiesni, részben tanulás, részben "kényszer" miatt, de ha jól alakul, még szakdolgozatnak is jó lehet :)

Úgy vélem, ide már az eddig alkalmazott "fejlesztési" megoldásaim (rendszerterv fejben, lekódolva text editorral, stb.) édes kevesek, előkerülnek a Framework, IDE, VersionTracker, stb. kulcsszavak.
Kérdésem: a fentiekből ki mit ajánl egy PHP/MySQL/AJAX fejlesztéshez?

Fw.-k közül eddig a Zend-et nézegettem, de előkerült itt feljebb a CakePHP is. Tudom, részben hitvita, de vajon melyik az alkalmasabb?
IDE-ből a Netbeans-t már használtam, de nem PHP-hez. Mennyire jó? Vagy inkább mással érdemes kezdeni?
Verziókezelőből erre vonatkozó fórumtémáknál a Git-et favorizálták nagyon. Jogos? Vagy ehhez inkább mást?

Java-s IDE-ből a NetBeans a legjobb szerintem, én is azt használom.
Keretrendszer: Kohana
SCM: git
js framework: jQuery

Illetve ha adatbázist is tervezni akarsz, akkor MySQL Workbench, nagyon megkönnyíti a munkát, tud éles adatbázist is frissíteni, ha átterveztél valamit.

--
http://sandor.czettner.hu

Hát én 1-2 napig játszottam symfony-val, de nagyon kevés ennyi idő ahhoz, hogy akár egy blogot is csináljak vele. Kohana valamivel fapadosabb, de sokkal gyorsabban megtanultam.

A symfony sebességét ugyan nem mértem, de képzelem milyen lehet a sok fájlt végigolvasni minden egyes oldalletöltéskor.

--
http://sandor.czettner.hu

( penztar v | 2010. 03. 05., p – 15:28 )

Hello!

Én is a netbeans-t használom a php kódoláshoz. Azt viszont hiányolom benne nagyon hogy nincs benne olyan funkció hogy a php függyvényeknél nincs hinting meg pop-up ablak a signatúrájával. Ugye ez a történet ha java a nyelv akkor meg van. De amúgy jó a dolog és azt is szeretem benne hogy ha kész a kód akkor egyből fel is tudom lökni ftp-vel a tárhelyre a kódot. Mondjuk ehhez le kellett tölteni egy külön plugint de ez nem nagy gond.

Üdv.

( djszapi | 2010. 03. 05., p – 16:23 )

Senki nem emlitette meg a django-t, szerintem nagyon korrekt es jol dokumentalt, nyitott forrasu keret rendszer pythonban, talan erdemes megnezni, ha nem akkor bocsi.

http://djszapi.homelinux.net

( r0by | 2010. 03. 06., szo – 16:02 )

Nekem a netbeans helyett az aptana studio jobban bejön. Igaz a 2-es verzióból kikerült a közvetlen php támogatás, csak a netbeanshez elérhető pdt-t lehet felrakni. Így az 1.5-öst kell használni, amiben szvsz jobb a php támogatás.

( arth2o | 2010. 04. 20., k – 06:31 )

Nem az a kérdés hogyan kell megvalósítani egy ilyet, hanem az hogy Te mennyire értesz a PHP-hez.

Ha nagyon és vágod az OOP-t akkor:
http://codeigniter.com és ez a bártod: http://codeigniter.com/wiki/Modular_Extensions_-_HMVC/

Ha nem értesz az OOP programozáshoz akkor:
* Csinálsz egy rakat függvényt
* kitalálod a moduláris felépítésed mappa szerkezetét
* kitalálod az URL struktúráját a rendszerednek.. melyik paraméter mit jelent..
* törekedsz a biztonságos fejlesztésre (ellenőrzöl minden mint az őrült)

URL: egyik paraméter mindig a modul neve:

pl.: /pages/akarmi_oldal

Fájlrendszer
- /modulok
-----------/pages/
------------------pages.php
- /sablonok
- /css
- index.php
- .htaccess

.htaccess-ben ráirányítod az index.php-re minden kérést (mod_rewrite)

index.php-ben
Vizsgálod az első paramétert és behívod az adott modult ha létezik, ha nem akkor haktivity van.

Nekem van ilyen és olyan rendszerem is. Mind a kettőnek meg van az előnye. A sajáthoz rendkívül egyszerű fejleszteni, viszont a másikban nem kell feltalálni a kereket.

arth2o: http://keszit.es