játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5441
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2186
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10]
Instalok - Tag | 532 hsz       Online status #210369   2016.10.04 21:32 GMT+1 óra  
A lentebbit végül megoldottam, maradt a REQUEST_URI

Viszont kíváncsi lettem, hogy nem vettem-e észre valami függvényt, amit használok, és nagyobb verziót igényel, mint php 5.5.0, így keresgéltem a neten, találtam például ezt. Tök jó lenne, csak 2010 óta nem volt frissítve, így az 5.3 a legnagyobb verzió, amit ismer.

Van valakinek ilyesmi cucca, amivel le tudnám csekkolni az eddigieket, hogy minimum hányas verzió kell milyen extension-ökkel?

   
Instalok - Tag | 532 hsz       Online status #210360   2016.10.03 08:25 GMT+1 óra  
Aludtam rá egyet, az előzőhöz képest fél megoldás lehet az, ha nem két külön szabályom van, hanem csak simán mindent átíratok, kivéve ugye a directory és file eléréseket.
Kód:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?url=$1 [END]

Ezzel így már csak annyi gond maradt, hogy ha beírom, hogy
Kód:
test:8080/index.php?url=hello

akkor a $_GET['url'] a "hello"-t adja vissza.

Régen annyi volt a megoldásom az egészre, hogy $_GET helyett fogtam, és lekértem az url-t $_SERVER['REQUEST_URI'] segítségével, és manuálisan feldolgoztam. Így, ha valaki beírta az index.php-t utána, akkor a rewrite rule ugyan nem irányított tovább, de az url alapján nem talált valid megjeleníthető oldalt.

Azonban azt hallottam, hogy erre a változóra nem érdemes építeni. A szerver eleve vagy elküldi ezt az értéket, vagy nem, ráadásul kliens oldalon ez felülírható - ha minden igaz.
Idézet
The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here.

Idézet
'REQUEST_URI'
The URI which was given in order to access this page; for instance, '/index.html'.

   
Instalok - Tag | 532 hsz       Online status #210359   2016.10.02 23:23 GMT+1 óra  
Köszi, ez a VS Code tényleg bejött, és ez is ingyenes.

Haladtam már picit előre, most konkrétan ott tartok, hogy ilyen tök egyszerű url rewrite szabályokat írtam a htaccess-be, azonban nem értem, hogy miért matchel egy adott patternre.

Maga a htaccess file csupán ennyi:
Kód:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !=/favicon.ico
# valid url, eg. forum/view-forum/12 => index.php?url=forum/view-forum/12
RewriteRule ^([a-zA-Z0-9\-_\/]*)$ index.php?url=$1 [END]
# invalid character in the url (eg. ".") => index.php?url=404
RewriteRule ^(.*)$ index.php?url=404 [QSA,END]

Azaz, ha egy általam elvárt formájú url érkezik (tehát nincs benne pont meg semmi egyéb speciális karakter), akkor azt átírom az index.php?url=$1-re, majd megszakítom a futást (az END ennyiben másabb, mint az L).

Ellenkező esetben, ha invalid karakter érkezik (pontosabban, ha nem matchel az első), akkor azt rögtön az index.php?url=404-re irányítom, amit aztán külön ellenőrzök, hogy ilyen url érkezett-e.

Elkezdtem azonban tesztelgetni a dolgokat, alapvetően működik. Azonban meglepődve tapasztaltam, hogy az url végén lévő "pont" karaktert tulajdonképpen figyelmen kívül hagyja, illetve az "üres" url nem jól működik.
Kód:
$url = isset($_GET['url']) ? $_GET['url'] : "index";
echo "<pre>";
echo $url;
echo "</pre>";

Eredmények:
test:8080 => url = 404 (nem jó, üres url-t várok, amiből a kódban index-et csinálok)
test:8080/asd => url = asd (jó, valid string az 1. rule-nak)
test:8080/asd..... => url = asd (nem jó, hol vannak a pontok?)
test:8080/forum...../view-forum/12 => url = forum/view-forum/12 (nem jó, az előző eset...)
test:8080/asd,,, => url = 404 (jó, mert a vessző invalid karakter)
test:8080/asd.php => url = 404 (jó, a szöveg.szöveg egy invalid pattern)

Szóval a kérdés már csak annyi, hogy az üres url az miért nem áll meg az első pattern match-nél, illetve, hogy a pont karaktereket (anélkül, hogy valami más követné) miért fogadja el az első match?

   
S_gaming - Tag | 9 hsz       Online status #210358   2016.10.02 11:59 GMT+1 óra  
A suliban webprog tantárgynál ismertem meg a Komodo Edit/ Komodo IDE-t, nemcsak a PHP-t, hanem html-t, js-t is kiemeli és ingyenes.

   
Instalok - Tag | 532 hsz       Online status #210357   2016.10.02 11:37 GMT+1 óra  
Köszi, ez a Visual Studio Code tetszik, Crane pluginnal kifejezetten jó lett!

   
HadaHector - Tag | 71 hsz       Online status #210356   2016.10.01 22:22 GMT+1 óra  
Aptana studio vagy Visual Studio Code amiket ajánlanék, hogy melyik jön be jobban, majd úgyis eldöntöd. De mindkettő elég jó.

   
Instalok - Tag | 532 hsz       Online status #210355   2016.10.01 14:38 GMT+1 óra  
Más: szerkesztőt mit használtok php-hoz? Eddig notepad++ban nyomtam, de hátha van valakinek jó tapasztalata egy másikról (amiben lehetőleg van "intellisense", mert akkor a notepad++ is jó)

   
Instalok - Tag | 532 hsz       Online status #210344   2016.09.27 13:09 GMT+1 óra  
Néha ide fogok tévedni ilyen gyogyós kérdésekkel, bocsi

A kis könyvecskémben most annál a résznél járok, ahol a cachinget tárgyalja. Konkrétan egy Memcache nevű dolgot használ, amivel elvileg lehet hatékonyan tárolni változókat key=>value módon. Úgy láttam, hogy localhostra nyit kapcsolatot, de sejtésem sincs, hogy miképp működhet, lehet utánanézek majd.

Eleve nem szeretem a 3rd party dolgokat (engine fejlesztés közben is csak egy SOIL nevű libet húztam be, amivel tudok képeket betölteni ), de a Memcache-nek szűksége van a ZLib-re is, így egyre kevésbé tetszett.

Azonban úgy gondolom, hogy valamilyen cache dolog nekem kelleni fog (azon kívül, hogy, ha úgy van, akkor az egész html oldalt cache-elem, azt kb. 10 sorból meg lehet csinálni), így valami mégis kelleni fog. A kérdés az, hogy van-e más, ingyenes, jó, egyéb dependency nélkül, avagy nagyon bonyolult lehet-e írni egyet? Mivel főleg tanulási céllal csinálom a dolgomat, így azt se bánnám, ha írnék egyet.

   
Instalok - Tag | 532 hsz       Online status #210317   2016.09.19 17:27 GMT+1 óra  
@Matzi:
Nekem sem volt túl szimpatikus egyébként, ezért is kérdeztem, hogy mennyire szokás az ilyeneket elő projekteken használni. Inkább megírom mindig kézzel a getter/setter függvényeket, mint mondjuk c++/c#/java esetében is kell (nyilván generálható is, de na).

Mondjuk a típus ellenőrzésre tényleg jó lehet, úgy nem kellene mindig kézzel megtenni. Egyébként felhozott egy olyan példát is, ahol kontextusfüggetlenné tehetjük ezzel a módszerrel.
Idézet
If the $location and $smell properties are only ever used in the same context, then our classes need none of this configuration we’ve been speaking about. If, on the other hand, these properties can have different meaning based on the implementation, we would need a means of defining this alternative context. Say, for instance, we wanted to create a Doghouse subclass in which $location could be defined as the location inside the Doghouse in which the Dog sleeps; or say we wanted to define $smell as a percentage of scents the Dog can smell from inside the Doghouse.


@HedaHector:
Igen, típustalan nyelvnél tényleg segíthet az ilyesmi. Bár php-val simán tökön tudja lőni magát az ember, ha akarja.

szerk.:
Később hozott még 2 példát:
Idézet
Perhaps we could want to enforce read-only/write-only/read-write behavior on class properties. The $_view property is protected, so it is not accessible outside the class, but imagine we have getters/setters for our class’s protected properties. We could, in those getters/setters, read the Doc Comments of our protected properties and enforce behavior based on them.
Perhaps we could want to make sure a method is executed only once. Other methods in our class could read the Doc Comments and ensure they do not call the authenticate() method if it has already been called.
These are two small, but effective examples of situations that we would require metadata for, and could provide it using Doc Comments. We will need to write a class that allows us to inspect these Doc Comments, and return the relevant key/value pairs for us to use elsewhere.

   
HadaHector - Tag | 71 hsz       Online status #210315   2016.09.19 17:16 GMT+1 óra  
Aminek az ilyen nyelvekben van még létjogosultsága az a hungarian annotation. Tudjátok: $iNumber, $qQuery, $sTitle. Tudom sokan nem szeretik, meg csúnya, de segít.

   
Matzi - Szerkesztő | 2519 hsz       Online status #210312   2016.09.19 15:13 GMT+1 óra  
Oszintén szólva a commentekbe rakott típus információktól nekem felfordul a gyomrom. Sajnos viszont a nem típusos scriptnyelveknél ez legalább ad valamiféle teszztelhetoséget. Szóval a mágia bban rejlik hogy maga a framework tud neked hibát jelenteni, ha a commentben lévo típus nem egyezik meg a ténylegessel. Illetve ebben a getter/setter esetben meg az adott member változó létét tudod jelezni, pl perzisztenciához. Persze a konkrét frameworkot nem ismerem (mert php-hoz nem akarok nyúlni), de gyanítom valami ilyesmi lesz inkább a lényeg.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 532 hsz       Online status #210311   2016.09.19 14:55 GMT+1 óra  
Elkezdtem végre tanulmányozni egy php-s könyvet, de kifejezetten olyat kerestem, amiben gyakorlati példák, illetve design patternek vannak. Ez Chris Pitt-től a Pro PHP MVC könyv. Itt elkezdett mindenféle "medzsiket" használni, mint például egy inspector osztály, ami a kommentekből szed ki meta adatot, és azt használja fel automatikus getter/setter hívásokhoz, például:
Kód:
class Car extends Framework\Base
{
/**
* @readwrite
*/
protected $_color;

Értek mindent, hogy hogyan működik, meg hogy miért csinálta, de tényleg kellenek ezek? Én például jó öreg c++osként szívesebben megírom kézzel a getter/setter függvényeket, amikor az nekem kell, nem pedig kommentből kibányászni meta adatot, amit felhasználnék a __call függvényben.

   
Parallax - Tag | 574 hsz       Online status #209501   2016.04.22 17:50 GMT+1 óra  
Instalok:
A Data rétegben entitások vannak, amik a nyelv számára objektumokat reprezentálnak, az viszont, hogy a háttérben XML, vagy SQL adatokkal dolgozik a rendszer az az ORM-től függ. Van olyan ORM, ahol csak egy kapcsoló kérdése a dolog és az entitások máris XML-el dolgoznak, vagy akár a memóriában (Mockolás). Igazából ez már nem a réteg feladata, így ezzel tervezni se kell.

A ViewModel-ek bármit reprezentálhatnak nem csak egy elemet, vagy listát, hanem lehet akár egy fa szerkezet is stb. Én szét szoktam választani ezeket is, mert így könnyebb összekötni őket a View-el és nagy programnál nem mosódnak össze a funkciók.

   
Instalok - Tag | 532 hsz       Online status #209500   2016.04.22 12:19 GMT+1 óra  
@Matzi:
Köszi, próbálkozok majd

@Parallax:
Hm, így már kezdem jobban érteni.

Viszont nem lehetne például a UserModel és a UserListModel egy osztály? Azaz a user data kezelésére egyetlen osztály lenne, amin keresztül le lehet kérdezni, hogy van-e ilyen user, illetve egy függvény visszaadna mondjuk egy listát (vagy visitor pattern használata, és mondjuk paraméterként átadni a visitor objektumot) a feltételek alapján létező userekről, stb.

Továbbá azt mondtad, hogy a Data réteg az, ahol az SQL utasítások generálódnak. Mi van akkor, ha én mondjuk menet közben kitalálom, hogy mostantól nem adatbázisba, hanem XML-be szeretnék menteni? Vagy mondjuk vegyesen - egyik data így, másik úgy. Ha jól értettem abból, amit írtál, akkor az adott entity osztály (pl. UserData) generálja az SQL utasításokat a megfelelő függvényhívás hatására.

Lehet, hogy majd valami vegyes, se-ilyen-se-olyan patternt fogok használni.

   
Parallax - Tag | 574 hsz       Online status #209497   2016.04.22 08:49 GMT+1 óra  
Instalok:
Legyen a User, Topic, Post SQL táblák.

Data: Ezt .NET-es szemmel nézve entitásokká alakítja az EF (entity framework) Ezek már C# osztályok, amik nyers SQL utasításokat fordítanak a rajtuk végzett műveletek mődosító/lekérdező (LINQ) alapján. (Ez talán a Java Hibernate-vel analóg ORM)

Model: Itt lenne UserModel, UserListModel, TopicModel, TopicListModel stb. A UserModel tartalmazna egy static User CurrentUser-t, aki a belépett emberke. Ezenfelül lenne benne egy bool IsLogin fgv, ami visszaadja az adatok alapján, hogy van e ilyen nevű/jelszavú ember. A UserList tartalmaz egy lista property-t, ami egy speciális Observer minta alapján a változásokat is lekezeli. Ilyen sztem Java-ban nincs, de vhogy biztos megoldható. Az üres konstruktora Mock adatokat tartalmaz Unit teszthez, a paramétert váró konstruktor pedig egy szűrő objektumot vár, ami alapján felépíti a listát és kivülről elérhető, illetve a szűrő ráköthető automatikusan majd a View-re két irányú data binding-al. Ez igazából WPF-ben egyszerű. A többi részt ebből már sztem el lehet képzelni, üzleti logika részt kell realizálni és elfeddni a részleteket az ORM felől, tisztán 1-2 fgv és property segítségével.

ViewModel: Ez már egy buta réteg itt lenne minden egyes megjeleníteni kívánt "tevékenység", ami 1-1 class lenne. pl.: Ha a usereket akarjuk végignézni, akkor UsersViewModel, belépéshez LoginViewModel, az adminnak UserManagerViewModel stb. A login csak a UserModel-t használná, míg a manager már a UserListModel-t is, mivel lenne benne egy master-detail rész is. Ezenkívül tetszőleges, hogy mennyi model-t kell itt haasználni, feladattól függ. Na most, ha valami kellően nagy pl több millió soros vállalati szoftver, akkor ott aztán 1 osztályba beleírni mindent elég bruteforce módszer lenne. Egy egyetemi beadandónál, vagy Pistike weblapnál elmegy az, hogy egyben mindent, de amúgy átláthatatlan. Unit teszteket, neadj isten TDD-t írni ezekre az meg már főleg önkínzás, már csak azért is, mert csapatban verzió követővel dolgoznak és módosítgatnak 1 file-t egyszerre 20-an.

View pedig amennyi felhasználói felület kell, ez akár több 100 is lehet.

   
Matzi - Szerkesztő | 2519 hsz       Online status #209495   2016.04.21 19:07 GMT+1 óra  
Nem tudom php-ban hogy van, de railsben vannak layoutok (abból egyet használsz, az az oldal kerete, az egész portálnak elég egy is akár), illetve a view objektum (meg generikus html fragmentek). Ez utóbbiból épul fel az oldal, és persze rekurzívan linkelhetik be a toredékeket. Szóval egy egyszeru listázó oldal esetén a kontroller behív pár model példányt, és kikuldi a view-nak. Az meg osszerakja, magát a tobbi ilyen kis toredékbol, vagy ahogy akarja. Nyilván ott már nem célszeru a modellt változtatni, illetve a controller azt kuld le, amit akar, lehetoleg mindent, ami a megjelenítéshez kell. Pl ebben a példában a '@books' egy lista, amiben 'book' példányok vannak.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 532 hsz       Online status #209494   2016.04.21 18:19 GMT+1 óra  
Igazából csak "gyakorlásnak" terveztem ezt az egészet. Miután az egyetemen néztük azt a fajta MVC patternt, kíváncsi voltam, hogy vajon real-life hogyan használják ezt az egészet.

És konkrétan php esetében hogy érdemes a view részt megvalósítani? Például írok egy olyan view php kódot, ami egyetlen hozzászólás megjelenítéséért felelős? Eredetileg úgy terveztem, hogy 1 view php készül minden egyes "aloldalhoz". Azaz például egy topic megjelenítése egy view feladata, a főoldal megjelenítése egy másiké, stb. Továbbá ki adja meg a megfeleltetést, hogy melyik view kell éppen? A view nyilván megkaphatja a controller objektumot, azzal nincs gond, az alapján tud html kódot generálni.

   
Matzi - Szerkesztő | 2519 hsz       Online status #209493   2016.04.21 17:52 GMT+1 óra  
Railsben így van ahogy írom. Modelbol annyit használsz fel, amennyit akarsz. A controller viszont lekérdezesenként csak egy kell, a view meg annyi ahány darabka adatot rajzolsz ki. Úgy van, hogy lehetoleg minden uzleti logika a modellben legyen, a controller meg csak azt etesse. Smart Model Dumb Controller, vagy ugyanez Fat és Slim kombinációval. Meg persze ugyanez van visszafelé is.

A lényeg, hogy minel kevesebbszer kelljen mindent megírni. Mivel a view az csak egy darabka html, oda értelemszeruen nem raksz semmit. A controller a lekérdezéshez kotodik, szóval oda is csak annyit kell, amennyi a minimum. A modell meg lehet okos, az jó, és ha egy adatot manipulálsz, akkor azt úgyis mindig a model osztályodon keresztul teszed.

Nyilván, ha más a kiosztásod, akkor más is lehet. Frameworkonként eltéro, hogy hogyan valósítják meg. Mire kell ez neked?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 532 hsz       Online status #209491   2016.04.21 17:35 GMT+1 óra  
@Matzi:
Igen, az egyetemen mi is ezt a módszert tanultuk. A model részben voltak az entity-k (Java estében Java Beans osztályok), amik egyszerű osztályok, mint egy adatbázis-tábla. A modelhez tartozott még a DAO ami a model objektumok tárolásáért és olvasásáért felelt (azaz mondjuk kiírta adatbázisba, vagy beolvasta onnan). A csúnyaság az egyetemi projektben az volt, hogy egyetlen DAO class volt, azon keresztül ment az összes model kezelése. A view tényleg csak megjelenítésért felelt, de a controllert használta fel az adatok kiírására és beolvasására (azaz a controller egyfajta mid-layer volt). A controller pedig a DAO-t használta. Ezek szerint ez a klasszikus?

@Parallax:
Tetszik ez is, egy mutáns MVC-nek tűnik.

Tehát ha tekintünk egy egyszerű fórumot, mint példát, akkor nagyon lebutítva: van 3 tábla: User, Topic, Post. A User nyilván a felhasználói adatokat tartalmazza (id, username, pwd, stb.). A Topicnak is van azonosítója, neve, esetleg leírás, ilyesmi. A Post-nak szintén id, továbbá egy Topic id (hogy az adott topic hozzászólásait tudjuk csak megjeleníteni) illetve egyéb adatok mellett egy user id, hogy tudjuk, hogy ki írta.

Ekkor miből hány osztályt kell/érdemes csinálni?
- Nyilván van 3 a Data/Model, ami az adott tábla megfelelője (User, Topic, Post).
- Ezután jön a Model/DAO, amiből szintén 3 van, a 3 előbbi classhoz tartozó. Ezeken keresztül lehet adatbázisba/akármibe írni-olvasni.

Az "eredeti" MVC szerint már csak Controller réteg maradt, amiből sejtéseim szerint szintén 3 kellene: UserController, TopicController, PostController? A legtöbb neten elérhető leírásban viszont azt láttam, hogy az URL alapján valamilyen módon kikövetkeztetik, hogy milyen Model, Controller és View objektumot kell létrehozni. És ezt meg is teszik (mondjuk az index.php-ban), azaz van 1db Model, 1db Controller, 1db View. Ez így nekem viszont nem jó, mert például egy adott Topic megjelenítéséhez szükség van a Topicok lekérdezésére, továbbá kell a Userek és Postok lekérdezése is. Azaz máris bukik az, hogy egyetlen model van, mert például az előbbi példában kell a User, Topic és Post DAO is.

Ezek szerint ez nem baj? A legtöbb internetes portálon rossz megközelítést írnak le?

Lehet, hogy kicsit kesze-kuszára sikerült, és bocsi a hosszú postért, itt egy krumpli:

   
Matzi - Szerkesztő | 2519 hsz       Online status #209488   2016.04.21 09:23 GMT+1 óra  
A ruby-on-rails is MVC-t használ. Ott úgy van a felosztás, hogy a Model az maga az adat, ami betoltodik, és alapveto muveletek rajta, vagyis minden olyasmi, amihez nem kell más, nem osszekapcsolt adatokat módosítani. A View az a HTML toredékek illetve layoutok, elég buták. A Controller meg tartalmaz minden mást, így mindkét irányba azon keresztul megy minden. Ez ugye a klasszikus megkozelítés.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Parallax - Tag | 574 hsz       Online status #209486   2016.04.21 07:03 GMT+1 óra  
Instalok:
Ma már MVVM-et használunk, de ezt is meg lehet feleltetni a régi MVC-nek, valahogy így épül fel:
View -> ViewModel -> Model -> Data Egy irányú kapcsolatok vannak és fentről lefelé megy az implementáció:

1. Data: Ez lehet egy adatbázis tábla entitás osztály például.
(UserData)

2. Model: Üzleti objektumok. Ezek reprezentálják a viewmodel is view számára a látható objektumokat. Ezek burkolják a Data-t, validálhatnak, betölthetnek 1-1 elemet, vagy ezek listáját lekérdezések alapján, tárolhatják statikusan pl a bejelentkezett felhasználót stb.
(UserModel, UserListModel)

3. ViewModel: Ez semmi mást, mint command pattern és a model, vagy model listákat kiközvetítő réteg, amit majd különböző View-ek használhatnak. Értesíti a View-et, ha változik egy lista vagy üzleti objektum tartalma, megnyomták a törlés gombot stb.
(LoginViewModel)

4. View: Egy buta UI, ami rá van kötve a ViewModel-re és a felhasználó számára megjeleníti az adatokat és biztosítja a felhasználói utsítások végrehajtását. Több féle View is választhat egy ViewModel-t, attól függően, hogy mi a feladat, hogyan kell reprezentálni.
(LoginView, SpecialLoginView)

Nem értem az miért baj, ha több modelt használ egy controller, hiszen az a dolga, hogy ezeket közvetítse a view felé, gyakorlatilag csak 1-1 objektum/lista ami kifelé egy változást kezelő property. Ami nehezebb az inkább a commandok implementálása. Persze nem egy controller van az egész alkalmazásban, mert az elég káosz lenne.

Ezt a hozzászólást Parallax módosította (2016.04.21 07:34 GMT+1 óra, 483 nap)

   
Instalok - Tag | 532 hsz       Online status #209485   2016.04.20 18:51 GMT+1 óra  
MVC-pattern: eddig kétféle megközelítést ismerek.

1)
A view a controllerrel kommunikál, azaz azon keresztül módosítja a modellt, vagy csak simán lekérdezi. Ez az ábra valami ilyesmit mutat:

Azaz a view-n keresztül a user kommunikál a controllerrel, ami módosítja a modellt. A view ezután a controllert kéri meg, hogy szolgáltassa adatokkal.

2)
A view közvetlen a modellből olvassa az adatokat, csak a módosítások történnek a controlleren keresztül. Valami ilyesmi:


Az egyetemen mi az előbbit tanultuk (ugyan nem web, hanem simán Java), és az nekem szimpatikus is volt.

Ott a model része volt az adatokat leíró osztályok (pl. Book, Customer, stb.), illetve a Data Access Object, amely a teljes alkalmazáshoz volt definiálva. Úgy értem, hogy volt egy interfész, illetve a konkrét megvalósítás (pl. DB DAO, vagy Memory DAO), amely az összes típusú model tárolásáért felelt. Azaz egy osztályon belül volt például AddBook, AddCustomer, stb.

Ezután jött a controller, amiből szintén egy volt a teljes alkalmazáshoz. Ebben tároltunk egy referenciát az adott DAO-hez (azaz a controller példányosította a megfelelő DAO-t). A controller alapvetően egy összekötő kapocs volt a view és a model között, kiegészítve ún. "üzleti logikával". Azaz például egy könyv hozzáadása esetén a controller beállította az "Ancient" flag-et, ha régebbi volt, mint 1970.

A view pedig nyilván a megjelenítés volt, de nem kommunikált direktben a modellel, a controllert használhatta csak. Azaz például user input esetén a controlleren keresztül módosította a modelt, majd a controlleren keresztül kérdezte le a tárolt adatokat.

Ebben az egészben annyi nem tetszett, hogy minél több model kerül a programba, annál nagyobb és átláthatatlanabb lesz a controller.

Ezen az oldalon egy teljesen más megközelítést olvastam, amely a 2. verziót alkalmazza. A modeltől közvetlen kéri le az információkat, és nem is direktben kommunikál a controllerrel.

Melyik lehet a jó megközelítés? Hogy érdemes csinálni?

szerk.:
Úgy tűnik, hogy az utóbbi az általános megközelítés:
Kód:
The typical program flow in MVC is:
The model, view and controller are initialised
The view is displayed to the user, reading data from the model
The user interacts with the view (e.g. presses a button) which calls a specified controller action
The controller updates the model in some way
The view is refreshed (fetching the updated data from the model)

Innen

Ezt a hozzászólást Instalok módosította (2016.04.20 19:05 GMT+1 óra, 483 nap)

   
itamas - Tag | 72 hsz       Online status #209224   2016.03.19 18:50 GMT+1 óra  
Köszönöm, Pixi, ezek valóban hasznos információk. Megnéztem a videókat is és kijegyzeteltem, amit csak lehetett, most pedig irány kipróbálni a dolgokat!
   
Pixi - Tag | 205 hsz       Online status #209222   2016.03.19 14:57 GMT+1 óra  
Konkrétan nem ismerem ezt a keretrendszert, de a Brackets nevű kódszerkesztőt használom én is. Nem teljesen világos mit értesz beépítés alatt. Tudtommal a könyvtárhoz tartozik egy vagy több JavaScriptes file, azt kell (legegyszerűbb, ha minden azonos mappában van, de ez nem feltétel) meghívni a html file-ban, tehát valami ilyesmi a lényeg:

Kód:
<script src="phaser.js"></script>


És ha minden jól megy, akkor ha hivatkozni próbálsz rá, meg fog jelenni a listában a könyvtárhoz tartozó megfelelő paraméter.

Talán ez a két videó segíthet az elindulásban, viszont régebbi verziót mutat be, tehát egyes dolgok nem működhetnek majd a te kódodban:

https://www.youtube.com/watch?v=0Mu1yAkkEi8
https://www.youtube.com/watch?v=TFVcaPuQp80

Ezt a hozzászólást Pixi módosította (2016.03.19 15:33 GMT+1 óra, 516 nap)

   
itamas - Tag | 72 hsz       Online status #209221   2016.03.19 11:47 GMT+1 óra  
Valaki tudna segíteni abban, hogy a "Brackets" nevű kódszerkesztőbe hogyan kell beépíteni a "Phaser" nevű HTML5 játékfejlesztő keretrendszert?
Mindenfelé nézem a neten, hogy ezt hogyan kellene, de sehol sem találom, úgyhogy egy pársoros eligazításnak nagyon tudnék örülni ezügyben...
   
Matzi - Szerkesztő | 2519 hsz       Online status #208728   2015.11.29 21:00 GMT+1 óra  
Szinte biztos, hogy már van rá plugin vagy egyéb megoldás, használd azt ami a frameworkben van, vagy hozzá kreáltak.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 532 hsz       Online status #208721   2015.11.29 09:36 GMT+1 óra  
Ha az adatbázisban BBCode-jellegű szöveget tárolok, akkor azt ugye megjelenítéskor át kell alakítani HTML szöveggé. Egy egyszerű regex jó megoldás lehet erre, vagy az túl lassú lenne?

   
Instalok - Tag | 532 hsz       Online status #207518   2015.04.21 19:46 GMT+1 óra  
Először megcsináltam úgy, teljesen jól működött. Aztán valamiért kipróbáltam úgy "simán", és most meg jó volt. Lehet, hogy előtte elbénáztam valamit, de most van rewrite is, és az ajax request is visszadobja, hogy nem találja a file-t, amikor kell.

   
Instalok - Tag | 532 hsz       Online status #207516   2015.04.21 17:37 GMT+1 óra  
Nem is tűnik rossz megoldásnak, úgyis most csináltam TOC (table of contents) részt is. Köszi az ötletet!

   
gopher - Törzstag | 496 hsz       Online status #207507   2015.04.21 13:58 GMT+1 óra  
@Instalok: szerintem a letezo parosokat el kellene tarolnod valahol (pl. egy tomb), ha szerver oldali fajlellenorzes (pl. PHP) nem lehetseges. Nem igazan latok mas megoldast, mivel a rewrite-ok minden keresnel le fognak futni.

Szerk: Vagy maximum egy plusz parameterre hivatkozhatsz egy ujabb RewriteCond-ban (pl. nem lehet "norewrite" az URL-ben) Ezt most hirtelen nem tudom hogy kene megadni (nincs keznel Apache tesztelodni )
   
Instalok - Tag | 532 hsz       Online status #207498   2015.04.20 10:49 GMT+1 óra  
Megint mod rewrite, csak most php nélkül. Adott a következő probléma:

Ajax segítségével betöltök egy xml-t, amiből adatokat generálok a html oldalba. Ezzel nincs baj, működik minden. Azonban szeretném megcsinálni, hogy "szép url-ek" legyenek, azaz olyasmik, mint: /alma/korte. Erre van ugye a lentebb látott egyszerű rewrite, ami azt csinálja, hogy amelyik link nem egy konkrét file-ra mutat, azt átírja index.html-re:
Kód:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule ^(.*)$ index.html [L]

Igenám, azonban az url alapján szeretném betölteni az xml-t. Azaz document.ready()-kor lebontom az url-t, és megkapom azt, hogy "alma/korte". Ezt viszont nem tudom leellenőrizni, hogy létezik-e, mert nagyon úgy tűnik, hogy lekéréskor (legyen az ajax vagy http request) szintén alkalmazódik a rewrite, ami nem talált file esetén átírja index.html-re, majd ezt nézi meg, hogy létezik-e. Ami nyilván létezik.

Hogy lehetne ezt értelmesebben megoldani?
Köszi!

   
Marcsello - Tag | 228 hsz       Online status #206632   2015.02.16 09:33 GMT+1 óra  
az, hogy miben írod a szervert és miben a klienst, az teljesen tökimndegy, amíg az üzeneteket egyeztetni tudod. C#-al még nem foglalkoztam, de gondolom ott is te rakod össze a csomagot, szóval csak olyan klienst kell írnod ami megérti.

js-ben nem maszatoltam nagyon, de ha jól tudom a jQuery-ben van valami socketes cucc, de ebben nem vagyok teljesen tökbiztos.

Ja és ha jól emlékszem (legalább is amikor én olvastam erről) akkor böngészőből még csak TCP-t lehetett használni, de azóta lehet már máshogy van.
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
HadaHector - Tag | 71 hsz       Online status #206628   2015.02.15 18:46 GMT+1 óra  
Igazából, mindegy miben írod a szervert, ha WebSocketet használsz javascriptben, az ilyen TCP kapcsolat gyakorlatilag, bármit meg lehet vele oldani.
Benne van már ezekben: Firefox 6, Safari 6, Google Chrome 14, Opera 12.10,Internet Explorer 10, szóval nem para.

   
Pixi - Tag | 205 hsz       Online status #206623   2015.02.14 15:57 GMT+1 óra  
Üdv mindenkinek!

Egy ideje próbálgatom a JavaScript kódolást (2D - HTML5/WebGL), és C# után nem tűnik vészesnek az áttérés, főleg úgy, hogy találtam megfelelő lib-et 2D-hez.

Viszont a problémám a következő: Milyen megoldást ajánlotok egy "realtime" adatátvitelű szerver létrehozásához? C#-ban ezt még nagyon egyszerűen össze tudtam eddig hozni, főleg úgy, hogy egy remek UDP-s lib-et használok az üzenetek küldésére és fogadására (Lidgren Network lib). Arra gondoltam, hogy ha van rá mód, akkor a szerver aplikációt megírnám a jól bejáratott C#-ban, és a kliensek böngészőben elfutnának. A problémám már csak az, hogy nem találok kielégítő megoldást, és mielőtt bármibe jobban belemélyednék, gondoltam egy hozzáértő tapasztalt véleménye sokat segíthetne, hogy milyen irányba induljak.

Tehát a kérdésem, hogy lehetséges-e a .NET-es világot összekapcsolni egy JavaScript alapú kliens játékkal, és ha igen hogyan lehetne megoldani a realtime adatátvitelt? Ha erre nincs megoldás, akkor viszont mivel helyettesíthetem a szervert futtató programot? Nézegettem a webservice-s megoldást, de ebből nem olvastam ki semmi olyat, hogy valós idejű extrémebb adatátvitelre használnák. Mindenképp Szerver-Kliens alapú megoldás érdekel. Lényegében annyi a cél, hogy valós időben adatot (üzenetet) tudjak küldeni/fogadni JavaScript kliens és egy gépen futó szerver aplikáció között.

Ezt a hozzászólást Pixi módosította (2015.02.14 16:09 GMT+1 óra, 915 nap)

   
Bacce - Bacce | 1783 hsz       Online status #205864   2014.12.22 17:42 GMT+1 óra  
kumbwol: Kezdésnek mindenképpen mélyülj el a html canvas-ban és a vanilla javascript-ben, ha egy alap irányítás-rajzolás-hang kombót megcsináltál már több rálátásod lesz mivel lehet kiegészíteni, van sok library bonyolultabb grafikához, fizikához, hangkezeléshez, de ezek nélkül is sok egyszerűbb dolgot könnyen meg lehet valósítani JS-ben, ezeket szerintem jó ha átlátja az ember mielőtt beleugrik a lib-ek világába.
Making the world a better place, one line of code at a time.
http://bacce.uw.hu
   
kumbwol - Tag | 7 hsz       Online status #205863   2014.12.22 14:30 GMT+1 óra  
Hali!

Weben játszható 2D-s multiplayer játékhoz mit ajánlotok? Főleg olyat szeretnék, amihez nem kell letöltenie a felhasználónak dolgokat (gondolok itt: flash, java update-ek, stb.) Inkább ha lehet JS-ben szeretném megcsinálni,de ott is sok közül lehet választani, és azoknak még több kombinációját. Ha valakinek van valami jó ötlete, akkor mondja, és ha tud mellé tutorial-t is linkelni az még jobb lenne!

   
DMG - Szerkesztő | 3172 hsz       Online status #205611   2014.11.24 09:48 GMT+1 óra  
Köszi, továbbítom.

Egy ismerősöm haverja 39 évesen eszmélt rá, hogy ő webet fejlesztene.
-----------------------------------------
Dont Listen to the Naysayers
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #205610   2014.11.24 09:29 GMT+1 óra  
Idézet
DMG :
Hali!

Ha valaki web fejlesztést akar tanulni, mit érdemes most megtanulni? html5, php, akármi?

Amit itt nálunk nagyon nyomnak a senior webesek, az HTML5 meg az újabb JavaScriptes cuccok, élen az AngularJS-el. A PHP mostanában eléggé leszállóágban van, effektíve kiscégek használják.

EDIT: Azt kihagytam, hogy - szintén az itteni senior-ok szerint - abba az irányba haladunk, hogy a frontenden html5, javascript, a backenden a logika tetejére pedig egy REST service van húzva, így nagyjából bármiben meg lehet írni a backendet, ami képes pl. tipikusan JSON objektumokkal kommunikálni. (Java, C#, whatever)

Ha viszont a backend logika vékony (tehát pl. tipikusan egy CRM vagy fórummotor van, de semmi komplikáltabb művelet mögötte), akkor technikailag még mindig jó lehet a PHP, de rendesen megélni abból necces

Ezt a hozzászólást MaNiAc módosította (2014.11.24 09:37 GMT+1 óra, 997 nap)
Dare to imagine!
http://www.insaneidea.hu
   
DMG - Szerkesztő | 3172 hsz       Online status #205609   2014.11.24 09:26 GMT+1 óra  
Hali!

Ha valaki web fejlesztést akar tanulni, mit érdemes most megtanulni? html5, php, akármi?
-----------------------------------------
Dont Listen to the Naysayers
   
Marcsello - Tag | 228 hsz       Online status #204892   2014.09.27 16:26 GMT+1 óra  
Hmmmm így már minden világos
Valóban jobb lenne a könyvtárakat ott szétszedni, mert a base tag megoldotta a szétesést ugyan, de mindig a főoldalra dob (azaz a $_GET['p'] üres) de nembaj, kis tervezéssel elkerülhető, hogy oda becsússzon bármi is, szóval nagyon jó ez a megoldás

Ezen a htaccess syntaxisán meg látszik, hogy arra tervezték, hogy egyszer megírod, aztán többet rá se nézel
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Instalok - Tag | 532 hsz       Online status #204890   2014.09.26 18:10 GMT+1 óra  
Arra pedig az a megoldás, hogy megadod a base url-t. No már ha jól értem a problémát.
Kód:
<base href="//localhost:8080/akarmi/" />

A rewrite pedig annyit csinál, hogy megad két feltételt. Ha nem directory és file, akkor a sor elejétől a végéig minden karaktert (amiből legalább 1-nek kell lennie) írjon át index.php?p="ami a zárójelben van" hozzáfűzve az egyéb query stringeket.

Én egyébként pont ezért nem tettem oda a directory kikötést. Azaz, ha könyvtárra hivatkozok, azt is átirányítom az index-re, ahol pedig lekérem a konkrét értéket:
Kód:
$page = dirname($_SERVER["SCRIPT_NAME"]);
$page = substr($_SERVER['REQUEST_URI'], strlen($page) + 1);

   
Marcsello - Tag | 228 hsz       Online status #204888   2014.09.26 15:25 GMT+1 óra  
Köszönöm, eza a QSA dolog megjavította a probléma no1-et már csak a kis szépséghiba maradt, ami az, hogy ha a végére véletlen becsúszik egy / akkor, valami olyan helyre mutat, amit nem is ismerek de ez a böngésző miatt van (mert a /message nem ugyan az mint a /message/ a relatív útvonalak miatt bugol be), szóval majd php-val megoldom, hogy redirectelje egy perjel nélküli változatra

itt a jelenlegi tutorialokból és egyéb forrásokból össze kattintgatott változatom:

Kód:
RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.+)$ index.php?p=$1 [QSA]


Fogalmam sincs, hogy mit csinál a gyakorlatban, de működik és kész
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Instalok - Tag | 532 hsz       Online status #204886   2014.09.25 21:50 GMT+1 óra  
Nekem arra valami ilyesmi volt, és úgy tűnt, hogy működött:
Kód:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [L]

Én mondjuk mindenféle mágia nélkül használtam, az index.php-ban bontottam fel az url címet, és azt vizsgáltam, de ugyan így a Rule-nál át lehet adni egyebeket is.
Egyébként meg használd a QSA flaget.

szerk.:
A fenti kód mondjuk mindent átirányít az index.php-nak, a conditiont lehet nézegetni, van -d kapcsolója is, ami directoryt jelöl. Hogy néz ki amúgy a jelenlegi rewrite-od? Lehet, hogy csak lehagytál egy "?"-et, vagy valami ilyesmi.

   
Marcsello - Tag | 228 hsz       Online status #204885   2014.09.25 18:06 GMT+1 óra  
Hello! Elvagyok a webfejlesztéssel de egy dolgot sosem fogok megérteni, a rewrite engine-t meg az egész .htaccess logikáját...

Valami olyasmit szeretnék összehozni, hogy ha valaki egy nem létező mappa nevet (per jellel és anélkül is) pl.: /shop vagy /messages/ akkor azt az index.php-nak adja
index.php?p=messages vagy index.php?p=shop néven, az se baj ha utána vagy elé rak valamit, csak a p értéke az legyen, ez nagyjából működik, de nem tökéletes (a perjelektől behal az egész) a másik pedig, hogy ugye ha így néz ki akkor után a GET cuccost ?-el illik utána írni, valamiért ezt sehogy se tudom megoldani, hogy a

/shop?buy=5 -ből /index.php?p=shop&buy=5 legyen, vagy
/messages?inbox-ot /index.php?p=messages&inbox-ra varázsolni
biztos meg lehet valahogy de ennek a logikáját nem tudom dekódolni... esetleg valaki csinált már hasonlót?
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Instalok - Tag | 532 hsz       Online status #204616   2014.08.24 21:33 GMT+1 óra  
Igen, a "Remember me" funkcióra én is hasonlót találtam ki. Sütiben nyilván nem lehet csak úgy a felhasználónevet tárolni, így valami id kellene. Egyelőre nem terveztem ilyet, szóval maradok a sessionben való username tárolásnál. Köszi!

   
Marcsello - Tag | 228 hsz       Online status #204615   2014.08.24 20:43 GMT+1 óra  
Ez attól függ, a $_SESSION tartalmát csak a php látja, a böngészőnek csak egy cookie-t ad az id-vel, szóval azzal nem sok mindent lehet kezdeni. viszont a SESSION minden értéke szerver oldalon van tárolva ami egy idő után lejár.

én igy oldottam meg a login eltárolást:

MySQL Users tábla:

Kód:
+-----+---------------+----------+----------------+
| Id  | Username      | Cookie   | LastActivity   |
+-----+---------------+----------+----------------+


Namost, ha valaki bejelentkezik, akkor generálok egy mondjuk 32 karakteres sütit, ezt adom a böngészőnek, és a többi lapon az alapján azonosítom be a felhasználót. meg minden lap betöltéskor frissitem a LastActivity-t pusztán a statisztika miatt, az inakitv userek szűrésére. ez azért jó, mert pl. az admin ki tud jelentkeztetni valakit. viszont két hátránya van:
- A cooke-k nem egyezhetnek, véletlen se
- egyszerre csak egy eszközről lehet bejelentkezni.
Az elsőt egyszerűen azzal orvosoltam, hogy eltároltam külön sütiben a sor ID-t ami ha végig gondoljuk ugyan olyan biztonságos, mert a random karakterlánc nélkül nem tudunk kezdeni vele semmit, szóval nehezebb is feltörni.
A másodikat meg süti újrafelhasználással lehetne kijavitani, de az viszont nem biztonságos.

Szóval szerintem ha csak PHP sessionokat akarsz használni akkor ne foglalkozz vele, magában az elég biztonságos, ez akkor kell, ha pl. akarsz "maradjak bejelentkezve" cuccot is bele
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Instalok - Tag | 532 hsz       Online status #204613   2014.08.24 20:26 GMT+1 óra  
Na még egy utolsó lame dolog, aztán leállok egy kis időre. Megírtam a regisztrálást, loginolást, működik szépen. A passwordot természetesen enkódolva tárolom egy adatbázisban. A kérdésem az lenne, hogy miután autentikáltam a felhasználót, és bejelentkezett, miként tárolhatom, hogy melyik felhasználó van bejelentkezve? Első körben - hogy tudjam tesztelni - simán a felhasználónevet tároltam el session változóként, de gondolom ez támadható pont.

   
Marcsello - Tag | 228 hsz       Online status #204604   2014.08.24 10:34 GMT+1 óra  
Ilyesmi gondok nekem is voltak, én a </li> és a <li> közé nem tehettem entert mert szétcsúszott az egész
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Instalok - Tag | 532 hsz       Online status #204603   2014.08.24 09:41 GMT+1 óra  
kristu:
Köszi, el is felejtettem ezt az oldalt! Ezen a linken az elsőnél otthagytam a sortörést, a további kettőnél pedig nem.

   
kristu - Tag | 6 hsz       Online status #204602   2014.08.24 09:35 GMT+1 óra  
szia
dobd fel ide: http://jsfiddle.net/

   
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10]