@e-Gandalf:
To naprawdę ciekawe podejście. Zastanawiam sie, jak rozwiązałeś kwestię cache (co to znaczy świeże, jak rozwiązać problem dynamicznych danych, itd.). Bo XSLT ma wielkie możliwości, ale jednak nie nadaje się do stosowania przy każdym żądaniu.

BTW, przychodzi mi na myśl zaraz Cocoon... może znasz? Dla php był chyba jakiś klon, o dźwięcznej nazwie Popoon .

Hmm... może trafię jak kulą w płot, ale jak mniej więcej działa klasa IO (czyli chyba Input/Output). Rozumiem, że przechowuje dane input a więc _POST _GET _COOKIES itp. Ale nie rozumiem po co. Przecież to są tablice superglobalne. Wszędzie można je czytać. Po prostu to jest to co mi pierwsze przyszło na myśl - ale skoro taką klasę stosukecie, znaczy jest potrzebna. Czy moglibyście mnie oświecić?

Tak jak onet Output idzie do pliku o losowej nazwie, a do bazy wpis z indeksem pliku, informacja o szablonie, formacie i zestawie danych dla jakich plik cache zostal stworzony i data. Jesli jakas klasa modyfikuje dane (np. dodawny jest news) odpowienie szablony sa dodawne do kolejki generacji cache.



Nie wiem Ja bardzo nie lubie gotowcow php bo jestem nimi nieodmiennie zawiedziony. Biblioteka Pear moim zdaniem zasluguje na miano najgorszej oficjalnej biblioteki jezykowej na swiecie.


Lolek9: To co napisales (GET|POST) to argumenty okreslajace zapytanie. Czyli przekladajac na model ludzki one okreslaja (wraz z np. parametrami konfiguracyjnymi serwisu) co ma serwis wypluc i jak ma to wygladac. Input to zestaw danych z jakich korzystamy (pliki xml, baza danych itp) a output to to co jest wypluwane, u mnie jest to xml/xslt

Dzięki, ach... czuje na swej skurze łagodny blasko oświecenia
Czyli po prostu źle zrozumiałem rolę klasy Input i Output.
Dzięki
A, i jeszcze jedno pytanko... czy klasa Input np. powinna na przykład czytać z różnych plików?
Sprecyzuje może moje pytanko. Mam klasę User i mam nadzieję mieć klasę Input
No i teraz plik w którym trzymam dane userów mam jako atrybut w input, a chce, aby z poziomu klasy User możnabyło dostać się do zawartości pliku. Czy to klasa User powinna czytać plik, czy może powinna po prostu wywołać metodę obiektu Input która przeczyta i zwróci zawartość??

No, to juz jest bardzo dyskusyjne Sadze, ze kazdy uczestnik tej grupy bedzie mial wlasne zdanie. Ja sklaniam sie ku rozwiazaniu abstrakcyjnego API. tworzysz klase abstrakcyjna, lub (w php5) interfejs z metodami publicznymi getRow(num), getNextRow(), setPointer(num), getRows() i tak dalej a potem tworzysz wyspecjalizowane klasy dziedziczace ten interfejs, ktore te metody stosuja dla pliku xml o konkretnej budowie, albo dla bazy danych, albo dla pliku tekstowego, albo dla pliku RDF... Klasa User powinna pobierac z silnika referencje do aktywnej instancji klasy korzystajacej z interfejsu Input i uzywajac jej pobierac. Staraj sie mocno rozgraniczac to co zajmuje sie przetwarzaniem danych wewnatrz, a to co pobiera te dane z zewnatrz. Dzieki temu chcac zmienic metode przechowywania danych masz pewnosc, ze musisz jedynie podmienic klase implementujaca Input na inna.

e-Gandalf.. a Ty czasem nie mówisz o DAO? Input to są jak dla mnie właśnie te dane przechwytywane od usera - czyli np: dane COOKIE, czy zmienne przesyłane np: POST'em... A to, o czym mówisz, to korzystanie z abstrakcji na źródło danych... (a nie dane wprowadzane z zewnątrz) czyli DAO. Czy może mylę pojęcia gdzieś? )

Hmm... no sluchajcie, wszystko zalezy od sposobu patrzenia
Dla mnie aplikacja wyglada tak:

Input <-- Processing+Engine--> Output

Gdzie Processing+Engine ma za zadanie pobrac dane wejsciowe i wypluc wyjsciowe. Gdzies tam przy okazji moze zrobic cos jeszcze (jak np. cache, z ktorego nastepnym razem skorzysta), a sposob dzialania ma uzalezniony od argumentow na rzecz ktorych jest wywolywany, ale Wejsciem dla mnie sa dane (nota bene) wejsciowe, a nie argumenty.
Ale nie bede sie upieral przy nazewnictwie, moze byc Ble i Bla, byleby dzialalo dobrze i pozwalalo na wygodna konserwacje oraz latwe dobieranie zrodel wejsciowych i wyjsciowych dla danych

@e-Gandalf:
Hmm, a jak to się ma do iteratorów w PHP5? Bo różni ludzie wymyślali różne DAO, własne iteratory i abstrakcję. A potem przyszło PHP5 i to wszystko jest lekko nieaktualne, bo PHP5 ma własne iteratory, i to lepsze.

Czy metody getRow(), getNextRow(), itd, nie robią czegoś w rodzaju iteratora? No może więcej niż iterator bo z dostępem swobodnym, ale IMHO robienie samemu czegokolwiek co służy do iteracji przestaje mieć sens. Zresztą zauważ że taki ogólny interfejs nie powinien mieć getRow(num), bo np. zapytanie SQL nie ma dostępu swobodnego - robisz query i dostajesz kolejne wiersze. Taki Input musiałby cacheować całość wyniku, a to nie jest optymalne. Więc lepiej pozostać przy dostępie sekwencyjnym.

A może POST i zapytanie do bazy są na tyle różne, że nie da się ich wcisnąć w ten sam interfejs? Może lepiej zrobić Input (tylko sekwencyjny) i CachedInput (extends Input + swobodny)? Hmm, jeszcze trochę i sam się zakręcę...

Ale iterator daje Ci tylko wygodna metoda przechowywania listy danych, a ja mowie o komunikacji ze strefa zewnetrzna. Nie zbierzesz do iteratora wierszy z bazy danych, bo tych wierszy moze byc tam 10 milionow. Lepiej sprecyzowac ile pobierac



Pewnie. Dlatego Iterator czy Enumerator oficjalny z php5 mozna uzywac do zwracania wynikow tych funkcji.



Podalem tylko przyklad, ale przedstawie Ci przyklad wdrozenia:

$x = $engine->services->getDefaultInput()::createStream();
$x->setInitPoint('localhost'.'baza','user','haslo','tablica');
/* i czesc uniwersalna */
$x->getRow(4);


i jesli getDefaultInput() jest wskaznikiem na MysqlInput to polaczy sie z baza danych i ustawi sobie query na tablice "tablica". Nastepnie getRow(4) wywoluje zapytanie 'select * from tablica limit 4,1'

To oczywiscie tylko przyklad, pewnie nalezaloby to wykonac troche inaczej, ale da sie A na dodatek, potem, transparentnie dla API mozesz cachowac to query i np. trzymac w bazy wyniki, aby drugie zapytanie o getRow(4) zwracalo zawsze z cache, chyba, ze $x wykonywal metody set/update (czyli istnieje ryzko, ze dane byly modyfikowane).



Nie koniecznie Moglby, ale nie musialby. Wszystko zalezy jak zbudujesz klase, i do czego bedzie uzywana.



No, interfejsu do Posta jeszcze nie robilem, ale wydaje mi sie, ze da sie. A jak ktos sie uprze to moze zrobic interfejsy dziedziczne ObjectInput i ListInput gdzie dziedziczyc po ListInput beda klasy odpowiedzialne za baze danych, rdf, tablice, skrzynke pocztowa i inne formy wielokrotnie powtarzajacych sie danych, a ObjectInput bedzie przyjmowal obiekt HttpResponseInput z wlasciwosciami argumentow _POST|_GET, XmlInput, TextFileInput itp.



Mozliwosci sa ogromne, a w tej kwestii w php standardu jeszcze nie ma zadnego.

Uff, sporo tego

Tutaj jestem bardzo przeciwny. Wiem że jest taka tendencja (eclipse, phrame), ale to bez sensu. php już ma HashMapy - tablice asocjacyjne. I klasa HashMapy nic nowego ci nie zaoferuje. Podobnie wiedziałem w php klasy ArrayList (to już szczyt głupoty), Iterator (w PHP5 równie wielka głupota) itd. To tylko balast, bezużyteczny kod i dodatkowe ułamki sekund przy każdym żądaniu.

No cóż, sesje, dane post, itd. generalnie nie pasują do MVC. Z jednej strony to jest źródło danych -> Model. Z drugiej strony tylko Kontroler powinien wiedzieć że jest żądanie HTTP -> Kontroler. IMHO nie ma sensu wpychać tego nigdzie na siłę. Sesje to jest coś jak Model, ale odrębne, bo Model się pisze pod konkretną aplikację, a obsługa sesji jest częścią jądra systemu/frameworku.

A swoją drogą, ja skłaniam się do włożenia sesji do kontekstu. To chyba pomysł z ASP.NET - klasa Context, która łączy Request i Response, czyli zbiera do kupy wszystko, co związane jest z komunikacją klient - serwer.


Miło widzieć że ktoś też lubi router . Widzicie to, zespół core? Coś w tym jest.
Ja bym jednak umieścił router ZA kontrolerem. Tak będzie działał (działa) phiend2, i ma to wielką zaletę: router można sobie łatwo wymienić, bo to zawarte jest w konfiguracji kontrolera. I kiedy nagle przyjdzie ci do głowy że index.php?action=foobar jest głupie, i chcesz mieć index.php/foobar, to tylko wybierasz odpowiedni router.

A co do kontroli dostępu, czyli auth... Owszem, auth można włożyć do Modelu. Tylko wtedy najpierw jest tworzona akcja, a potem akcja wywołuje metody auth. Bo przecież z Modelu korzystają akcje. A to nie jest dobre, bo można po prostu zapomnieć w jednej akcji sprawdzić prawa dostępu i już mamy security breach. Takie rzeczy jak auth powinny odbywać się PRZED akcją, żeby była pewność że zawsze się wykonają. Niewykonany auth to gorzej niż niewykonana akcja.

Wracając do pytania - gdzie to wcisnąć? Odpowiedź jest prosta i znowu żywcem wzięta z phiend2 - Intercepting Filter. Piękny wzorzec, wrzucasz do kontrolera obsługę filtrów (wczytywanie z pliku konfiguracyjnego i odpalanie). O samym wzorcu poszukaj na MSDN (narawdę mają bardzo dobry dział dot. wzorców dla aplikacji internetowych) i Sunie - zresztą w J2EE Intercepting Filter jest wbudowany.

phiend :mrgreen:
Na resztę odpowiem jutro, time to get some sleep

Doleje troche oliwy do ognia, a co



Ding - dong. To ja Cie bardzo poprosze o wygodna implementacje containsValue w tym "PHPowym hasmapie" - oczywiscie bedziesz mi iterowal algorytmem o zlozonosci liniowej element po elemencie. HasMap znany nam np. z Javy posiada liste poindeksowanych wartosci tak samo jak posiada liste poindeksowanych kluczy. "Dobranie sie" do odpowiedniej wartosci i do odpowiedniego klucza daje ten sam narzut czasowy.
Po drugie kazdy szanujacy sie HasMap posiada wlasciwosc LoadFactor majaca niebagadelny wplyw na wygode dzialania tablic. LoadFactor dopasowany dobrze do przechowywanych wartosci potrafi czasem dwukrotnie nawet przyspieszyc dzialanie.
Indeksowane tablice w php to bardzo mala namiastka i zastepowanie ich powaznym hasmapem uwazam za jak najbardziej na miejscu!



Znowu niekoniecznie.
Iterator z Javy daje mi mozliwosc latwego kasowania elementow, bez niebezpieczenstwa utraty plynnosci iteracji. W php jesli sie nie myle nie jest to takie "fajne".



Apage To pomysl Tomcata zdaje sie, albo Resina - juz nie jestem pewien



Zgadzam sie, ale wykorzystanie IF nie zawsze wydaje mi sie konieczne, natomiast wszelkie metody autoryzacji wykonywalbym tuz po czesci inicjujacej dzialanie silnika. W momencie kiedy srodowisko "klienckie" dziala, a "administracyjne" nie jest jeszcze zainicjowane.

U mnie router to obiekt, który dostaje Context i ma wymyśleć nazwę akcji. Interfejs chyba dużo nie mówi:
[php:1:148251ea58]<?php

interface IRouter {
public function translate(HttpContext $context);
}

?>[/php:1:148251ea58]
Fajnie byłoby jeszcze, jakby router mógł robić "w drugą stronę", tzn zamieniać nazwę akcji na URLa. Wtedy mamy automatyczne generowanie URLi, i co najważniejsze, jak zmienimy router (czyli schemat budowy URLi dla całej aplikacji), dotychczasowy kod się nie zmienia, bo nowy router generuje URLe wg nowego schematu.
Poza tym router może sprawdzać, czy przeglądarka obsługuje XHTML (i jakoś to przekazywać do akcji), itd.

Komunikat to nie akcja, i zapewne jest wyciągany z modelu. Ale obsługa formularzy to inna sprawa, jest tu gdzieś ładny wątek o tym...


Context = request (POST, URL, itd) + dane o akcji (jeżeli mamy MVC) + response (do co wypluwają akcje).


A do czego służy httpServletRequest? Pachnie Javą, ale z J2EE mam mało wspólnego .

Tu mnie zagiąłeś :oops: . Zdarzyło mi się widzieć w php tylko badziewiaste HashMapy które udają że nie są debilną tablicą asocjacyjną. A containsValue() tłumaczy się w php na in_array(), i nie mam pojęcia jak jest w środku implemntowane. Może tablica asocjacyjna potrafi więcej niż tylko liniowe przeszukiwanie? Ktoś wie?


Tutaj to nie jest takie proste. Bo ta łatwość jest po stronie klienta, a implementując iterator już tak łatwo nie jest. Ale masz rację: Iterator np. na ArrayList obsługuje usuwanie bardzo przyjemnie, a z foreach(...) już byłoby topornie.


Hmm, tzn kiedy? Nie tak łatwo się porozumieć . Jak dla mnie, uwierzytelnianie może być jak najwcześniej, natomiast autoryzacja dopiero wtedy, gdy wiemy, jaką akcję chcemy wykonać (skrzywienie MVC). A to niestety nie jest tak wcześnie - przedtem wstają różne filtry, db, sesje, router, trzeba w ogóle ściągnąć config akcji... A IF podoba mi się dlatego, że nie chcę wrzucać rzeczy takich jak auth na sztywno do silnika, jak w "starym" phiendzie. IF pozwala wywalić dużo rzeczy na zewnątrz, zwiększając tym samym elastyczność i konfigurowalność, a mimo to mogę je wykonać w podobnym momencie, jako część silnika, a nie część akcji.

Skontaktuj sie z lekarzem... To naprawde niebezpieczne - mi musial pomagac po pierwszym spotkaniu z Tomcatem



Mhm, masz racje, pomysl jest bardzo "czysty" i logicznie spojny - jak zreszta wiekszosc z Javy. Naprawde, uwazam, ze implementacja server-side w wykonaniu Javy jest praktycznie wzorcowa i jedyne co mozemy robic to ja emulowac w php

A co do auth - wiesz, to tak jak z wysylaniem zapytan do bazy. Bardzo trudno to robic w jednym miejscu. Auth musi moc byc odpalony w czasie trwania calej akcji, poniewaz autoryzacja czegos co ty nazywasz akcja (zakladajac, ze dobrze zrozumialem ja to nazywam generacja szablonu) to poczatek. Potem w trakcie wykonywania akcji nalezaloby jeszcze sprawdzic czy uzytkownik ktory ma prawo do obejrzenia tego dokumentu powinien tez zobaczyc przecisk 'edit' umieszczony pod nim, nie?

Znikąd. phiend2 powstaje w bólach i nie zanosi się na szybki przełom.

Prawda. IMHO ważne jest żeby pierwsze odpalenie auth było przed akcją - może w ogóle nie trzeba ładować akcji. I to jest ta część od której zależy bezpieczeństwo systemu - np. czy user może usuwać artykuły. Potem, w trakcie wykonywania akcji, nie ma rady, trzeba znowu sprawdzać. Ale jak tutaj się zapomni to będzie bezużyteczny przycisk, a nie włamanie do systemu.

BTW, z tym związany jest problem. Jeżeli będzie gdzieś zapisane że do akcji "DeleteArticle" mają dostęp grupy "Administrators" i "Moderators", to przy wyświetlaniu przyciski "Delete article" można albo sprawdzać przynależność do tych grup (wtedy trzeba pilnować żeby nie rozjechało się z wpisami przy akcji "DeleteArticle", albo sprawdzać config samej akcji, co kosztuje znacznie więcej.

Mam pytanie z innej beczki, lecz tez dotyczy jadra .

Mianowicie ile ? Jak dlugo wykonuje sie skrypt strony waszej, ktory analizuje dane, przetwarza je i wypluwa do przegladarki. Wlasnie dobiegl koncu pisanie mojego systemu i nie wiem czy sie cieszyc czy nie, ale jeszcze tak dlugo stworzone przeze mnie skrypty sie nie wykonywaly. Do rzeczy:



czy to duzo ? Moze podacie jakies swoje wyniki dla porownania. Moj system narazie zawiera automatycznie ladowane moduly, prosta administracje strony - tzn, administracja uzytkownikow, oraz edycjia pozycji w menu. W kazdym badz razie ten wynik wydaje sie jak dla mnie duzy. Ciekawi mnie w jakim czasie generuje sie np: to forum, lub vortal php.pl ...

pozdrawiam

zalezy tez od procesora oczywiscie...

hawk: ja bym sprawdzal tablice uprawnien aktualnego uzytkownika. taka tablice tworzylbym na poczatku i potem nie obchdozi mnie czy on moze to zrobic bo nalezy do tej grupy czy dlkatego ze ma solowe uprawnienia

Hmm, ale to nie jest takie proste. Bo ja widzę system uprawnień trochę jak system plików. Są sobie obiekty (u mnie: akcje), do których można nadawać prawa. System nie definiuje z góry ile takich obiektów może być, i w ogóle jakie są. Czyli nie definiujemy na sztywno praw "usuwanie artykułów" itd (całe mnóstwo), tylko jest obiekt "usuwanie artykułów" do którego można nadawać prawa.

No i teraz znalezienie wszystkich obiektów do których użytkownik ma dostęp nie jest proste. Raz że użytkownik należy do wielu grup. A dwa że ja bym chciał te obiekty mieć zagnieżdżane. Tzn jest sobie taki pseudo-katalog "artykuły", w nim "usuń artykuł", "dodaj artykuł" itd. I jak nadam prawa do "artykuły" to za jednym zamachem przenosi się to niżej. Czyli analogia z systemem plików, zwłaszcza tym z WinNT, jest bardzo trafna.

Ale "ja mam" oznacza tutaj "ja bym chciał żeby było w jądrze THOTa i czekam aż ktoś to napisze"

Ok, ok. ale to nie koliduje z elastycznoscia. Ja tylko mowie, ze na poczatku tablica uprawnien (zagniezdzona, czy nie, wielowymiarowa czy nie) zostaje wypelniona dla tego usera i do konca wykonywania strony uyzwam tej tablicy.

No cóż, fanatyczne trzymanie się MVC jest tak samo złe jak każdy inny rodzaj fanatyzmu...
W momencie, gdy chcemy, żeby framework robił coś inteligentnego, a nie tylko uruchamiał akcje (bo to można zrobić w kilku linijkach nawet), robi się pewien konflikt na styku Model - Kontroler. Ja bym powiedział tak: akcje SĄ częścią Kontrolera (nie kontrolera jako klasy, ale jako logiczna część aplikacji), więc skoro akcje mogą odwoływać się do Modelu, to kontroler (już jako obiekt) też może, więc sprawdzanie uprawnień przed wykonaniem akcji nie jest zbrodnią.

A poza tym - to nie jest problem tylko php. Ten Intercepting Filter, który chwalę, pochodzi z J2EE. A przecież to jest właśnie nasz problem - jest sobie "coś", co nie jest akcją, ale może grzebać w Modelu. Skoro oni mogą, to my też .

A pomysł z Model3 bardzo mi się podoba. Gdyby to nagłośnić, rozreklamować, i koniecznie opatentować, to wtedy żyć nie umierać.

mam pytanko

mozecie podac jakies materialy o pisnaiu jadra?

przeczytalem to co jest na webcity ale jakos za bardzo nie kumam :?

pytanie numer 2:
Przeglądając tak te wszystkie strony nie znalazłem nic na temat przekazywania informacji o modulach i operacjach jakie one maja wykonac. Bo zacząłem tworzyć system, w którym główna klasa pobiera (własnie, skąd?) informacje jakie modoly maja byc uruchomione i wysyla zapytanie do bazy (gdzie znajduje sie rejestr modolow i wymaganych uprawnien) skad otrzymuje informacje o wymaganych uprawnieniach usera i sprawdza czy takie ma jezeli nie to wyswietla stosowna informacje. Poczatkowo myslalem ze trzeba bedzie przesylac tylko dane dotyczace modolu glownego (biorac pod uwage ze wyglad bedzie standardowy czyli php-nuke'owy to modol glowny to bedzie "ten-na-środku") jednak pozniej stwierdzilem ze musze rowniez przekazywac dane dla innych modolow (tych wyswietlanych "po-bokach") i tutaj klops nie wiem w jaki sposob sie za to wziąć. Wiec chciałbym poznać jak Wy rozwiazujecie tą kwestie.

OT: router naprawdę zrobił karierę

Ju dawno o tym wspominalem, u mnie wyglada to troszke inaczej:

[php:1:5756255a0d]<?php
$cos_tam = $reg->get('comments/tbl_name', 'news');
?>[/php:1:5756255a0d]

Gdzie news to nazwa drzewa glownego, dalej mozna tworzyc strukture bez ograniczenia poziomu zaglebienia. Jest tez przegladarka, ktora nazwalem... regedit

Jest jeszcze oczywscie $reg->set ktory update'uje jezeli klucz jest, w przeciwnym wypadku dodaje nowy - a teraz zastanawiam sie jak przyjemnie zrobic usuwanie...

Wiem że jest niezbędny . Moja uwaga spowodowana była tym, że ja w różnych oficjalnych materiałach dot. MVC z routerem się nie spotkałem. Pewnego razu chyba wymyśleliśmy z Sethem na GG i daleki jestem od przypisywania nam/sobie jakiś zasług czy odkryć, ale koncepcja routera mocno się trzyma.

Chociaż ja widzę router inaczej niż ty. Bo piszesz o wzorcach URLi, przypisanych do akcji. A dla mnie podstawowym zadaniem routera jest podanie nazwy akcji -> więc musi zrobić swoje przed wykonaniem akcji. Potrzebujesz różne wzorce dla różnych akcji (czyli zapewne różne schematy URLi)? Bo tak jak ja to teraz mam, router zwraca właśnie nazwę akcji + tablicę parametrów które znalazł w URLu.

Co prawda nie robilem tego do modelu MVC, a do drzewek ale wykombinowalem to w ten spsob, ze skrypt sprawdza po kolei czy pierwsze elementy znajduja si ew sciezce - czy istnieje wogole taki element - i tak w gore szedlem do momentu az danego elementu nie bylo. W tedy reszte ze sciezki przekazywalem jako parametry.

Czyli gdy mamy np /cos/cos2/test/12 sprawdzamy po kolei czy mamy modul/akcje cos, a w nim pod modul/akcje cos2, a w nim podmodul/akcje test itd. Jezeli nie nie bedziemy mieli takiego modulu/akcji to uznajemy, ze ostatnio znaleziony element jest akacja i przekazujemy mu pozostale dane.

Malo to wydajne ale cos...

No to załóżmy że pierwsza rzecz po slashu to nazwa akcji, a druga to parametr. Routera nie obchodzi co ten parametr oznacza, to sprawa akcji.
Nie mówię że jest to super elastyczne, ale działa.

Poza tym, pamiętaj że router tak naprawdę powinien działać w obie strony. Znajdywanie parametrów w URLu to jedno, ale tworzenie URLa mając nazwę akcji i parametry też jest potrzebne. Inaczej i tak będziesz musiał zakodować na sztywno jakiś schemat w aplikacji, chociażby w linkach rozsianych po szablonach. A w przypadku, gdy każda akcja może kodować swoje parametry w inny sposób, router ma ciężkie zadanie.

W routerze właśnie chodzi mi o to, że jak dochodzisz do wniosku że jakiś schemat URLi ci nie odpowiada, a ktoś wymyslił coś bardziej eleganckiego, zamieniasz jedną klasę i cała aplikacja chodzi na nowym schemacie, bez zmiany ani jednej linijki. Taka przynajmniej jest teoria :wink: .

do tego o czym mowicie wykorzystuje sie standard. xlinks. Po co wymyslac cos na nowo?

A po co?
Skoro stawiam na router to mam pewność że engine będzie współpracować z czymkolwiek co ktoś sobie wymyśli. Mam ten komfort że mogę sobie to zupełnie ignorować i wiem że aplikacji mi nie zepsuje. :wink:

serafin:
"The XLink specification [XLink] defines ways for XML documents to establish hyperlinks between resources." - cytat ze specyfikacji. Jesli to ma sie nijak do tematu waszej rozmowy, to przepraszam.

gdzie można sie dokłądniej zapoznac z model'em 3 ?W szczególności chodzi o nowe elementy pośredniczące.

Byla tutaj mowa o IF, zapoznalem sie wstepnie z opisem tego wzorca na stronach javy, ale nadal nie pojmuje sensu jego dzialania. Byloby fajnie, gdyby ktos bardziej rozeznany napisal na forum 'z czym to sie je'

co samo jądro powinno robić? nie pytam się o cały cms tylko o konkretną klase/klasy

Myślę że jądro musi kontrolować dostęp do danych, kierować obsługą plików, bazą danych, konfiguracją. W php jest o tyle łatwo że nie trzeba kontolować sprzętu na serwerze.

Zajrzyj tutaj: http://forum.php.pl/index.php?showtopic=13770&st=100
Hwao zapodał tam kod jądra, poczytaj o MVC, też właśnie wgłębiam się powoli w podobne zagadnienia więc nic więcej Ci póki co nie powiem.

dokladnie.

jadro jest swego rodzaju szefem z najwyzszej polki tak jak w firmie, szef siedzi i zarzadza cala reszta. moze kontrolowac innych szefow a ci ludzi lub bezposrednio ludzi, w kazdym badz razie sam niczego nie robi, jedynie kontroluje i wydaje polecenia a za szczegoly odpowiadaja w roznym stopniu ludzie na roznych szczeblach w hierarchii

Mam pytanie. Czy jest jakaś książka która wprowadzi na wasz poziom, bo jest on bardzo zaawansowany. Naprzykład wydawnictwa HELION. Chciałbym wzbogacić umiejętności

Tak. Ta książka zwie się forum.php.pl
A pozatym to praktyka mistrzu

To znaczy pisać umiem i nawet zacząłem pisać stronkę ze sklepem (z koszykiem). Tylko że niekapie wszystkich pojęć, które używacie. A ty Vengeance ile piszesz w php? Bo ja od niecałego roku

tutorial MVC dla początkujacych(w. ang)
http://www.zend.com/zend/tut/tutsweatpart1.php

Napisz których pojęć nie rozumiesz, a my postaramy się je wytłumaczyć

Narazie tyle bo nie doczytałem całego teamtu. np:

Singleton, do czego słurzy metoda instance() i co oznacza ten zapis = &DB:get_DB(). W szczegłólności ten dwókropek.

Singleton - wzorzec projektowy, odsyłam do wyszukiwarki, googla

:: oznacza, że chcemy użyć metody statyczne, odsyłam do manuala, na zend.com też jest kilka artykułów

niedługo pojawi się na php.pl artykuł o singletonie

Fajnie dzięki, jak coś jeszze znajde to napisze

Mógłby ktos opisac mi po kolei do czego one wszystkie słuzą ? :|

Przecież jest opis na początku.

| Poziom | Podzial | pliki | Opis |

USER | Nakladki | *.skin | Nakladki wizualne na system

SYS/USER | Moduly | *.mod | Moduly spelniajace okreslone funkcje typu client/server rozne platformy

SYSTEM | Biblioteki | *.lib | funkcje i biblioteki systemu

SYSTEM | System | ***** | Jadro systemu

1. Sprawdzanie poziomow na ktorym pracuje dany modul/biblioteka.
2. Jadro zcentralizowane ale tzw. mikrojadro
3. Wyniesienie poza jadro testow uprawnien.
4. Niezalezne dzialanie modolow lub wspolne.
5. Udostepnianie uslug przez moduly
6. Itd...

Projekt w trakcie tworzenia.

rozumiem że w tym miejscu mogło by być coś w rodzaju *.tpl



Mógłbyś nieco rozwinąć temat. Wszystko o czym tu mówicie jest nieco zagadkowe, jabyście pisali sami dla siebie byle by pisać (sztuka dla sztuki).

Staram sie coś zrozumieć i nauczyć a tu hebrajszczyzna :?: