![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
![]() Grupa: Zarejestrowani Postów: 56 Pomógł: 0 Dołączył: 23.11.2003 Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
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 ![]() 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 |
|
|
![]()
Post
#2
|
|
![]() Grupa: Zarejestrowani Postów: 602 Pomógł: 0 Dołączył: -- Skąd: W - WA -> GRO Ostrzeżenie: (0%) ![]() ![]() |
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). -------------------- Zanim zadasz pytanie, zawsze wczesniej zajrzyj do manuala ( pl.php.net/manual/pl/ ).
Szukasz skryptow - www.hotscripts.com |
|
|
![]()
Post
#3
|
|
![]() Grupa: Przyjaciele php.pl Postów: 2 335 Pomógł: 6 Dołączył: 7.03.2002 Ostrzeżenie: (0%) ![]() ![]() |
Cytat Co do tematu, to moze Seth Ci conieco napisze w wolnej chwili
![]() ![]() 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. |
|
|
![]()
Post
#4
|
|
![]() Grupa: Przyjaciele php.pl Postów: 2 335 Pomógł: 6 Dołączył: 7.03.2002 Ostrzeżenie: (0%) ![]() ![]() |
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. Cytat Seth a co sadzisz o MVC ? Przegladalem ostatnio phienda i phrame i powiem ze moj cms duzo sie pod wzgledem mechanizmow dzialania nie rozni.
W naszym systemie uzyjemy wlasnie phienda - zmodyfikowanego, wiec polecam go ![]() ![]() Cytat Czy wiec to nadal jest cms czy juz mvc?? Jaka jest roznica miedzy tymi systemami?? Czy Cms powstać może na bazie MVC
![]() 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 ![]() |
|
|
![]()
Post
#5
|
|
![]() Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) ![]() ![]() |
Cytat Przegladalem ostatnio phienda i phrame i powiem ze moj cms duzo sie pod wzgledem mechanizmow dzialania nie rozni.
Ja również polecam phienda ![]() Cytat Czy wiec to nadal jest cms czy juz mvc?? Jaka jest roznica miedzy tymi systemami?? Czy Cms powstać może na bazie MVC
![]() 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 ![]() 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. |
|
|
![]()
Post
#6
|
|
![]() Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) ![]() ![]() |
Generalnie, nie wiem gdzie przebiega taka granica
![]() 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 :?. |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 19.07.2025 - 07:51 |