Witam

Po dluzszym watku na grupie pl.comp.lang.php odnosnie wyboru frameworku
PHP (dla back-end) oraz frameworku do strony wizualnej (dla front-end)
doszedlem do takiej koncepcji aby w obecnych czasach strone kliencka
wykonywac po stronie przegladarki za pomoca frameworku js np. AngularJS
+ formatowanie wygladu kontrolek za pomoca Twitter Bootstrap (wszystko
co sie da robic po stronie klienta np. formatowanie danych, walidacja,
itp.) natomiast po stronie serwera gdzie jest wspolna baza danych
wykonac tylko serwis REST w PHP ktorego zadaniem bedzie jedynie obsluga
operacji bazodanowych CRUD (np. pobranie danych do gridow, aktualizacja
danych, itp.). Czy taka koncepcja jest sluszna ? Nie mieszalbym teraz
PHP (strona serwerowa) ze strona wizualna jak to dawniej bylo w praktyce
(np. wplatanie "echo" w kod HTML). Szukam tylko dobrego tutoriala ktory
by cos takiego wyjasnial poniewaz np. nie wiem czy mozna z bazy danych
serwera REST pobrac liste z zapytania SQL do jakiegos obiektu framewroku
js w porcjach, a potem z niego do grida.

Dziekuje.

Pozdrawiam
M.K.

do góry

On Monday, May 18, 2015 at 9:05:13 PM UTC+2, MK wrote:
> Witam
>
> Po dluzszym watku na grupie pl.comp.lang.php odnosnie wyboru frameworku
> PHP (dla back-end) oraz frameworku do strony wizualnej (dla front-end)
> doszedlem do takiej koncepcji aby w obecnych czasach strone kliencka
> wykonywac po stronie przegladarki za pomoca frameworku js np. AngularJS
> + formatowanie wygladu kontrolek za pomoca Twitter Bootstrap (wszystko
> co sie da robic po stronie klienta np. formatowanie danych, walidacja,
> itp.) natomiast po stronie serwera gdzie jest wspolna baza danych
> wykonac tylko serwis REST w PHP ktorego zadaniem bedzie jedynie obsluga
> operacji bazodanowych CRUD (np. pobranie danych do gridow, aktualizacja
> danych, itp.). Czy taka koncepcja jest sluszna ?

Potencjalnie jest słuszna i to bardzo. W praktyce dużo może pójść nie tak
jakbyśmy chcieli. Przede wszystkim musisz mieć zestaw gotowych komponentów
do Twojej aplikacji. Wyświetlanie htmla przez echo to prymitywna metoda, ale
także szybka i prosta. Jeśli podejdziesz do projektu Twoją metodą, to
może się okazać, że będziesz musiał napisać brakujący komponent. Jeśli
komponent wykorzystasz tylko 2-3 razy, to prawdopodobnie stracisz czas.
Może się okazać, że przez komponenty można omijać zabezpieczenia aplikacji,
albo można komuś zalogowanemu podsyłać niebezpieczne linki. Nie wiem, ale
strzelam, że będziesz musiał zainwestować minimum pół roku, a potem na
dwoje babka wróżyła: albo znajdziesz dobre rozwiązania i środowisko które
je wspomaga, albo uznasz że był to czas stracony.


> Nie mieszalbym teraz
> PHP (strona serwerowa) ze strona wizualna jak to dawniej bylo w praktyce
> (np. wplatanie "echo" w kod HTML). Szukam tylko dobrego tutoriala ktory
> by cos takiego wyjasnial poniewaz np. nie wiem czy mozna z bazy danych
> serwera REST pobrac liste z zapytania SQL do jakiegos obiektu framewroku
> js w porcjach, a potem z niego do grida.

W sumie też bym poczytał takie tutoriale, ale rzetelne i obustronne, a nie
takie które tylko pokazują zalety, albo tylko wady.

Pozdrawiam

do góry

On 2015-05-18 21:05, MK wrote:
> Witam
>
> Po dluzszym watku na grupie pl.comp.lang.php odnosnie wyboru frameworku
> PHP (dla back-end) oraz frameworku do strony wizualnej (dla front-end)
> doszedlem do takiej koncepcji aby w obecnych czasach strone kliencka
> wykonywac po stronie przegladarki za pomoca frameworku js np. AngularJS
> + formatowanie wygladu kontrolek za pomoca Twitter Bootstrap (wszystko
> co sie da robic po stronie klienta np. formatowanie danych, walidacja,
> itp.) natomiast po stronie serwera gdzie jest wspolna baza danych
> wykonac tylko serwis REST w PHP ktorego zadaniem bedzie jedynie obsluga
> operacji bazodanowych CRUD (np. pobranie danych do gridow, aktualizacja
> danych, itp.). Czy taka koncepcja jest sluszna ?

Koncepcja jak koncepcja. Prawie niczym się nie różni od typowego grubego
klienta starych desktopowych aplikacji tyle że inny język/framework.
Problemy też będą podobne. Im wiekszy program i im więsza baza danych
tym więcej danych będzie przepychane przez sieć. Z tym że desktopy
chodzą na sieci lokalnej o znacznie większej przepustowości. Do tego
dochodzą kwestie bezpieczeństwa, które przy ograniczonej logice po
stronie serwera trudno zapewnić. Przy czym tak jak pisałem, problemy są
zauważalne dopiero dla większych aplikacji.


--
Darek

do góry