Witam. Jestem w trakcie pisania swojego kolejnego już cms'a i głównym jego założeniem jest uniwersalność i flexibility (elastyczność). W związku z czym mam pytanie to bardziej zaawansowanych użytkowników. Czy "opłacalne" w takiej aplikacji jest użycie SOAP czy Xml-Rpc (WebServices). I jeśli tak to mam z tym pewien mały problem. Załóżmy, że mam serwer, który przetwarza requesty i wysyła je klientowi. To jest w zasadzie proste. Ale co zrobić gdy do wygenerowania strony jest potrzebnych ponad setka zmiennych, od poziomu zezwoleń nadanych użytkownikowi (GACL) po zmienne sesyjne czy inne. Czy w takim wypadku transport tych zmiennych w jedną i drugą stronę jest opłacalny (w sensie szybkości). Zastanawia mnie głównie transport wszystkich zmiennych od klienta do serwera ... Czy ktoś ma pojęcie z Was w tym temacie ? Z góry dziękuje za odpowiedzi i za rozgryzienie mojego postu...


Może jeszcze podam mały przykład:

Request do serwera o wyświetlenie newsów, parametry: sort_by, limit.
A teraz załóżmy, że newsy kontrolowane są właśnie przez GACL. Czy wtedy mam przekazać również poziom zezwoleń użytkownika. i czy potem by wygenerować stopkę i header strony wysyłać kolejny request o dynamiczne dane Czy może całość strony którą chcę wygenerować otrzymać za pomocą jednego requesta i ptoem dzięki Smarty wyświetlić to??

Jeszcze jedna sprawa, zalozeniem cms'a jest szybkosc. O ile wiem ezPublish korzysta z SOAP i Xml-rpc i jest strasznie wolny. Co wiec proponujecie ?

Pozdrawiam

Co do tematu, to moze Seth Ci conieco napisze w wolnej chwili

Nie od dzis wiadomo, ze wydajnosc zyskuje sie przez upraszczanie calego dzialania - im mniej danych jest przesylanych/na mniejszej ilosci danych musisz operowac, tym calosc powinna byc wydajniejsza.
W warstwie komunikacyjnej powinny byc przesylane tylko podstawowe dane, niezbedne do prawidlowego funkcjonowania calej aplikacji.

Napisz dokladniej w czym rzecz (jesli jeszcze cos jest niejasne), bo uwazam ze moje dosc ogolne wypociny idealnie rozwiazuja przedstawione problemy (moze z wylaczeniem wyboru odpowiedniej technologii).

Troche sie o tym naczytalem, wiec odrazu powiem, ze SOAP w przypadku php IMHO odpada.
Co do XML-RPC to niestety ale jako, ze jest to wykorzystanie "zdalnyh" procedur zawsze wiaze sie ze strata wydajnosci.
Myslalem kiedys o stworzeniu CMSa bazujacego tylko na web services ale po testach zrezygnowalem. 15 prostych zapytan na localu zajelo ok 8s.

Dlatego web services uzywal bym oszczednie. Czyli w takich przypadkach gdy ktos z zewnatrz potrzebuje pewnych danych, ktore my udostepniamy. Web services powinien byc dodatkiem a nie glowna czescia systemu.
Chociaz sa i systemy oparte na webservicach jako skladowe workflowu ale te sa postawione na specjalnie do nich dedykowanych maszynach i nie sa pisane w php.

btw: Sa juz gotowe implementacje XML-RPC gdzie nie musisz juz sam pisac obslugi XMLa itp.
Z ciekawszych polecam: http://phpxmlrpc.sourceforge.net/ i http://scripts.incutio.com/xmlrpc/
Dodam jeszcze, ze mozna nieco przyspieszyc same XML-RPC przez cacheowanie wynikow.


W naszym systemie uzyjemy wlasnie phienda - zmodyfikowanego, wiec polecam go BTW. Moze hawk sie wypowie w tej kwesti ?


CMS to ogolne pojecie systemu do zarzadzania informacjami, a to jakich mechanizmow - wzorcow projektowania aplikacji uzyjesz to juz Twoja sprawa.
MVC to wlasnie taki wzorzec pisania aplikacji.
Poczytaj sobie to: http://forum.php.pl/viewtopic.php?p=48913#48913 powinno Ci pomoc

Ja również polecam phienda . Reklama dźwignią handlu. Phrame akurat nie polecam, bo jest wolny i za dużo w nim Javy kosztem php (jak ktoś zamiast tablic i foreach() robi sobie klasy ArrayList i Iterator, to coś jest nie tak :?).



CMS da się zrobić na bazie MVC, a przynajmniej w to wierzymy, bo inaczej nasze prace w tym zakresie byłyby bez sensu .

Seth już podał linka do mojego opisu MVC. Generalnie różnica pomiędzy MVC i CMS jest, hmm, taka, że to jest inna kategoria. MVC jest wzorcem, stosowanym nie tylko dla aplikacji internetowych. W ogóle to MVC wymyślił chyba Xerox dla Smalltalka (btw: niesamowity język, jednocześnie prosty jak trzonek od łopaty i zakręcony jak świński ogon ). Więc jest to sposób robienia aplikacji. A CMS wiadomo - pewna klasa systemów.

W sumie MVC jest proste. Jeżeli tylko aplikacja podzielona jest odpowiednio na Model-View-Controller, to masz MVC. Cała reszta to dodatki specyficzne dla implementacji.

Generalnie, nie wiem gdzie przebiega taka granica . Zwłaszcza że zależy to w dużej mierze od systemu na którym się testuje.
Lepsze byłoby porównanie, co zżera więcej czasu: twój piękny obiektowy kod czy np. Smarty. Jeżeli to drugie, to i tak dużo nie zwojujesz...

Zresztą, stosując OOP godzimy się na pewną utratę wydajności. W zamian za modyfikowalność, jakość, time-to-market, itd.

A teoretycznie rzecz biorąc, należałoby zacząć od analizy, ile będziemy mieli wejść na godzinę i jakiej wydajności wymagamy.

Chociaż w sumie to oczywiste i nic mądrego nie napisałem :?.