Leszármazott osztály könyvtára
Üdv.
Van egy ősosztályom, aminek a leszármazottjának a könyvtárát szeretném elérni.
valahol/leszarmazott.php:os.php:Bármi ötlet?
■ Van egy ősosztályom, aminek a leszármazottjának a könyvtárát szeretném elérni.
valahol/leszarmazott.php:
class Leszarmazott extends Os
{}
abstract class Os
{
public function __construct()
{
$class=get_called_class(); // Leszarmazott
$dir=???; // valahol
}
}
Üdv !
Szia!
Találtam kerülő megoldást, az autoload kezelő osztályomtól kérem le a leszármazott osztály könyvtárát (mert úgyis az tölti be). Eddig ott rontottam el, hogy a leszármazottat require_once-oltam, aztán ott akartam beállítani az autoload-ot. (Ennek is megvolt a maga oka, amit most megszűntettem.)
Koncepció?
Valóban
Milyen fájlok?
Huh, bonyolult. :-) Írok egy
index.php:
A document root kb így néz ki:
A saját szerver meg az Engine\Server-ből van származtatva, és az Engine\Server konstruktorának kell indítania a keresést.
Jó ez Neked
Köszi a javaslatokat, request
Egyébként folyamatosan változik az egész, még képlékeny, meg fejlesztés alatt vannak az alapok is. Még nem tudom, hogy mik a lehetőségek, meg közben is tanulok, ezért nehéz unit testelni. :-)
Nekem az az elgondolásom, hogy unit test előtt meg kell tervezni az interfacet, meg hogy hogy fog működni, utána tesztet írni rá, és utána bekódolni, miközben folyamatosan ellenőrizzük, hogy a kód teljesíti e a tesztet. Na most ezt egy olyan rendszernél, ami még formálódik bennem, hogy hogy fog kinézni kicsit nehéz...
De simán lehet, hogy nem értem a unit test lényegét, mert még nem foglalkoztam vele behatóan.
Kezd beigazolódni, hogy
Bár egyelőre csak kisebb részletekben... A bonyolult működési logikával kapcsolatban, tök felesleges az összes project mappáját előre kikeresni (a foreach az Engine\Server-ben), simán meg lehet tenni, hogy csak akkor kérjem le, amikor tényleg szükség van rá.... Érdekes megtapasztalni, hogy még egy viszonylag egyszerű programnál is simán lehet logikai hibákat elkövetni a fejlesztésnél. Végülis az interface-t a mostani rendszer is teljesíti, de minden lekérésnél egy csomó plusz fájlművelettel...
CLI-vel kapcsolatban az van, hogy nem szeretnék ilyet írni, mert nem igazán látom értelmét. Persze lehet, hogy van, de én még nem jöttem rá, hogy mi... Ha generáltatni akarok dolgokat, akkor weblapokból is elküldhetem az ehhez szükséges adatokat, ráadásul sokkal hatékonyabban lehet így paraméterezni a dolgokat. (vagy én nem értek valamit cli-vel kapcsolatban...)
UnitTest-ről csak most kezdek olvasgatni, hasznosnak hasznos, csak még nem szoktattam magam hozzá.
Csináltam új Factory-t, ami
Így Athlon64 3000-esen az összes autoload-dal együtt 8ms alatt áll fel a rendszer xdebug szerint. (A régi változat 40ms körül futott.)
A request és response objectek és a session kezelő felépítése meg szükséges a kérés lekezeléséhez.
Nem probléma
Egyébként ami a CLI-t illeti, azért érdemes abban (is) gondolkodni, mert simán lehet, hogy szeretnél a későbbiekben valamiféle háttér-feldolgozást, adat exportot vagy hasonlót csinálni, ami böngészőből leginkább tákolás. Ezer meg egy oka lehet annak, hogy egy programot ne a HTTP interfészen keresztül szólíts meg. Ha akarsz interoperabilitást tesztelni, lőjj föl az Apache alá egy FastCGI-t és próbáld meg azon használni a programot. Ha nem fut, javítsd ki.
Ami a unittesztelést illeti, a unitteszt olyan, mint egy specifikáció. Amikor először láttam ilyet, én is nagyon elcsodálkoztam. Előbb írod meg a unittesztet, utána magát a programkódot. Így mindjárt előre tisztázod magadban, hogy mik is a követelmények. Ez egy érdekes szemléletváltás azzal szemben, hogy nekiállsz, kódolsz, működik valahogy, aztán mégis másképp kéne. Próbáld ki, érdemes.
Ki fogom, ne aggódj :D Azért
CLI-n még gondolkodok, nem tudom hogy lehet megvalósítani, nincs tapasztalatom vele.
Alapból olyan rendszert szeretnék, aminek van SOA támogatása, szóval lehet, hogy inkább SOAP-pal fogom megszólítani a progit CLI helyett. Úgy könnyebb struktúráltabb adatot átadni.
Egyébként szinte kizárólag a soap miatt csinálok saját fw-t, van egy elképzelésem, hogy js hogyan tudna php-vel soap-pal kommunikálni, és szeretném megvalósítani. Leginkább az a része tetszik a dolognak, hogy a wsdl-ben megadott xsd-vel lehet automatikus validálást is csinálni a soapEnv-re, nem kell egyenként megnézni a változókat, hogy stimmel e a típusuk, és a típuskonverzió is automatikus. (A meló mondjuk sok vele, nem csak php, hanem js oldalról is. Normális soa-hoz kellenének osztályok, amiket js még nem támogat. Meg xsd-ben meg kell oldani, hogy le tudjam szűkíteni az átadott tulajdonságok körét a teljes osztályról. Igazából ez utóbbi a nehezebb, js-be osztályokat csukott szemmel is írok...)
Vigyázz vele
Tudom, én írtam :D Meg azt
Olyasmit szeretnék, hogy megadom a wsdl-t, aztán az abban lévő alap XML Schema-ból generálom az adatbázist meg a DAO osztályokat, az alap séma szűkítésével meg az action paraméterek típusait határozom meg, és kigenerálom a serviceket.
Ez így lehet, hogy kicsit tömény lett. :D
Mondok példát, mondjuk a felhasználót beléptetjük:
az alap UserDao osztály:
az alap szűkítése, amit az UserService.login használ meg:
Itt az átadott UserDao xsd típusa eltér az alap UserDao xsd típusától, mert az átadottnál csak email és password példányváltozókat adhatjuk meg, ezt meg xsd-vel validáltatni kell. Úgy szeretném megoldani, hogy az alap típust részletesen megadom, a leszűkítést meg valami egyszerű módon csinálom meg az alap típust felhasználva. Viszont kicsi az esély, hogy ez ténylegesen megoldható, mert alapból nem jellemző ez a fajta megközelítés a programnyelvekre, szal valszeg az xsd-re sem lesz az. (Persze aztán ki tudja, lehet, hogy szerencsém lesz.)
Nem jo otlet.
Tudom, hogy manapsag mindenki kodot akar generalni, de egy vegig gondolt, az implementalo szemszogebol koherens interfesz sokkal jobb, mint a sajat szemszogedbol elsonek jonak tuno adatbazisbol lebutitott valtozat.
Bocs, elszabtam :D Dao
Kicsit módosítok azon, amit írtam, valami olyasmit szeretnék, hogy xsd alapján építem fel az adatbázist, és ezt az xsd-t használom fel valamilyen formában a modeleknél és servicek (controllerek) felületét leíró wsdl-ben is. De nyilván a servicek felületéhez ennyi adatnál több fog kelleni....
Tisztában vagyok vele, hogy a Soap lassú, viszont azt is lehet kesselni ugyanúgy, mint bármilyen kimenetet. Előnyösnek meg elég előnyös, mert XML + XSLT -> XHTML, és ez már kliens oldalon is megy IE6-tól.
Hááát
A legfőbb érvem az automatikus API generálás ellen az API logikája. Olvasd el ezt, hátha jobba illusztrálja, amit mondani próbálok: http://lcsd05.cs.tamu.edu/slides/keynote.pdf
Update: szóval azt próbálom mondani, hogy szerintem, rossz oldalról közelíted meg. Az API felől kellene indulni a tervezéssel, mert ott merülnek föl a követelmények, nem az adatbázis oldalról. Az adatbázis a use casek következménye, nem oka.
Ahm, szóval nem biztos, hogy
szerk:
Hát tanulságos volt. :-) Egy részéhez gyenge volt az angolom, szótárazgattam. Tolódtam az először tervezés, aztán implementálás felé. Majd még elolvasom többször is.