🚀 go-pugleaf

W dniu 2014-12-18 o 15:37, M.M. pisze:
> On Thursday, December 18, 2014 12:56:29 AM UTC+1, Kviat wrote:
>
>> To jest do projektowania warstwy wizualnej, którą możesz sobie użyć z
>> dowolnym serwerem. To dobrze.
> Zaletą jest to, że można użyć tejże warstwy wizualnej w wielu frameworkach a
> nawet w wielu językach programowania. Niestety ta zaleta implikuje
> taką wadę, że środowisko nie umie wycisnąć wszystkich soków z danego
> frameworka. No chyba że z każdego języka wspiera szczegółowo 2-3 najbardziej
> popularne frameworki.

Nie mogę się z tym zgodzić. Znaczy z tą niemożnością wyciskania 
wszystkich soków :)
No chyba, że bardziej sprecyzujesz co znaczy "szczegółowo".

Zobacz przykład:
http://dhtmlx.com/docs/products/dhtmlxGrid/samples/04_dataprocessor/01_basic_init.html

http://dhtmlx.com/docs/products/dhtmlxGrid/samples/04_dataprocessor/13_json_response.html

Jeżeli warstwa wizualna jest osobną aplikacją, to jedyne o co muszę 
zadbać na serwerze to prawidlowo wysłać (czy odebrać) xmla lub jsona.
A to mogę zrobić z dowolnego frameworka, albo nawet ręcznie wyrzeźbić od 
zera.

Tutaj akurat jest php:
mygrid.loadXML("php/get.php")

ale ja mam zrobione tak, że nie muszę podawać rozszerzenia, czyli
mygrid.loadXML("controller/metoda/parametry(opcjonalnie)")
(grid to tylko przykład)

I w przypadku zmiany serwera (albo tylko frameworka php), np. na 
windowsa nie muszę nawet dotykać warstwy wizualnej. Wystarczy, że w 
aplikacji na serwerze właściwie zorganizuję routing "controller/metoda".


> Chodź założymy nowy wątek, ja w nim będę pisał że nie wiesz że php generuje
> kod html, a ty że nie odróżniam warstwy wizualnej od obliczeniowej, proponuję
> minimum 4 posty dziennie, przegrywa ten kto pierwszy nie utrzyma tempa :D

Dobra. Zakładaj ;)

> Chwila. To że IDE operuje na komponentach PHP tak aby te komponenty
> wygenerowały kod wizualny (i nie tylko), nie oznacza jeszcze że IDE jest
> do wszystkiego.
>
> Do wszystkiego jest wtedy, gdy:
> 1) umie wycisnąć soki z każdego popularnego frameworka w każdym popul. języku

Xmla da się wysłać i odebrać praktycznie w każdym frameworku czy języku. 
No, oczywiście niektóre framweorki mają (lub nie mają) jakieś dodatkowe 
biblioteki wspierające xmla (czy jsona), ale to przecież szczegół, w php 
json_encode załatwia sprawę.

> 2) generuje tylko to, co potrafi obsłużyć każdy framework, np. tylko htmla

I dla mnie to jest właśnie zaleta. Zwróć uwagę, że większość tych visal 
designerów pozwala na zbudowanie aplikacji, która z serwerem komunikuje 
się ajaxem. Ani grama php czy innego języka. "Czysty" (umowmy się, że 
czysty ;)) html/javascript/css.
(nie korzystam z visal designerów, ale chodzi o ideę - w Sencha czy 
Dhtmlx to samo można zrobić na piechotę)
Oczywiście ma to swoją specyfikę i taka budowa bardziej to się nadaje do 
backendów, ale te kontrolki można wykorzystać również jako pojedyncze 
elementy we fontendzie.

Z drugiej strony, na serwerze w aplikacji czysty php.
Oczywiście w teorii, bo w praktyce nie zawsze się tak da. Tak czy 
inaczej, wypluwanie htmla z php sprowadzone do absolutnego minimum.

> Ten pierwszy przypadek byłby dobry, ale jestem sceptyczny że komuś udalo się
> napisanie takiego frameworka.

Obok pisałem, że właśnie sprawdzam sobie ten CodeCharge Studio. Fajne 
narzędzie, tomek pisze, że robi w tym coś większego. Znaczy się można.
Mnie to na razie nie przekonało (patrzę co te studio tam tym automatem 
generuje) ale możliwe, że to kwestia przetrawienia. Zbyt duży chaos jak 
dla mnie.

> Dlatego mówię że jak coś jest do wszystkiego,
> to prawdopodobnie jest do niczego. Ten drugi przypadek z kolei sprawia
> wiele kłopotów. Wszelkie zmiany w projekcie wymagają przepisania
> dużej ilości kodu, ponownego podpinania modułów, itd.

Moim zdaniem to kwestia organizacji. Dodanie grida na stronie, to 
dodanie nowego controllera na serwerze dla tego grida. Nic nie trzeba 
przepisywać.
Nawet zmiana, powiedzmy, ilości kolumn w gridzie, to kosmetyczna zmiana 
w kontrolerze. A w skrajnym przypadku w ogóle nie ruszam kontrolera, 
tylko w kontrolce ustawiam kolumnę jako nie widoczną i już ;) (tylko nie 
pisz, że to amatorszczyzna - skrajny przypadek to mus :) - do 
prototypowania wyglądu dla klienta idealne)


>> No ale właśnie te IDE do projektowania warstwy wizualnej są
>> wyspecjalizowane w projektowaniu warstwy wizualnej.
> Ale warstwa wizualna, warstwie wizualnej nie jest równa. Każdy framework
> inaczej pobiera dane,

Masz na myśli framework php?

Hmmm... framework jest po to, żeby działał jak ja chcę. Co to znaczy 
inaczej pobiera? Jak ma pobrać np. xmla to go pobieram, jak ma go wysłać 
to wysyłam. Postem, getem, echo... bez różnicy.

> inaczej przeprowadza autoryzację, itd.

Ale warstwy wizualnej nie interesuje jak framework to robi. Ma do 
serwera wysłać login i hasło. Co framework z tym zrobi to jego sprawa.

> Jeśli
> IDE nie jest świadome tych cech framweorka, to bez testowania tegoż IDE
> z góry wiadomo, że nie może uzależnić widoku od danych, autoryzacji, itd.

Właśnie m.innymi idea takiego IDE mnie nie przekonuje. Jak już bym się 
na niego zdecydował, to jestem na niego skazany.

> Potem trzeba to wszystko robić ręcznie. W momencie gdy dochodzi do zmiany
> w projekcie, masz do wyboru dwa rozwiązania:
> 1) poprawić ręcznie trudny i duży kod wygenerowany przez automat

Wiesz, ja tam wolę poprawiać kod po sobie, albo po koledze, którego mogę 
spytać o co kaman w tym fragmencie...

> 2) wygenerować na nowo i na nowo uzależniać (ręcznie!) widok od danych i autoryzacji

Ale to zależy do skali zmian. To oczywiste, że po przekroczeniu jakiegoś 
progu to czasem lepiej wyrzucić do kosza i napisać od nowa.

> I jeden i drugi przypadek jest upierdliwy. Po 10 zmianach ja miałem tak
> szczerze dosyć, że wyjebałem rozwiązania na takich IDE.

No nareszcie w czymś się zgadzamy ;)

> Teraz nagle wracamy do pierwszego pytania - super. Chodzi o to, czy
> środowisko które generuje warstwę wizualną w oderwaniu od konkretnego
> frameworka w ogóle może w skomplikowanych projektach być pomocne?

A czemu nie, kolejny przykład:
http://www.bindows.net/
http://www.bindows.net/demos/

> Do prostych projektów, albo do prototypu żeby pokazać klientowi zapewnie
> jest dobre. Ale czy może uczynić pracę tak wygodną jak w takim delphi czy
> qtcreator? Myślę że nie może.

Ale to kwestia organizacji. W takim Delphi jak piszesz aplikację to tam 
masz warstwę widoku i logiki w jednym (nie wnikajmy w szczegóły) - 
traktujesz to jak jedną całość. Jednego bez drugiego nie uruchomisz.

Aplikację webowej potraktuj jakbyś miał dwie aplikacje, a życie stanie 
się prostsze :)
Do warstwy wizualnej bierzesz dobry framework ajaxowy - dobrze napisana 
może pracować bez połączenia z serwerem, korzystasz z dobrodziejstw 
takich jak local storage itd..
Do warstwy serwerowej bierzesz dobry (albo taki, który najbardziej 
lubisz ;) framework php.

Czy to jest wygodne? W Delphi aplikację możesz wyklikać - wygodne to to 
jest... ale też chyba tylko na etapie prtotypowania dla klienta, bo 
później się mści.

> Właśnie co do tego przyspieszenia (ale liczonego sumarycznie) nie
> jestem przekonany. Wiem że można wygenerować w takich środowiskach
> szybko warstwę wizualną. Wiem że można ją podpiąć pod aplikację
> webową. I do tego momentu bez wgryzania się w szczegóły środowiska,
> domyślam się, że praca przebiega super efektywnie. Pytanie co dalej?
> Klient np. chce poprawki w warstwie wizualnej. Co robimy wtedy?
> Znowu generujemy warstwę wizualną

A dlaczego? Nie można zrobić tylko tej poprawki? Od razu trzeba od nowa 
całość generować?
Tu masz wersję online takiego IDE.
http://dhtmlx.com/docs/products/visualDesigner/live/

Zapisujesz co zrobiłeś, chcesz nanieść poprawkę - wczytujesz, robisz 
poprawkę i zapisujesz.
(od razu zaznaczam, że to tylko przykład, że się da - nie korzystam, jak 
robię coś z dhtmlx to robię ręcznie, w "notatniku" ;))

> i znowu podpinamy ją pod aplikację
> webową?

Nie... na serwerze dopisujesz/zmieniasz tylko to co dotyczy tej poprawki.

> I tak 10 poprawek i 10 razy taka sama robota?

Nie :) 10 poprawek to dziesięć poprawek, a nie 10 razy od nowa :)

> Zastanawiam się, czy nie lepiej napisać z palca warstwę wizualną i
> jak klient chce poprawki, to pamiętamy co szybko zmienić - i mamy
> dodatkową zaletę - warstwa wizualna będzie szybko się ładowała i
> szybko przeglądarka ją zrenderuje.

W przypadku tych frameworków ajaxowych (sencha itd.) czy zrobisz z palca 
czy designerem to bez różnicy na szybkość renderowania. Kontrolki te same...
Jak już pisałem, ja wolę z palca bo łatwiej mi to ogarnąć.

> Zwróć uwagę, że
> środowiska do budowania warstwy wizualnej za pośrednictwem PHP mogłoby
> nie mieć takich problemów. Przesuwamy głupi guzik czy obrazek, a kod
> zdarzeń pozostaje taki sam - tak jak w delphi czy qtcreator.

Tak właśnie działają te designery :)

>>>> Chcesz dobre IDE które to wspiera? Proszę bardzo:
>>>> pierwsze z brzegu: https://netbeans.org/
>>> Żeby nie było: Netbeans jest jednym z najlepszych IDE jakie widziałem.
>>> Natomiast mam pytanie, skąd ta pewność, że dobrze wspiera
>>> zenda i symfony?
>>
>> Zenda i symfony dobrze wspiera też Notatnik, a taki Notepad++ to już
>> hoho... To co dopiero Netbeans?
> Czyli dla Ciebie jak coś jest lepsze od notatnika to już oznacza super
> wsparcie dla frameworka?

Nie frameworka, ale php. Framework to rzecz wtórna.
Code completion ,podświetlanie składni, pomoc w dokumentowaniu... itd...
Podaję ścieżki do core frameworka i mam autouzupełnianie meteod w 
klasach potomnych... czego więcej chcieć? ;)

> Nasze wymagania różnią się o 10 poziomów, może
> dlatego  nie możemy się dogadać?

Bardzo możliwe. Mówiłeś, że lubisz Symfony, czego konkretnie brakuje 
Netbeansowi?

>> Ale ja żadnego takiego sensownego IDE nie znam.
>> Te które próbowałem robiły z kodu sieczkę.
> No cóż, jak nie ma takiego IDE to nic nie poradzimy. Moim zdaniem
> potrzeba kwoty 8 cyfrowej żeby napisać takie IDE. Nie wiem czy
> by się sprzedało potem 10tys instalacji za 1tys każda... może.

http://twojstartup.pl/ ;)


>> Przetestuj proszę i powiedz czy to się do czegoś nadaje. Do czegoś
>> poważniejszego. Nie mówię, że nie, nie używałem - ale głównie chodzi mi
>> o to, czy w wyniku takiego "generowania" nie robi kaszanki mieszając php
>> z htmlem...
> Tutaj bym musiał powiedzieć o czymś, czego nikt nie pozwoli mi opatentować :/
> Dlatego przykro mi i się nie wypowiem. Chociaż nie wiem... taki qtcreator
> ma coś podobnego... może już nie mam czego ukrywać...

Podziel się. Wal prosto z mostu :)


>> Bo chyba rozmawiamy jak jest, a nie jak mogło by być.
> Rozmawiamy jak jest. Ale poza tym że obecnie nie ma dobrego IDE
> do wizualnego projektowania w PHP, jest jeszcze druga sprawa.
> A mianowicie taka, że generowanie warstwy wizualnej w całkowitym
> oderwaniu od frameworka PHP, nastręcza wiele problemów.

Ale wiele problemów rozwiązuje.

> Czasami
> mam wrażenie, że te problemy biorą górę nad zaletami.

Ja mam wrażenie odwrotne. Ale jak zwykle, to zależy... tzw. armata na 
muchy - czasem nie warto i wystarczy echo("<b>Witaj świecie!</b>");

>>> Generowanie osobno HTMLa to proteza.
>> Wręcz przeciwnie.
> Może faktycznie, ale póki co ja tego nie rozumiem. Tak, rozumiem
> że PHP trochę się różni od HTML, ale nie rozumiem, że generowanie
> HTMLa w takim IDE jest efektywnym sposobem pracy :D Wytłumacz
> mi, proszę.

No starałem się powyżej.
Dodatkowa zaleta:
do warstwy wizualnej bierzesz specjalistę od html/css/javascript (może 
nawet nie znać php - teoretycznie)
Do warstwy serwerowej bierzesz specjalistę od php, C# czy coś tam (może 
nawet nie znać htmla - teoretycznie ;) - a już na pewno nie musi znać 
wszelkich niuansów i haków z css zależnych od przeglądarki - to wie 
htmlowiec)
Każdy skupia się na swojej robocie.

Dla samotnego freelancera ta zaleta jest dyskusyjna. Czyli jak zwykle:to 
zależy...

> Generujemy w IDE np. stronę główną. Więc mamy kod wizualny. Możemy
> ten kod wrzucić na serwer. Mamy od razu stronę główną, bez zaglądania
> do kodu! Super, rewelacja. Do prostych stron takie środowiska są
> idealne. Potem chcemy mieć jakiś drobiazg na stronie głównej, np.
> licznik odwiedzin. Więc jak postępujemy? Generalnie są dwa podejścia.
> Na pewno w IDE jakoś zaznaczamy diva, aby potem go odnaleźć w kodzie.
> Potem w tym divie albo wstawiamy kod php,

No nie w warstwie wizualnej :) Umawiamy się, że konsekwentnie oddzielamy 
warstwy.

> albo JS i AJAX, a w
> PHP tylko obsługa zapytania AJAX.

No tak.

> Oprogramowujemy jednym lub
> drugim sposobem i mamy licznik. Dobrze myślę, czy już coś mylę?

No tak. :)

> Jeśli dobrze, to potem chcemy zmianę w na stronie głównej. Więc
> generujemy na nowo w IDE warstwę wizualną.

To już chyba ustaliliśmy :) Robisz zmianę, nie robisz od nowa.

> A stary kod podpinamy
> na nowo.

Skoro nie robisz od nowa, to nie ma co od nowa podpinać.
Podpinasz/zmieniasz w php tylko to co dotyczy zmian na stronie wizualnej.
Inaczej to nie miałoby sensu przecież :)

> Jeśli takich drobiazgów jak licznik mamy na stronie 10,

To wstawiasz te 10 drobiazgów.

> a
> poprawki wprowadzamy 20 razy, to łącznie mamy 200 ponownych wstawień
> starego kodu. Dobrze mówię, czy coś mylę?

Mylisz :) Nie mam pojęcia skąd te 200.

10 poprawek w warstwie wizualnej + 20 poprawek w logice aplikacji php = 
to mi wychodzi razem 30 poprawek.

> Jeśli mylę, to może
> faktycznie powinienem się bliżej zainteresować tymi środowiskami i
> lepiej je poznać. Jeśli niczego nie pomylilem, to chyba już rozumiesz,
> dlaczego takie IDE uważam za protezę.

Myślę, że to konsekwencje przyzwyczajeń z "klikalnych" IDE dla aplikacji 
desktopowych.

>> Wyżej pisałeś, że jak jest do wszystkiego to źle. Już się pogubiłem.
> Jak wyżej pisałem. Jeśli jest do wszystkiego,
> czyli wspomaga technologię tworzenia aplikacji webowej od początku
> procesu tworzenia do samego końca - to jest dobrze.

Ja rozumiem co masz na myśli. Ale to inna specyfika. Nie można 
zapominać, że aplikacja webowa to nie tylko przeglądarka na desktopie w 
rozdzielczości 1920x1080, to tablety, pierdzifony czy inne wynalazki. 
Wyklikanie myszką wyglądu strony tak, by to było czytelne niezależnie od 
urządzenia to nie jest prosta sprawa.
Teraz taka moda (jak ten świat się zmienia :)) na "responsive 
templates". Weź to wyklikaj myszką w IDE... powodzenia :)

> Wyspecjalizowane
> może byłyby lepsze, ale programista musiałby się przełączać pomiędzy
> 10cioma programami. Lepiej te programy zawrzeć w jednym IDE.

Lepiej dla kogo? Właśnie. To zależy...

> Natomiast
> jak jedno IDE próbuje wspomagać wszystkie technologie, to można domniemać,
> że żadnej nie wspomaga wystarczająco dobrze.

I wychodzi jakaś drutowana hybryda :)


>> Do części wizualnej używam tego:
>> http://dhtmlx.com/
>> (to ma nawet helpery serwerowe:
>> for PHP Connector (including integration with CodeIgniter, Yii, and
>> CakePHP frameworks)
> Jak ma taki integrator z frameworkiem, to widzę światełko w tunelu :)
> Szkoda że nie ma symfony i zenda, jakoś najbardziej ufam tym dwóm
> frameworkom.

Jak zajrzysz do tego Connectora to sobie coś takiego w symfony 
wyrzeźbisz w godzinę.


>> W czym ten serwis byś nie zrobił - nie zmienisz faktu: strona wizualna
>> to ani php, ani masm. I projektowanie części wizualnej w przeglądarce
>> nie ma z tym nic wspólnego. A w kontekście przyspieszenia pracy: na
>> szczęście.
> Nie kumam. Co na szczęście?

Pytałeś o przyśpieszenie pracy.
Już pisałem, podział obowiązków. W aplikacji webowej (w przeciwieństwie 
do takiego np. Delphi) podział widok-kontroller (na szczęście) jest 
jakby naturalny. Zatrudniasz dwóch ludzi i powstają równocześnie. Nawet 
znać się nie muszą :)

(znowu: nie chcę powiedzieć, że w Delphi się nie da, ale to dyskusja na 
inną grupę :))

>> I wcale to nie jest warunek konieczny żeby środowisko do php musiało
>> zawierać edytor wysiwig do htmla aby go nazwać dobrym.
> Są różne kryteria oceny. Ja za ważne kryterium uznaję takie, które
> skraca czas pracy w przypadku aplikacji webowych pisanych w PHP.
> Nie interesuje mnie rozmowa o jakimś aspekcie, choćby było najlepszy,
> jeśli potem w całym procesie technologicznym odgrywam małą rolę.

Ale bez tego "aspektu" to możemy gadać w nieskończoność o niczym i o 
wszystkim.
Jak widać, inaczej widzimy "skracanie czasu pracy".

>>> Dobre środowisko mogłoby w ogóle HTMLa ukryć,
>> Ale jak chcesz ukryć htmla, kiedy właśnie chcesz wizualnie projektować
>> stronę?
> Nie usunąć z projektu, tylko ukryć przed programistą. Jak ukryć od
> strony technicznej? Np. trzymać w osobnych plikach, do których
> programista nie musi zaglądać.

Ja tak właśnie robię.
Osobno framework ajaxowy, osobno php...
Ale jednak czasem muszę zajrzeć... ;)

Pozdrawiam
Piotr