- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Vezetékes FEJhallgatók
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Androidos tablet topic
- OLED monitor topik
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Hisense LCD és LED TV-k
- Hobby elektronika
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
Új hozzászólás Aktív témák
-
#13200
Peter Kiss
őstag
Speeedfire
#13199
Peter Kiss
őstag
válasz
Speeedfire
#13199
üzenetére
Ez egy eszköz, mint a Notepad vagy a Netbeans.
-
#13199
Speeedfire
félisten
DeltaPower
#13198
Speeedfire
félisten
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?
-
#13198
DeltaPower
addikt
Speeedfire
#13197
DeltaPower
addikt
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.
-
#13197
Speeedfire
félisten
Sk8erPeter
#13195
Speeedfire
félisten
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.
-
#13196
tildy
nagyúr
Sk8erPeter
#13195
tildy
nagyúr
válasz
Sk8erPeter
#13195
üzenetére
Mi eddig mindenhol kezzel irtuka layoutot.
-
#13195
Sk8erPeter
nagyúr
#36268800
#13193
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. -
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.
-
#13193
#36268800
törölt tag
Peter Kiss
#13190
#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?
-
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 ?
-
#13190
Peter Kiss
őstag
#36268800
#13189
Peter Kiss
őstag
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).
-
#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?
-
#13188
Speeedfire
félisten
Sk8erPeter
#13187
Speeedfire
félisten
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.
-
#13187
Sk8erPeter
nagyúr
Speeedfire
#13186
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.
-
#13186
Speeedfire
félisten
modder
#13184
Speeedfire
félisten
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.
-
#13185
DeltaPower
addikt
Speeedfire
#13183
DeltaPower
addikt
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?
-
#13184
modder
aktív tag
Speeedfire
#13183
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.
-
#13183
Speeedfire
félisten
modder
#13182
Speeedfire
félisten
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.
-
#13182
modder
aktív tag
Speeedfire
#13181
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)
-
#13181
Speeedfire
félisten
modder
#13179
Speeedfire
félisten
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á.
-
#13180
Speeedfire
félisten
cucka
#13177
Speeedfire
félisten
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.
-
#13179
modder
aktív tag
Speeedfire
#13176
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.
-
#13178
Sk8erPeter
nagyúr
Speeedfire
#13176
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?
-
#13177
cucka
addikt
Speeedfire
#13176
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.
-
#13176
Speeedfire
félisten
vgyuri
#13175
Speeedfire
félisten
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? -
#13175
vgyuri
őstag
Speeedfire
#13174
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. "
-
#13174
Speeedfire
félisten
Speeedfire
félisten
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?
-
#13173
fordfairlane
veterán
Vision
#13155
fordfairlane
veterán
válasz
Vision
#13155
üzenetére
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.
-
#13172
fordfairlane
veterán
Dave-11
#13159
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.
-
#13169
syC
addikt
Peter Kiss
#13152
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?
-
#13167
Soak
veterán
Speeedfire
#13165
Soak
veterán
válasz
Speeedfire
#13165
üzenetére
shop.example.com ...
-
#13166
Sk8erPeter
nagyúr
Dave-11
#13164
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ó. -
#13163
Siriusb
veterán
Speeedfire
#13162
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?
-
#13162
Speeedfire
félisten
Peter Kiss
#13160
Speeedfire
félisten
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.
-
Dave-11
tag
válasz
Peter Kiss
#13160
üzenetére
Most miért?
-
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? -
#13156
Peter Kiss
őstag
Vision
#13155
Peter Kiss
őstag
válasz
Vision
#13155
üzenetére
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?
-
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?
-
#13154
#68216320
törölt tag
Tele von Zsinór
#13153
#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.
-
#13153
Tele von Zsinór
őstag
#68216320
#13150
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.
-
#13152
Peter Kiss
őstag
syC
#13151
Peter Kiss
őstag
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.
-
#13151
syC
addikt
Peter Kiss
#13149
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?
-
#13150
#68216320
törölt tag
Tele von Zsinór
#13147
#68216320
törölt tag
válasz
Tele von Zsinór
#13147
üzenetére
mysqli-t használok. Oké, tehát a real_escape_string lesz a megfelelő. Köszönöm. Gyakorlatilag kiírás előtt végigpörgethetem egy POST tömbön is, nem?
Így gondoltam:
foreach($_POST as $key => $item) {
$_POST[$key] = $mysqli->real_escape_string($item);
}Egy csomó modul POST-ot használ, macera volna átírni.
-
syC
addikt
Üdv!
Hogyan tudom elérni fájl olvasásnál, hogy a gépről bármely fájlt kiválasztva működjön az olvasás, ne csak a szkripttel egy mappában levőkkel? 'Rá lehet venni' valahogy <input type="file"-t, hogy ne csak fájlnév.kit -értékkel térjen vissza, hanem a teljes ( pl. C:\Lószerszám\fájl.kit elérési úttal), vagy máshonnan kell megközelíteni a dolgot?
-
#13147
Tele von Zsinór
őstag
#68216320
#13146
Tele von Zsinór
őstag
válasz
#68216320
#13146
üzenetére
Ha szöveget viszel az adatbázisba, akkor azt escape-elni kell, az addslashes() erre nem megfelelő. Ha az elavult mysql függvényeket használod, akkor a mysql_real_escape_string() a barátod. Ha modern technológiát használsz, akkor a mysqli vagy a PDO prepared statementjeinek nézz utána (attól függően persze, melyikkel dolgozol).
A problémád azonban valószínűleg másutt van - tippre mire hozzád kerül az adat, addigra már ott vannak benne a perjelek. Kapcsold ki a magic_quotes-t.
-
#68216320
törölt tag
Úgy tudom, ha szöveget viszek adatbázisba illik az addslashes() függvényt használni. Viszont úgy tudtam, ez csak az átvitel idejére kell, adatbázisban ez nem tárolódik. Viszont nekem most minden html kód így néz ki az adatbázisban:
<a href=\"hello.php\">hello</a>
Megjelenítéskor stripslashes(), ez oké, de feltétlen így kell ennek az adatbázisban mutatnia? Mit csináljak másképp?
-
#13144
Sk8erPeter
nagyúr
fordfairlane
#13138
Sk8erPeter
nagyúr
válasz
fordfairlane
#13138
üzenetére
Igen, ebben igazad van. Habár kérdés, hogy valósítja meg valaki, hol keletkezzen a fatális hiba, vagy akár egy exception mondjuk itt, akkor, ha a fájl nem létezik, vagy akkor, amikor példányosítani akarja valaki az osztályt.
-
#13143
Peter Kiss
őstag
H.O.D.
#13136
Peter Kiss
őstag
válasz
H.O.D.
#13136
üzenetére
Mindkettő rossz. Active record-nak hívják, akárhogy is csinálod, ahol az entitásod egyben felel azért, hogy mentve legyen minden adott típusú elemed, illetve a lekérdezésért is ez felel. Az ilyen jellegű keveredések károsak.
Ha a legegyszerűbb értelmes megoldást szeretnéd, akkor kell
valami, ami kezeli a "tárhelyet" (adatbázis backend mellett ez jelenti az adatbázis-kapcsolatot, illetve a query-k végrehajtását),
valami, amivel le tudsz kérdezni, menteni tudsz (DAO),
és az entitásod (Product) -
cucka
addikt
válasz
H.O.D.
#13136
üzenetére
Tehát egy statikus osztálynak nincs is __construct metódusa,
PHP-ban nincs olyan fogalom, hogy statikus osztály. Felejtsd el.
Minden osztálynak van __construct metódusa. Ha te nem írod meg, akkor a PHP csinál neki egy alapértelmezett üres metódust.Szerintem fogj egy PHP-s könyvet, ami az OOP-ra van kihegyezve, és olvasd el. Továbbra is ott tartunk, hogy írsz valami kódot, amiben vannak OOP-s kulcsszavak, de az egésznek semmi értelme OOP szemszögből.
Egy Product osztály az OOP irányból nézve nem a termékekkel kapcsolatos segédfüggvények gyűjteménye, hanem egy termék reprezentációja a kódodban. Egy Product objektumban tehát nincs getProduct() metódus, mert maga a Product objektum a termék. Az adattagok a termék adatai, a metódusok pedig a terméken végezhető műveletek. Ezt figyelembe véve a kérdésed blődség, teljesen irreleváns, hogy statikus vagy nem statikus az a metódus, aminek semmilyen keresnivalója nincs a termék osztályban.
Persze, biztos össze tudsz kalapálni szaktudás nélkül is valamit, ami úgy-ahogy működik és vannak benne OOP kulcsszavak, csak nem ez a jó irány.
-
#13138
fordfairlane
veterán
Sk8erPeter
#13137
fordfairlane
veterán
válasz
Sk8erPeter
#13137
üzenetére
Szerintem nem kell. Ha olyan osztályra hivatkozik a programjában, aminek az implementációja nincs meg, akkor az fatális hiba.
-
#13137
Sk8erPeter
nagyúr
fordfairlane
#13135
Sk8erPeter
nagyúr
válasz
fordfairlane
#13135
üzenetére
Gondolom csak szemléltetés akart lenni, de sztem nem árthat egy
if(file_exists('classes/' . $class . '.class.php')){
// ...
}
ellenőrzés is előtte, végül is a file_exists() relatíve gyors. -
H.O.D.
senior tag
Kezd világos lenni. Tehát egy statikus osztálynak nincs is __construct metódusa, ez akár hellopisti() is lehet és az "inicializálás" is csak annyiból áll, hogy az osztály értékeinek beállítására ezt a metódust használom és a többi metódus ezzel dolgozik tovább.
A lényeg, amit el akarok érni, egy interface, ahol teszem azt. termék paramétereket akarok lekérni egy id alapján, pl.:
$a = Product::get($id);
vagy használjak "hagyományosat":
$n = new Product;
$a = $n -> get($id);Melyik a jobb megoldás?
-
#13135
fordfairlane
veterán
H.O.D.
#13126
fordfairlane
veterán
válasz
H.O.D.
#13126
üzenetére
Értelmes fellelhető forrás hiányában arra gondoltam, ez megtörténik az osztály bármely metódusának/elemének használatakor.
Tudomásom szerint erre nincs beépített automatizmus, osztály használatakor nem történik ilyesfajta inicializálás. A konstruktor példányosításkor hívódik meg.
A PHP osztálybetöltő mechanizmusa viszont testreszabható, így megoldható egyfajta osztálybetöltő és inicializáló kódrész. Mondjuk ha __init-nek hívod, akkor valami ilyesmivel pl:
<?php
spl_autoload_register(function ($class) {
include 'classes/' . $class . '.class.php';
if(is_callable($class, '__init')) {
$class->__init();
}
});
?> -
wolandino
tag
Sziasztok!
Excel-t szeretnék exportálni PHP-ból.
Formázni szeretném a létrehozott táblázatot.
Ehhez a PHPExcel könytárat szeretném használni.
Az egyik kérdésem az lenne, hogy megfelelő eszközt választottam-e?
A másik, hogy hogyan tudnám megoldani, hogy olyan számokat jelenítsen meg az excel, ahol pont és nem vessző a tizedesválasztó?
Mert eddig vagy dátumot csinál belőle, vagy nem fogadja el számként.
Köszönöm,
W. -
cucka
addikt
válasz
H.O.D.
#13126
üzenetére
Statikus adattagot így tudsz inicializálni:
class Test{
static $data = 5;
}Nyoévám me, példányosítással, de akkor hogyan?
A statikus adattagok/metódusok az osztályhoz köthetők, nem az objektumpéldányhoz. Tehát pont az a lényeg, hogy függetlenek attól, hogy létrejön-e akár 1 példány abból az osztályból vagy sem.arra gondoltam, ez megtörténik az osztály bármely metódusának/elemének használatakor.
A statikus adattag akkor jön létre, amikor az osztály kódját értelmezi a php.
Ezt próbáld meg megérteni: a statikus adattag az lényegében egy globális változó. A trükk, hogy becsomagolod egy osztályba, az osztály nevén keresztül tudod elérni, így nem szennyezed a globális névteret. Egy osztály, ami csak statikus dolgokat tartalmaz, az lényegében nem egy osztály, hanem egy névtér. Akkor használunk ilyet, ha
- a nyelv nem támogatja a névtereket (pl. régebbi php verziók)
- a nyelvben nincsenek globális változók (pl. java)__autoload()-dal töltöm be, ha abba teszek egy xy::__construct()-ot, az lehet megoldás?
Nem. Az autoload arra van, hogy megtaláld a hivatkozott osztály file-ját és include-old. A konstruktor meg az a speciális metódus, amely egy osztály példányosításánál fut le. A kettőnek semmi köze egymáshoz. -
#13131
rt06
veterán
Speeedfire
#13130
rt06
veterán
válasz
Speeedfire
#13130
üzenetére
-
#13130
Speeedfire
félisten
Speeedfire
félisten
Hülye kérdés, de van valami beépített függvény arra, hogy egy adott tömb elemének indexét megkapjam?
$tomb = array("egy", "ketto", "harom");
tomb_erteke("egy"); // return 0
tomb_erteke("ketto"); // return 1 -
H.O.D.
senior tag
Hogy mit tudok és mit nem, azon most ne témázzunk, nem ez volt a kérdés. Ha egy 15 éves megkérdezi, mi az az OTTO motor, elmondod neki, vagy elküldöd a fenébe, mert nincs jogosítványa?
Tekintsünk el a kódtól, első próbálkozás statikus osztályokat illetően, nyilván nincs kész, de arra
megfelelő volt, hogy megértsem az elvet.Tehát akkor a kérdés: hogyan kell/lehet, oééetve lell-e egy statikus osztályt inicializálni? Nyoévám me, példányosítással, de akkor hogyan? Értelmes fellelhető forrás hiányában arra gondoltam, ez megtörténik az osztály bármely metódusának/elemének használatakor.
__autoload()-dal töltöm be, ha abba teszek egy xy::__construct()-ot, az lehet megoldás?
Köszi előre is!
-
#13125
Sk8erPeter
nagyúr
rt06
#13123
Sk8erPeter
nagyúr
Volt hosszas témázás róla itt a topicban, érdemes lenne átfutnod:
http://prohardver.hu/tema/php_kerdesek_2/keres.php?stext=singleton -
#13122
cucka
addikt
fordfairlane
#13121
cucka
addikt
válasz
fordfairlane
#13121
üzenetére
Én nem javasolnék singletont ilyen esetben. Meg úgy őszintén, jól el kell gondolkoznom, hogy mikor fordult elő utoljára, amikor singletonra lett volna szükségem. Attól, mert egy osztályból várhatóan csak egy példány lesz, még nem indokolt a singleton használata.
-
#13121
fordfairlane
veterán
H.O.D.
#13119
fordfairlane
veterán
válasz
H.O.D.
#13119
üzenetére
Használhatsz Singletont.
<?php
class Osztaly {
private $prop1;
private $prop2;
private function __construct() {}
public static function getInstance() {
static $instance = null;
if($instance == null) {
$instance = new Osztaly();
}
$instance->prop1 = "ezt belerakom";
$instance->prop2 = "ezt meg ide";
return $instance;
}
public function getProp1() {
return $this->prop1;
}
public function getProp2() {
return $this->prop2;
}
}
$o = Osztaly::getInstance();
$o2 = Osztaly::getInstance();
var_dump($o === $o2);
?> -
cucka
addikt
válasz
H.O.D.
#13119
üzenetére
Igazából a probléma, hogy a kódod tele van OOP kulcsszavakkal, csak jól láthatóan nem igazán tudod, mire használd ezeket.
Egyrészt, amit írsz, az nem OOP kód, lényegében egy namespace-t készítesz egy osztályba csomagolva. Ennyi erővel akár használhatnál namespace-t is.
A másik, hogy a kódodból és a hosszászólásodból jól látszik, hogy az alapvető OOP-s fogalmak hiányoznak, tehát első körben javaslom, ezeket pótold be. (Például a konstruktort nem manuálisan hívod, hanem példányosításnál fut automatikusan. Statikus adattagok konstruktorban történő inicializálása azt jelenti, hogy nem érted, mit jelent a static kulcsszó.). Nehéz úgy segíteni, ha nem egy bugot kell kijavítani, hanem ilyen alapvető gondok vannak a kóddal. -
#13119
H.O.D.
senior tag
fordfairlane
#13118
H.O.D.
senior tag
válasz
fordfairlane
#13118
üzenetére
Azt sejtettem, hogy hibás...
Mit tegyek, hogy ne kelljen a konstruktort manuálisan meghívni? Megoldható egyáltalán? Egy csomó keretrendszerben láttam ezt a megoldást, de lehet, hogy valami alapvető dolog kerüli el a figyelmemet. -
H.O.D.
senior tag
Sziasztok, akadt egy kis static class problémém. A kód:
<?php
class Portal
{
static $row;
private function __construct()
{
self :: $portal = "";
self :: $language = "";
self :: $currency = "";
self :: $row = self :: set();
}
private static function set()
{
$db = Db :: getInstance();
$bind = array($_SERVER["HTTP_HOST"]);
$res = $db -> getPortalByURI($bind);
return $res;
}
public static function getPortalId()
{
return self :: $row["id"];
}
public static function getPortalLanguage()
{
return self :: $row["nyelv_id"];
}
public static function getPortalCurrency()
{
return self :: $row["penznem_id"];
}
}
?>Namármost, annyi van, hogy a $res-ben ott csücsül a rekord, ami nekem kell, de a $row változóba nem kerül be. Így néz ki a főprogram-részlet:
$portal = Portal :: getPortalId();
$lang = Portal :: getPortalLanguage();
$curr = Portal :: getPortalCurrency();Mit cseszek el?
-
#13116
Sk8erPeter
nagyúr
Speeedfire
#13115
Sk8erPeter
nagyúr
válasz
Speeedfire
#13115
üzenetére
Ebben a topicban úgy látszik, már nem lehet KORRIGÁLNI egyes mondatokat a helyes infók érdekében, mert valaki biztos, hogy magára veszi.
Miért lenne "belekötés" egy egyszerű korrekció? -
#13115
Speeedfire
félisten
Sk8erPeter
#13114
Speeedfire
félisten
válasz
Sk8erPeter
#13114
üzenetére
Mindegy, a lényeg, hogy jQuery.
Meg amúgy is, most ebben minek kellett belekötni?
-
#13114
Sk8erPeter
nagyúr
Speeedfire
#13110
Sk8erPeter
nagyúr
válasz
Speeedfire
#13110
üzenetére
A jQuery még mindig nem framework, hanem csak egy library...
-
#36268800
törölt tag
Üdv!
Most kezdtem el PHP-zni és az első akadályba máris bele ütköztem. (vagyis inkább hibába)
Van egy rövid kódom, ami hibásan jelenik meg:
<html>
<head>
<title> Bob autóalkatrészek - Rendelési eredmények</title>
</head>
<body>
<h1>Bob autóalkatrészek</h1>
<h2>Rendelési eredmények</h2>
<?php
echo "<p>Rendelés feldolgozva!</p>";
?>
</body>
</html>Ennek elvileg a két 'h' részen kívül ennyit kéne megmutatnia: Rendelés feldolgozva!
Ehelyett én a következőt kapom:
..h részek.. (ezek jók)
Rendelés feldolgozva!"; ?>
Vajon mi az oka ennek?
-
#13109
Vekko
aktív tag
Speeedfire
#13108
Vekko
aktív tag
válasz
Speeedfire
#13108
üzenetére
Ez sajnos számomra ismeretlen nyelv.
-
#13108
Speeedfire
félisten
Vekko
#13107
Speeedfire
félisten
Jquery ajax megoldás?
$.ajax({
'type' : 'POST',
'url' : 'http://url.hu/url.html', //url címe
'data' : 'data=1', //post adatok
'success' : function(data){ //ha van visszajelzés akkor visszaküldi az adatokat
$('#iderakdbe').html(data); //betölti az iderakdbe id-jü div-be a tartalmat
}
}); -
#13106
syC
addikt
Sk8erPeter
#13105
syC
addikt
válasz
Sk8erPeter
#13105
üzenetére
Köszi, ezek szerint baromi rosszul gugliztam ezidáig.
-
-
syC
addikt
Sziasztok!
A véleményeteket szeretnem kikérni. Adott egy tetszőleges adatbázis, valamilyen táblával. A táblában lehet auto incrementes attr. . Ebbe a táblába kellene beszúrnom új sort. Ha ismerem a tábla attribútumait, akkor nincs gond, analóg módon megy minden. Viszont az okoz fejtörést nekem, hogy bármilyen táblára működnie kell, ergo le kell kérdeznem az attribútumlistát és az alapján tudok insert into sql kérést írni. A kérdésem valójában az lenne, hogy mivel tudom kipuhatolni, hogy van-e az adott táblának auto inc-es attribútuma? Tudtommal az attr. típus lekérdezésével nem kapok választ erre a kérdésre.
Előre is köszi a választ!
-
#13102
fordfairlane
veterán
Babetta-X
#13101
fordfairlane
veterán
válasz
Babetta-X
#13101
üzenetére
Ha nem tudod előcsalogatni, akkor valószínűleg nincs is, viszont létrehozhatsz egyet. Átirányítást többféleképpen is meg lehet oldani, meta taggel, kliens-, szerveroldali sripttel. Ez a webszerveres rewrite direktívák talán a legelegánsabbak, mivel az átirányítás így rejtve marad a kliens szemszögéből.
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.
Miért lenne "belekötés" egy egyszerű korrekció? 
Új hozzászólás Aktív témák
Hirdetés
- S.T.A.L.K.E.R.: Shadow of Chernobyl
- Mibe tegyem a megtakarításaimat?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Vezetékes FEJhallgatók
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- bambano: Bambanő háza tája
- Androidos tablet topic
- Samsung Galaxy A55 - új év, régi stratégia
- Háztartási gépek
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...
- AMD Ryzen 7 7700X - Új, 1 év garancia - Eladó!
- Apple Watch ultra 2 49mm Natur Titanium, Új, 1 év Apple garanciával
- Gamer PC - R5 5600, RTX 3060 és 16gb RAM + GARANCIA
- HP Zbook 14 laptop (14FHD/I7-G5/8GB/128SSD/MagyarVilágítós)
- Jó áron ÁRON ELADÓ! Üzleti HP Elitebook 1040 G9 Laptop! / i5-1245U 16GB 256GB
- ÁRGARANCIA! Épített KomPhone Ryzen 7 5800X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Apple iPhone 13 256GB Kártyafüggetlen, 1Év Garanciával
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD RX 5700XT 8GB Rampage SHIVA Chieftec 600W
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest