🚀 go-pugleaf

Dnia Tue, 16 Dec 2014 05:30:56 -0800 (PST), silos10000@gmail.com
napisał(a):

> to czy w takim przypadku takze nie ma zintegrowanego srodowiska
> pozwalajacego z jednej strony osadzic elementy edycyjne, przyciski, pola
> wyszukiwania, itp. i nastepnie podpiac pod te elementy odpowiednie
> procedury z czesci serwerowej w wygodny sposob? W takim srodowisku
> ukladalbym sobie w/w elementy wygodnie dopierajac ich polozenie, wyglad
> i dodajac zdarzenia z czesci serwerowej.

Nie. To jest dodatkowo na frameworku RWD, który operuje na wartościach
procentowych i media queries. Powodzenia w przekładaniu tego na automatykę.



-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Tuesday, December 16, 2014 2:30:57 PM UTC+1, silos...@gmail.com wrote:
> Witam ponownie
> 
> Przepraszam, ze jeszcze pociagne temat na podsumowanie.
Ależ pisz, to dobry temat na tę grupę i ten wątek.

> Jezeli chce np. zbudowac prosta, toporna aplikacje www np.
> https://budzet.czestochowa.um.gov.pl:81/
Nie wiem czy jest prosta. Na pierwszy rzut oka wygląda prosto, ale z
tego nie wynika, ani że jest prosta dla docelowego użytkownika, ani że
jest prosta do wykonania.

> to czy w takim przypadku takze nie ma zintegrowanego srodowiska pozwalajacego
Szczerze nie wiem. Jak już pisałem, w dreamweaver widziałem jak ktoś generował
dużo elementów wizualnych, ale potem je przerabiał ręcznie. 

Kiedyś grafik dał mi gotowy layout z animowanym menu i innymi cudami. 
Działało to perfekcyjnie na wszystkich przeglądarkach, na telefonach, a że grafik miał trochę pojęcia, to jeszcze było przyjazne dla osób niepełnosprawnych. Wszystko wygenerowane z automatu. Wydawało 
się że to dobra technologia. Niestety wady uaktywniały się później. 
Dodanie jakiegoś detalu było trudne. Po kilku ręcznych zmianach było 
mniej zaoszczędzonego czasu niż włożonego. Kod nie nadawał się do 
wydzielenia wspólnych elementów, jeśli były małe różnice na 
pod-stronach, to trzeba było generować każdą pod-stronę
od nowa. Każda pod-strona była diabelnie duża, renderowanie
mocno obciążało procesor, pliki css miały po kilka tys linii kodu...


> z jednej strony osadzic elementy edycyjne, przyciski, pola wyszukiwania, itp.
> i nastepnie podpiac pod te elementy odpowiednie procedury z czesci serwerowej > w wygodny sposob? W takim srodowisku ukladalbym sobie w/w elementy wygodnie 
> dopierajac ich polozenie, wyglad i dodajac zdarzenia z czesci serwerowej.
W wygodny sposób czyli bez pisania kodu? Nawet jeśli znajdziesz takie
środowisko, to nie wiem czy dużo zaoszczędzisz czasu. Strony są niestandardowe,
strona www to nie to samo co aplikacja. Zawsze trzeba jakieś niestandardowe
elementy wklepać z palca. Zaoszczędzony czas, relatywnie od czasu całego 
wykonania projektu, może i tak okazać się bardzo mały.

Ktoś np. chce taki formularz, żeby pojawiały się dynamiczne nowe pola. A jak
tekst wybrany w polu select zaczyna się od 'silnik', to wyskakuje checkbox
do zaznaczenia czy nowy czy używany. Jakiś automat wygeneruje podobną
formatkę i guzik do wysłania. Potem trzeba się wgryźć w wygenerowany kod i
dopisać dynamikę. Zwykle automaty generują masę kodu, zwykle od zera można
napisać szybciej, niż analizować kod wygenerowany przez automat...

Myślę, że nie bez powodu technologie tworzenia aplikacji webowych
rozwijają się w kierunku edycji po zainstalowaniu frame-worka.

W netbeansie są opcje do pracy na frameworkach, więc jakieś
wsparcie ma. Niestety nie wiem jakie jest to wsparcie, nigdy 
nie sprawdziłem, zobacz sam.

Pozdrawiam

Użytkownik "Kviat" <kviat@NIE_DLA_SPAMUneostrada.pl> napisał w wiadomości 
news:5491cf23$0$2645$65785112@news.neostrada.pl...
>W dniu 2014-12-17 o 18:39, M.M. pisze:
>
>>> Już ci tłumaczyłem, ale nie przyjmujesz do wiadomości.
>> Nic nie tłumaczyłeś, napisałeś tylko 'nie brnij'.
>>
>>> Bzdura. To właśnie udowadnia, że nie wiesz o czym piszesz. Tam nie ma
>>> żadnego mieszania kodu. W przeglądarce nie ma ani grama kodu w php.
>> To że w przeglądarce nie ma kodu php ma tyle wspólnego z dobrym
>> IDE co dupa z trąbą.
>
> "Przeszukałem stronkę po słowach 'zend' i 'symfony' i nic nie znalazłem.
> Więc działa to na jakimś ichniejszym frameworku - szkoda."
>
> Jeszcze raz: to nie działa na żadnym ichniejszym frameworku. To działa z 
> każdym frameworkiem php i nie php po stronie serwera.


Jak wieloletni użytkownik CodeCharge Studio napiszę, że ma on własny 
powiedzmy fremework.
Może i można by było jeszcze tam wcisnąć 'zend' czy 'symfony' ale po co?

To jest program nastawiony głównie na pisanie aplikacji bazodanowych typu 
ekran z listą/ekran z edycją.
Nastawiony jest na zdarzenia.
Co można to się wyklika a potem jak cos jest potrzebne więcej to trzeba 
wybrać odpowiednie zdarzenie (kod wygeneruje sie automatycznie)
i w środek już można wcisnąć dowolny kod PHP.

W dniu czwartek, 18 grudnia 2014 10:08:05 UTC+1 użytkownik tomek napisał:
> Użytkownik "Kviat" napisał w wiadomości 
> >W dniu 2014-12-17 o 18:39, M.M. pisze:
> >
> >>> Już ci tłumaczyłem, ale nie przyjmujesz do wiadomości.
> >> Nic nie tłumaczyłeś, napisałeś tylko 'nie brnij'.
> >>
> >>> Bzdura. To właśnie udowadnia, że nie wiesz o czym piszesz. Tam nie ma
> >>> żadnego mieszania kodu. W przeglądarce nie ma ani grama kodu w php.
> >> To że w przeglądarce nie ma kodu php ma tyle wspólnego z dobrym
> >> IDE co dupa z trąbą.
> >
> > "Przeszukałem stronkę po słowach 'zend' i 'symfony' i nic nie znalazłem.
> > Więc działa to na jakimś ichniejszym frameworku - szkoda."
> >
> > Jeszcze raz: to nie działa na żadnym ichniejszym frameworku. To działa z 
> > każdym frameworkiem php i nie php po stronie serwera.
> 
> 
> Jak wieloletni użytkownik CodeCharge Studio napiszę, że ma on własny 
> powiedzmy fremework.

Faktycznie, mój błąd. Zagalopowałem się nie obejrzawszy nawet dema.
Właśnie zainstalowałem i oglądam.

> Może i można by było jeszcze tam wcisnąć 'zend' czy 'symfony' ale po co?

Jak znam bardzo dobrze jakiś framework to wolałbym przy nim zostać.

I tu znowu masz rację. Spinanie tego z innym frameworkiem to może być przekombinowanie i strata czasu.
 
> To jest program nastawiony głównie na pisanie aplikacji bazodanowych typu 
> ekran z listą/ekran z edycją.
> Nastawiony jest na zdarzenia.

Czyli coś podobnego jak Delphi4php.
Na pierwszy rzut oka widzę, że to też generuje kupę nadmiarowego kodu, ale z drugiej strony o wiele mniej bałaganu. 
Przynajmniej przy nowo otwartym projekcie.

> Co można to się wyklika a potem jak cos jest potrzebne więcej to trzeba 
> wybrać odpowiednie zdarzenie (kod wygeneruje sie automatycznie)
> i w środek już można wcisnąć dowolny kod PHP.

Robiłeś w tym coś większego?

Pozdrawiam
Piotr 

Użytkownik "Piotr" <kviatkowo@gmail.com> napisał w wiadomości 
news:bd648b06-eabd-4c88-9f98-0f721057b75a@googlegroups.com...
W dniu czwartek, 18 grudnia 2014 10:08:05 UTC+1 użytkownik tomek napisał:
> Użytkownik "Kviat" napisał w wiadomości

>> To jest program nastawiony głównie na pisanie aplikacji bazodanowych typu
>> ekran z listą/ekran z edycją.
>> Nastawiony jest na zdarzenia.

>Czyli coś podobnego jak Delphi4php.
>Na pierwszy rzut oka widzę, że to też generuje kupę nadmiarowego kodu, ale 
>z drugiej strony o wiele mniej bałaganu.
>Przynajmniej przy nowo otwartym projekcie.

>> Co można to się wyklika a potem jak cos jest potrzebne więcej to trzeba
>> wybrać odpowiednie zdarzenie (kod wygeneruje sie automatycznie)
>> i w środek już można wcisnąć dowolny kod PHP.

>Robiłeś w tym coś większego?

Tak.
W ramach pracy zawodowej (w firmie) prawie codziennie od 2008.
Przy czym na wersji 4.
Na wersję 5 nie przechodziliśmy (ale bardziej z powodu licencji itp) 

On Saturday, December 20, 2014 3:21:15 PM UTC+1, Kviat wrote:
> > Mogłoby widoki sqlowe budować, a potem na
> > bazie widoku mogłoby zbudować model. IDE samo mogłoby zaproponować nazwy
> > funkcji/akcji i samo wyniki zapytań wrzucić do jsona. Programista decydowałby, czy
> > PHP osadza w widoku dane, czy PHP tylko odpowiada na AJAXa, a potem JS osadza
> > dane. Poodobnie do delphi.
> 
> Właśnie opisałeś ORM (który mają wszystkie szanujące się frameworki php) 
> i nie obejrzałeś nawet wersji testowej Delphi for php.
> Nie chce mi się odpalać Code Charge Studio, ale założę się, że to ma w 
> standardzie.
> W skrócie - to nie jest nowy pomysł.
Nie przedstawiałem tego ani jako pomysł, ani jako nowy pomysł. Widzę
sprzeczność w tym co piszesz. Jeśli Code Charge nie zna frameworków,
to dlaczego ma jakieś mapery baz danych? Nie kumam.

> Czyli przy każdym odświeżeniu strony proponujesz wysyłać z serwera całą 
> stronę + dane. Czyli przy każdym requeście oprócz wyciągnięcia danych z 
> bazy ciężar budowania widoku przerzucasz również na serwer i z serwera 
> pchasz dane + html + javascript. Za każdym razem.
Jeśli dane są wygenerowane i osadzone po stronie serwera, to jest oszczędność
na kodzie js, bo po co on wtedy? Ale nie o to mi chodziło, to tak na
marginesie.

> Gdzie tu widzisz oszczędność na transferze? Gdzie tu jest oszczędność na 
> odczytach dyskowych?
Nic nie pisałem o oszczędności na transferze, chociaż mała oszczędność
jest. Gdy gzip upakuje wszystko razem, to dane mogą być mniejsze. Do
małych porcyjek danych, nawet gzipa nie opłaca się włączać.


> > Każdy request to pewien narzut. Czasami warto podać dużo danych
> > użytkownikowi w odpowiedzi na jedno zapytanie,
> 
> Co znaczy dużo danych? Dane do wyświetlenia np. w tabeli i tak musisz 
> wysłać. Jak za każdym razem wysyłasz oprócz tych danych jeszcze 
> html+javascript to masz jeszcze więcej danych.
Dużo w jednej odpowiedzi na request, zamiast 10 małych w
10 requestach. Ilość danych jest mniej-więcej taka sama,
za wyjątkiem tego, że:
1) wystarczy mniej js
2) lepiej działa gzip
3) jest mniej nagłówków

> > a pozostałe zapytania obsłużyć całkowicie lokalnie.
> Lokalnie czyli gdzie? Bo chyba tego nie zrozumiałem.
Lokalnie po stronie przeglądarki. Wraz ze stroną
lecą całe dane i potem jak użytkownik pracuje na stronie to
nie ma już zapytań ajaxowych, tylko dane są pobierane 
z lokalnego cache, albo wręcz z jakieś zmiennej js.

Podsumowując, niepokoi mnie duża ilość requestów, a nie
próbuję jakoś zmniejszać ilość transferów czy operacji dyskowych.


> 
> 
> >>> 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ć.
> > Ja od frontendowca dostawałem za każdym razem (po każdej poprawce) goły
> > kod w htmlu i JS. JS odpowiadał za interakcje z użytkownikiem, NIC nie
> > pobierał z serwera żadnym JSONem, ani w w htmlu nie było kodu PHP. Za
> > każdym razem musiałem wstawiać te same wstawki w php czy ajaxie. Po kilku
> > takich poprawkach zrezygnowałem...
> 
> To nie jest argument na to, żeby nie oddzielać widoku od serwera. Wręcz 
> przeciwnie.
> Use Git, CVS Luke...
> Po co sobie tak życie komplikować?
> To co napisałeś tylko potwierdza to co ja napisałem: kwestia organizacji.
No jak to nie jest argument? Przecież to się przekłada na tamte 20*10
poprawek o których pisaliśmy.

> 
> > Nawet nie wiedziałem, że w IDE
> > definiuje się URLe do pobrania danych... Jeśli można zdefiniować, to
> > sprawa wygląda znacznie korzystniej.
> 
> No to dlaczego rozmawiamy o czymś, czego nawet pobieżnie nie obejrzałeś?
Bo miałem pośrednio do czynienia z adobe muse, za pośrednictwem front-endowca. Twoje 
wypowiedzi rozumiem raz tak, raz przeciwnie, chyba faktycznie nie mogę
na nikogo liczyć i będę musiał samemu sprawdzić kilka IDE. Szkoda, bo 
to krecia robota i lepiej zapytać kogoś, kto już odsiał to co badziewne.


> >> 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)
> > Ok, dobre IDE umożliwia wstawienie funkcji które pobierają dane, obojętnie
> > czy te funkcje są funkcjami PHP, czy AJAXowymi po stronie przeglądarki.
> > W przypadku takiego IDE faktycznie jest mniej pracy po każdej poprawce.
> > Niemniej jednak gdy IDE nie potrafi czegoś zrobić i zmodyfikujemy kod
> > ręcznie, to po ponownej edycji w IDE, tracimy nasze ręczne modyfikacje.
> 
> Niby dlaczego tak miałoby być?
Mato boska, dlatego żebyś miał rację :D Jeśli masz rację (z tym że
nie trzeba 20*10 poprawek) i jeśli nie jest tak jak opisałem, to
jak jest? Może jeszcze czegoś nie wiem? Może jest trzecia możliwość?

> No chyba, że znowu piszesz o jakimś 
> hipotetycznym IDE.
Nie, wyobrażam sobie czego o tych IDE nie wiedziałem, że je tak zachwalasz.
Jedyne co mi przyszło do głowy, opisałem powyżej. Ale mówię, może jest
trzecia możliwość, teraz zgłupiałem do reszty, nie wiem o czym rozmawiamy.


> Dlaczego np. Delphi miałoby skasować moje ręczne poprawki w pliku .pas?
Czyli delphi analizuje kod i jak coś dodasz do plików generowanych
przez środowisko, to delphi nie usunie tego? Dawno nie pracowałem w
delphi, może ono istotnie ma takie możliwości. Mnie się analiza kodu
wydaje trudna, na granicy niemożliwej. Zapewniam Cię, że jak zmienisz
pliki *.h *.cpp wygenerowane przez qtcreator,  to Twoje zmiany zginą
bezpowrotnie. Co nie oznacza że qtcreator jest badziewny, po prostu
nigdy nie ma konieczności zmiany tych plików.

> Niby dlaczego jakiekolwiek IDE miałoby samo z siebie coś kasować z 
> plików źródłowych?
> Albo znowu nie zrozumiałem co chciałeś napisać....
Z takimi IDE miałem do czynienia. Dostałem kod html + js. Wstawiłem
do tego kodu np. licznik odwiedzin. Po poprawce znowu dostałem kod
html + js, oczywiście bez tego licznika. Ale pytałeś wyżej, że
dlaczego IDE do widoków ma osadzać kod php albo urle ajaxówe, więc
ja już do końca nie wiem o co chodzi.


> >> Właśnie m.innymi idea takiego IDE mnie nie przekonuje. Jak już bym się
> >> na niego zdecydował, to jestem na niego skazany.
> > Dlatego takie IDE musi być świadome swoich słabości i musi pozwalać
> > na każdym kroku dpisać kod.
> 
> Znowu nie rozumiem. A znasz jakieś IDE, które nie pozwala?
Tak, każde. Sorrki, nie widzę sensu dalszej rozmowy, chyba zakończymy.


> 
> > Wtedy z jednej strony jesteśmy skazani na
> > IDE, ale z drugiej mamy nieograniczoną możliwość parametryzacji.
> 
> Coś mi się widzi, że ty chcesz mieć narzędzie, w którym klikasz przycisk 
> i to narzędzie robi make_portal();
No wiem że tak Ci się widzi, tak samo jak Ci się widzi, że nie odróżniam php 
od html :) Chyba naprawdę nie ma sensu dalej ciągnąć.


> >>> 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.
> > No ale pomimo tego ograniczenia,
> 
> Ależ przecież to nie jest żadne ograniczenie! To cecha aplikacji 
> desktopowych. Taka specyfika. Ani wada, ani zaleta.
Dlatego piszę 'POMIMO'.

> 
> > że jednego bez drugiego nie uruchomisz, w
> > delphi pracuje się świetnie, a w qtcreator jeszcze lepiej.
> 
> >
> >> Aplikację webowej potraktuj jakbyś miał dwie aplikacje, a życie stanie
> >> się prostsze :)
> > Ale by mogło być jeszcze prostsze.
> 
> make_portal(); :):)
Nie widzę szans na dogadanie się.


> 
> >> 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.
> > Często wystarcza statyczny, wyklikany interfejs. Jeśli kontrolek jest dużo,
> > to łatwiej zbudować je w pętelce. Jeśli na początku tworzenia projektu
> > nie było wiadomo że będzie dużo i wyklikali statyczny, a potem trzeba
> > przejść na dynamiczny, to nie jest żadnym problemem. Kod obliczeniowy
> > się przenosi, starą warstwę wizualną się wywala i wkłada nową. Tak powinno
> > być w dobrym IDE do PHP. Jak IDE nie daje rady, to ja robię pętelkę i
> > generuję jakąś trudną, wielokrotnie powtarzającą się kontrolkę wizualną.
> 
> Nie widzę problemu.
> Tylko cały czas, mam takie wrażenie, chcesz takiej sytuacji, w której 
> aplikacja webowa była tak zrobiona jak desktopowa.
Nie. Chcę żeby proces tworzenia aplikacji webowych był podobny jak
desktopowych.


> > Jeśli IDE generuje takie menu, że ajaxem
> > sobie dobiera strukturę, to faktycznie można zrobić tylko tę jedną poprawkę.
> >
> 
> Proszę:
> http://docs.dhtmlx.com/menu__xml_file.html
No mówię, musi tak robić, bo trzeciej możliwości nie ma.

> To nie jest problem. Jeżeli jest potrzebna duża ilość requestów, to ajax 
> pozwala na _zmniejszenie_ ilości przesyłanych danych z serwera do 
> przeglądarki. To Zaleta, a nie wada.
Bo piszesz ogolnie a nie w kontekscie naszej rozmowy. Ogóle to pewnie
że ajax zmniejsza ilość danych, bo dane są doładowywane tylko gdy
user chce. Ale menu czy licznik odwiedzin czy formularz logowania
każdy user chce... rozbijanie tego na 3 zapytania ajaxowe minimalnie
zwiększa ilość danych - ale to też nie ważne. Pisałem o czym innym.
O narzucie przetwarzania dużej ilości requestów.


> Żeby wysłać do przeglądarki dane do tabeli musisz wykonać tyle samo 
> requestów. Z ajaxem czy bez ajaxa.
Przeiceż każde zapytanie ajax to request. Jak może być tyle samo?

> Bez ajaxa masz dodatkowy narzut - obok danych dodatkowe śmieci html - w 
> skrajnych przypadkach za każdym razem pchasz cały widok. Zresztą 
> powtarzam się. Pisałem już o tym wyżej.
Udowodnię Ci że się mylisz. Wyobraź sobie dane giełdowe. Mamy np.
kursy mierzone co minutę. Użytkownik wchodzi na stronę do analizy
danych z ostatniego miesiąca. Po tym przełącza się na widok
danych godzinowych, piętnastominutowych, 10cio minutowych, i tak
aż do jednominutowych. Gdy podajesz ajaxem, masz WIELE zapytań.
Gdy podasz raz 1minutowe, to potem lokalnie, bez żadnego
zapytania, użytkownik może pracować i godzinę na takich danych BEZ
ANI JEDNEGO ZAPYTANIA. Może je filtrować, dobierać wskaźniki, a
serwer nawet nie wie co użytkownik robi. Oczywiście pierwsza
odpowiedź na zapytanie jest cięższa, trzeba przeslać komplet
danych. Ale jeśli użytkownik zrobi więcej niż jedna operacje
na danych, to już się zyskuje.


> > 2) utrata zmian wprowadzonych ręcznie (bez pośrednictwa ide)
> Nieprawda.
To jak to jest rozwiązane w IDE, jeśli to nie jest prawda.

> > 3) gdy ide nie ma danych możliwości, to musimy edytować trudny kod
> >     wygenerowany przez automat
> 
> No ale przecież tak jest w każdym IDE. Delphi, VisualStudio...
> Przed chwilą pisałeś, że w Delphi pracuje się świetnie...
> Ja nie znam IDE, w którym nie trzeba było czegoś edytować.
Chodzi o kod wygenerowany przez IDE. W QTCreator jeszcze
nigdy nie edytowałem kodu generowanego przez automat.


> make_portal(); nie istnieje.


> 
> > 4) w przypadku gdy ide jest niestabilne,
> 
> to się go wyrzuca do kosza i o nim zapomina.
> 
> > to i tak i tak musimy robić
> >     ręcznie, nawet to co ide potencjalnie może zrobić za nas. poprawka
> >     ręczna może też być po każdej edycji w niestabilnym IDE.
> 
> Nie robi się poprawek ręcznych po IDE. Takiego IDE się nie używa/nie 
> kupuje. Chciałeś sobie życie ułatwić, a nie utrudnić.
> Tak więc ten problem z definicji nie istnieje.
> 
> 
> >> 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ć? ;)
> > Pisałem wyżej, ale jeszcze dodam. Generalnie chodzi o stan aplikacji,
> > od odczytania którego IDE mogloby wygenerować kod zależny od konkretnego
> > frameworka i automatyucznie uzależnić wygląd/zachowanie kontrolek.
> > Dla przykładu, wyobrażam sobie taką kontrokę, która prosi usera o
> > zalogowanie, a jak się zaloguje, to wyswielta link do preferencji
> > osobistych i wylogowania. Nie trzeba takiej kontrolce podpinać requestów
> > ajaxowych, ani kodu php, ponieważ IDE zna frameworka i samo wygeneruje
> > kod który sprawdzi.
> 
> No tak... czyli jednak make_portal();
> 
> Od której wersji Delphi taka kontrolka jest dostępna? A może znajdę taką 
> w VisualStudio?
Jeśli ma/by miało delphi standardowe logowanie do aplikacji, to w czym
widzisz problem? Frameworki mają taki standard, więc kontrolka taka
mogłaby istnieć.



> 
> 
> 
> >>>> 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 :)
> > Między innymi błąd tych środowisk polega na tym, że próbują parsować kod i potem z tego
> > kodu robią sieczkę. Parsowanie kodu, to strasznie trudne podejście. QTCreator
> > trzyma informacje o formatkach, zdarzeniach, zasobach, itd w swoim
> > formacie. Format ten jest prosty do analizy dla automatu. Potem jest specjalny
> > program, który z formatek generuje kod C++. Co ciekawe, nigdy nie ma konieczności
> > ingenrencji w wygenerowany kod, a więc nigdy po wygenerowaniu nie tracimy
> > wprowadzonych zmian.
> 
> To ma być prostsze? Lepsze? Od czego?
> Chyba znowu nie zrozumiałem co chciałeś przekazać.
Nie ma sensu, nie chce mi się, nic nie mam z ciągnięcia tej rozmowy...
Kręcimy się tylko w kółko. 

> 
> >
> >>>> 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".
> > Na pewno inaczej skraca się czas w zespole, inaczej pracując samemu.
> 
> 
> Czy pracujesz sam, czy w zespole, to jak potrzebujesz jakąś 
> _niestandardową_ kontrolkę, którą potem chcesz wykorzystać wielokrotnie, 
> np " kontrokę, która prosi usera o
> zalogowanie, a jak się zaloguje, to wyswielta link do preferencji
> osobistych i wylogowania", to sobie ją piszesz raz. A potem używasz.

> A jak ja nie chcę mieć linka do preferencji użytkownika to mam nie 
> kupować takiego IDE? Czy wtedy takie IDE powinno mieć dwie kontrolki? 
> Jedna z linkiem, druga bez linka? A może trzy? Trzecia wyświetlałaby 
> link kursywą i obok gifa z gwiazdką...
A słyszałeś o tym, że kontrolki to co innego niż IDE? Framework ma
tylko zapewniść standardowe działanie/używanie kontrolek. Dlatego
dobre IDE powinno znać frameworka. Potem możesz sobie kupić IDE 
w ogóle bez kontrolek, bo je dokupisz gdzie indziej.

Pozdrawiam

W dniu 2014-12-20 o 11:35, M.M. pisze:
> On Thursday, December 18, 2014 7:54:59 PM 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".
> IDE, jakby znało framework, to mogłoby też wizualnie zbudowć zapytanie do
> bazy za pośrednictwem jakiegoś mapera tabel i te dane wyświetlić przy pomocy
> echa w tabelce - bez ajaxa. Mogłoby widoki sqlowe budować, a potem na
> bazie widoku mogłoby zbudować model. IDE samo mogłoby zaproponować nazwy
> funkcji/akcji i samo wyniki zapytań wrzucić do jsona. Programista decydowałby, czy
> PHP osadza w widoku dane, czy PHP tylko odpowiada na AJAXa, a potem JS osadza
> dane. Poodobnie do delphi.
>
>
>> 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.
> Z tym się generalnie zgadzam. Przykład, domyślam się, podałeś typowo ajaxowy. PHP
> nie osadza danych, tylko JS. AJAX nie jest złym rozwiązaniem, bałbym się tylko, że
> wąskie gardlo aplikacji, z odczytów dyskowych albo z transferu, przemieści się na
> dużą ilość requestów. Każdy request to pewien narzut. Czasami warto podać dużo danych
> użytkownikowi w odpowiedzi na jedno zapytanie, a pozostałe zapytania obsłużyć całkowicie lokalnie.
>
>
>>> 2) generuje tylko to, co potrafi obsłużyć każdy framework, np. tylko htmla
>>
>> I dla mnie to jest właśnie zaleta.
> Jeśli dlatego, że można rozłożyć pracę na dwie osoby, to się zgadzam. Jeśli
> dlatego, że można na inne oprogramowanie po stronie serwera przejść bez
> ingerencji w widoki, to też zaleta. Co do tego nie miałem nigdy zastrzeżeń.
>
>
>>> 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.
> Moje obawy są inne. Myslę że jeśli aplikację da się prawie w całości
> zrobić w CodeCharge czy innym IDE, to należy jej użyć. W momencie gdy
> trzeba coś wielokrotnie poprawiać, albo dorabiać ręcznie, to przestaje
> się opłacać.
>
>
>>> 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ć.
> Ja od frontendowca dostawałem za każdym razem (po każdej poprawce) goły
> kod w htmlu i JS. JS odpowiadał za interakcje z użytkownikiem, NIC nie
> pobierał z serwera żadnym JSONem, ani w w htmlu nie było kodu PHP. Za
> każdym razem musiałem wstawiać te same wstawki w php czy ajaxie. Po kilku
> takich poprawkach zrezygnowałem... Nawet nie wiedziałem, że w IDE
> definiuje się URLe do pobrania danych... Jeśli można zdefiniować, to
> sprawa wygląda znacznie korzystniej.
>
>
>> 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)
> Ok, dobre IDE umożliwia wstawienie funkcji które pobierają dane, obojętnie
> czy te funkcje są funkcjami PHP, czy AJAXowymi po stronie przeglądarki.
> W przypadku takiego IDE faktycznie jest mniej pracy po każdej poprawce.
> Niemniej jednak gdy IDE nie potrafi czegoś zrobić i zmodyfikujemy kod
> ręcznie, to po ponownej edycji w IDE, tracimy nasze ręczne modyfikacje.
>
>
>>> 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.
> Dlatego takie IDE musi być świadome swoich słabości i musi pozwalać
> na każdym kroku dpisać kod. Wtedy z jednej strony jesteśmy skazani na
> IDE, ale z drugiej mamy nieograniczoną możliwość parametryzacji.
>
>
>
>>> 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/
> Fajne, jeśli jest stabilne, to może warto.
>
>
>>> 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.
> No ale pomimo tego ograniczenia, że jednego bez drugiego nie uruchomisz, w
> delphi pracuje się świetnie, a w qtcreator jeszcze lepiej.
>
>
>> Aplikację webowej potraktuj jakbyś miał dwie aplikacje, a życie stanie
>> się prostsze :)
> Ale by mogło być jeszcze prostsze.
>
>> 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.
> Często wystarcza statyczny, wyklikany interfejs. Jeśli kontrolek jest dużo,
> to łatwiej zbudować je w pętelce. Jeśli na początku tworzenia projektu
> nie było wiadomo że będzie dużo i wyklikali statyczny, a potem trzeba
> przejść na dynamiczny, to nie jest żadnym problemem. Kod obliczeniowy
> się przenosi, starą warstwę wizualną się wywala i wkłada nową.. Tak powinno
> być w dobrym IDE do PHP. Jak IDE nie daje rady, to ja robię pętelkę i
> generuję jakąś trudną, wielokrotnie powtarzającą się kontrolkę 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/
> Mi tak właśnie dawał frontendowiec. Za każdym razem goły HTML I JS. A
> gdy ilość pozycji w menu zależała od tego kto się zalogowal, to najchętniej
> by mi dał dwa osobne projekty... Jeśli IDE generuje takie menu, że ajaxem
> sobie dobiera strukturę, to faktycznie można zrobić tylko tę jedną poprawkę.
>
>
>
>> Nie :) 10 poprawek to dziesięć poprawek, a nie 10 razy od nowa :)
> Ok, nie wiedzialem że IDE mają takie możliwości. Niemniej trzy/cztery
> problemy pozostają nadal otwarte:
> 1) duża ilość requestów w przypadku ajax
> 2) utrata zmian wprowadzonych ręcznie (bez pośrednictwa ide)
> 3) gdy ide nie ma danych możliwości, to musimy edytować trudny kod
>     wygenerowany przez automat
> 4) w przypadku gdy ide jest niestabilne, to i tak i tak musimy robić
>     ręcznie, nawet to co ide potencjalnie może zrobić za nas. poprawka
>     ręczna może też być po każdej edycji w niestabilnym IDE.
>
>
>>>>>> 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ć? ;)
> Pisałem wyżej, ale jeszcze dodam. Generalnie chodzi o stan aplikacji,
> od odczytania którego IDE mogloby wygenerować kod zależny od konkretnego
> frameworka i automatyucznie uzależnić wygląd/zachowanie kontrolek.
> Dla przykładu, wyobrażam sobie taką kontrokę, która prosi usera o
> zalogowanie, a jak się zaloguje, to wyswielta link do preferencji
> osobistych i wylogowania. Nie trzeba takiej kontrolce podpinać requestów
> ajaxowych, ani kodu php, ponieważ IDE zna frameworka i samo wygeneruje
> kod który sprawdzi.
>
>
>>>> 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/ ;)
> Coś się nie mogę tych zer doliczyć :)
>
>
>>>> 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 :)
> Między innymi błąd tych środowisk polega na tym, że próbują parsować kod i potem z tego
> kodu robią sieczkę. Parsowanie kodu, to strasznie trudne podejście. QTCreator
> trzyma informacje o formatkach, zdarzeniach, zasobach, itd w swoim
> formacie. Format ten jest prosty do analizy dla automatu. Potem jest specjalny
> program, który z formatek generuje kod C++. Co ciekawe, nigdy nie ma konieczności
> ingenrencji w wygenerowany kod, a więc nigdy po wygenerowaniu nie tracimy
> wprowadzonych zmian.
>
>
>>>> 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ę.
> Będę musiał się zainteresować.
>
>
>>>> 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".
> Na pewno inaczej skraca się czas w zespole, inaczej pracując samemu.
>
>
śmiech, ile danych, jakie podsumy.. chcecie to wysłać np. do Excela?  To 
grauluję - tu śmiechu już nie ma. Masz to obrobić. Wypowiadają się sami 
ideolodzy, studenci?
Dostajesz zadanie - przygotować raport (Na papierze nigdy nie robiłem), masz 
analityku drukuj sobie. ON analizuje i co z 6 szron niczego nie łapie :)
Wolę małego mojego kotka, łapiącego mnie za palce (pisząc to), niż bawić się 
w coś co sensu nie ma.

Pracowałem w wielu firmach, znam sposoby by udupić analityka, chyba to nie 
Twój cel.

-- 
Artur
0 weeks 2 days 10 hours 20 minutes 36 seconds and 625 milliseconds.
"pl.comp.lang.php"

On Saturday, December 20, 2014 8:58:42 PM UTC+1, artiun wrote:
> W dniu 2014-12-20 o 11:35, M.M. pisze:
> > On Thursday, December 18, 2014 7:54:59 PM 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".
> > IDE, jakby znało framework, to mogłoby też wizualnie zbudowć zapytanie do
> > bazy za pośrednictwem jakiegoś mapera tabel i te dane wyświetlić przy pomocy
> > echa w tabelce - bez ajaxa. Mogłoby widoki sqlowe budować, a potem na
> > bazie widoku mogłoby zbudować model. IDE samo mogłoby zaproponować nazwy
> > funkcji/akcji i samo wyniki zapytań wrzucić do jsona. Programista decydowałby, czy
> > PHP osadza w widoku dane, czy PHP tylko odpowiada na AJAXa, a potem JS osadza
> > dane. Poodobnie do delphi.
> >
> >
> >> 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.
> > Z tym się generalnie zgadzam. Przykład, domyślam się, podałeś typowo ajaxowy. PHP
> > nie osadza danych, tylko JS. AJAX nie jest złym rozwiązaniem, bałbym się tylko, że
> > wąskie gardlo aplikacji, z odczytów dyskowych albo z transferu, przemieści się na
> > dużą ilość requestów. Każdy request to pewien narzut. Czasami warto podać dużo danych
> > użytkownikowi w odpowiedzi na jedno zapytanie, a pozostałe zapytania obsłużyć całkowicie lokalnie.
> >
> >
> >>> 2) generuje tylko to, co potrafi obsłużyć każdy framework, np. tylko htmla
> >>
> >> I dla mnie to jest właśnie zaleta.
> > Jeśli dlatego, że można rozłożyć pracę na dwie osoby, to się zgadzam. Jeśli
> > dlatego, że można na inne oprogramowanie po stronie serwera przejść bez
> > ingerencji w widoki, to też zaleta. Co do tego nie miałem nigdy zastrzeżeń.
> >
> >
> >>> 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.
> > Moje obawy są inne. Myslę że jeśli aplikację da się prawie w całości
> > zrobić w CodeCharge czy innym IDE, to należy jej użyć. W momencie gdy
> > trzeba coś wielokrotnie poprawiać, albo dorabiać ręcznie, to przestaje
> > się opłacać.
> >
> >
> >>> 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ć.
> > Ja od frontendowca dostawałem za każdym razem (po każdej poprawce) goły
> > kod w htmlu i JS. JS odpowiadał za interakcje z użytkownikiem, NIC nie
> > pobierał z serwera żadnym JSONem, ani w w htmlu nie było kodu PHP. Za
> > każdym razem musiałem wstawiać te same wstawki w php czy ajaxie. Po kilku
> > takich poprawkach zrezygnowałem... Nawet nie wiedziałem, że w IDE
> > definiuje się URLe do pobrania danych... Jeśli można zdefiniować, to
> > sprawa wygląda znacznie korzystniej.
> >
> >
> >> 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)
> > Ok, dobre IDE umożliwia wstawienie funkcji które pobierają dane, obojętnie
> > czy te funkcje są funkcjami PHP, czy AJAXowymi po stronie przeglądarki.
> > W przypadku takiego IDE faktycznie jest mniej pracy po każdej poprawce.
> > Niemniej jednak gdy IDE nie potrafi czegoś zrobić i zmodyfikujemy kod
> > ręcznie, to po ponownej edycji w IDE, tracimy nasze ręczne modyfikacje.
> >
> >
> >>> 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.
> > Dlatego takie IDE musi być świadome swoich słabości i musi pozwalać
> > na każdym kroku dpisać kod. Wtedy z jednej strony jesteśmy skazani na
> > IDE, ale z drugiej mamy nieograniczoną możliwość parametryzacji.
> >
> >
> >
> >>> 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/
> > Fajne, jeśli jest stabilne, to może warto.
> >
> >
> >>> 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.
> > No ale pomimo tego ograniczenia, że jednego bez drugiego nie uruchomisz, w
> > delphi pracuje się świetnie, a w qtcreator jeszcze lepiej.
> >
> >
> >> Aplikację webowej potraktuj jakbyś miał dwie aplikacje, a życie stanie
> >> się prostsze :)
> > Ale by mogło być jeszcze prostsze.
> >
> >> 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.
> > Często wystarcza statyczny, wyklikany interfejs. Jeśli kontrolek jest dużo,
> > to łatwiej zbudować je w pętelce. Jeśli na początku tworzenia projektu
> > nie było wiadomo że będzie dużo i wyklikali statyczny, a potem trzeba
> > przejść na dynamiczny, to nie jest żadnym problemem. Kod obliczeniowy
> > się przenosi, starą warstwę wizualną się wywala i wkłada nową.. Tak powinno
> > być w dobrym IDE do PHP. Jak IDE nie daje rady, to ja robię pętelkę i
> > generuję jakąś trudną, wielokrotnie powtarzającą się kontrolkę 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/
> > Mi tak właśnie dawał frontendowiec. Za każdym razem goły HTML I JS. A
> > gdy ilość pozycji w menu zależała od tego kto się zalogowal, to najchętniej
> > by mi dał dwa osobne projekty... Jeśli IDE generuje takie menu, że ajaxem
> > sobie dobiera strukturę, to faktycznie można zrobić tylko tę jedną poprawkę.
> >
> >
> >
> >> Nie :) 10 poprawek to dziesięć poprawek, a nie 10 razy od nowa :)
> > Ok, nie wiedzialem że IDE mają takie możliwości. Niemniej trzy/cztery
> > problemy pozostają nadal otwarte:
> > 1) duża ilość requestów w przypadku ajax
> > 2) utrata zmian wprowadzonych ręcznie (bez pośrednictwa ide)
> > 3) gdy ide nie ma danych możliwości, to musimy edytować trudny kod
> >     wygenerowany przez automat
> > 4) w przypadku gdy ide jest niestabilne, to i tak i tak musimy robić
> >     ręcznie, nawet to co ide potencjalnie może zrobić za nas. poprawka
> >     ręczna może też być po każdej edycji w niestabilnym IDE.
> >
> >
> >>>>>> 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ć? ;)
> > Pisałem wyżej, ale jeszcze dodam. Generalnie chodzi o stan aplikacji,
> > od odczytania którego IDE mogloby wygenerować kod zależny od konkretnego
> > frameworka i automatyucznie uzależnić wygląd/zachowanie kontrolek.
> > Dla przykładu, wyobrażam sobie taką kontrokę, która prosi usera o
> > zalogowanie, a jak się zaloguje, to wyswielta link do preferencji
> > osobistych i wylogowania. Nie trzeba takiej kontrolce podpinać requestów
> > ajaxowych, ani kodu php, ponieważ IDE zna frameworka i samo wygeneruje
> > kod który sprawdzi.
> >
> >
> >>>> 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/ ;)
> > Coś się nie mogę tych zer doliczyć :)
> >
> >
> >>>> 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 :)
> > Między innymi błąd tych środowisk polega na tym, że próbują parsować kod i potem z tego
> > kodu robią sieczkę. Parsowanie kodu, to strasznie trudne podejście. QTCreator
> > trzyma informacje o formatkach, zdarzeniach, zasobach, itd w swoim
> > formacie. Format ten jest prosty do analizy dla automatu. Potem jest specjalny
> > program, który z formatek generuje kod C++. Co ciekawe, nigdy nie ma konieczności
> > ingenrencji w wygenerowany kod, a więc nigdy po wygenerowaniu nie tracimy
> > wprowadzonych zmian.
> >
> >
> >>>> 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ę.
> > Będę musiał się zainteresować.
> >
> >
> >>>> 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".
> > Na pewno inaczej skraca się czas w zespole, inaczej pracując samemu.
> >
> >
> śmiech, ile danych, jakie podsumy.. chcecie to wysłać np. do Excela?  To 
> grauluję - tu śmiechu już nie ma. Masz to obrobić. Wypowiadają się sami 
> ideolodzy, studenci?
> Dostajesz zadanie - przygotować raport (Na papierze nigdy nie robiłem), masz 
> analityku drukuj sobie. ON analizuje i co z 6 szron niczego nie łapie :)
> Wolę małego mojego kotka, łapiącego mnie za palce (pisząc to), niż bawić się 
> w coś co sensu nie ma.
> 
> Pracowałem w wielu firmach, znam sposoby by udupić analityka, chyba to nie 
> Twój cel.
Twoja wypowiedź nie ma sensu, najmniejszego. W ogóle cała ta rozmowa nie
miała sensu. Słusznie zrezygnowałem z dyskusji za pierwszym razem, 
wiedziałem że tak się skończy. Co mi odbiło żeby jednak spróbować, to nie
wiem.

W dniu 2014-12-20 o 17:07, M.M. pisze:

>> Chyba znowu nie zrozumiałem co chciałeś przekazać.
> Nie ma sensu, nie chce mi się, nic nie mam z ciągnięcia tej rozmowy...
> Kręcimy się tylko w kółko.

Masz rację.
Już mi się znudziło tłumaczenie podstaw.

EOT

Pozdrawiam
Piotr

Ale to jeszcze skomentuję, bo ktoś przeczyta i pomyśli, że faktycznie 
tak się robi.

W dniu 2014-12-20 o 17:07, M.M. pisze:
>>> a pozostałe zapytania obsłużyć całkowicie lokalnie.
>> Lokalnie czyli gdzie? Bo chyba tego nie zrozumiałem.
> Lokalnie po stronie przeglądarki. Wraz ze stroną
> lecą całe dane i potem jak użytkownik pracuje na stronie to
> nie ma już zapytań ajaxowych, tylko dane są pobierane
> z lokalnego cache, albo wręcz z jakieś zmiennej js.
>

Jak masz 30 wierszy do wyświetlenia, to do przeglądarki wysyłasz 
wszystkie 500 tys. z bazy danych... i tak 20 razy, bo 20 pracowników 
akurat siadło do kompa.

Brawo.

Pozdrawiam
Piotr

On Sunday, December 21, 2014 1:09:09 AM UTC+1, Kviat wrote:
> Ale to jeszcze skomentuję, bo ktoś przeczyta i pomyśli, że faktycznie 
> tak się robi.
> 
> W dniu 2014-12-20 o 17:07, M.M. pisze:
> >>> a pozostałe zapytania obsłużyć całkowicie lokalnie.
> >> Lokalnie czyli gdzie? Bo chyba tego nie zrozumiałem.
> > Lokalnie po stronie przeglądarki. Wraz ze stroną
> > lecą całe dane i potem jak użytkownik pracuje na stronie to
> > nie ma już zapytań ajaxowych, tylko dane są pobierane
> > z lokalnego cache, albo wręcz z jakieś zmiennej js.
> >
> 
> Jak masz 30 wierszy do wyświetlenia, to do przeglądarki wysyłasz 
> wszystkie 500 tys. z bazy danych... i tak 20 razy, bo 20 pracowników 
> akurat siadło do kompa.
> 
> Brawo.
Kumaci wyginęli, dobrze że skomentowałeś.

On Sunday, December 21, 2014 1:09:09 AM UTC+1, Kviat wrote:
> Ale to jeszcze skomentuję, bo ktoś przeczyta i pomyśli, że faktycznie 
> tak się robi.
> 
> W dniu 2014-12-20 o 17:07, M.M. pisze:
> >>> a pozostałe zapytania obsłużyć całkowicie lokalnie.
> >> Lokalnie czyli gdzie? Bo chyba tego nie zrozumiałem.
> > Lokalnie po stronie przeglądarki. Wraz ze stroną
> > lecą całe dane i potem jak użytkownik pracuje na stronie to
> > nie ma już zapytań ajaxowych, tylko dane są pobierane
> > z lokalnego cache, albo wręcz z jakieś zmiennej js.
> >
> 
> Jak masz 30 wierszy do wyświetlenia, to do przeglądarki wysyłasz 
> wszystkie 500 tys. z bazy danych... i tak 20 razy, bo 20 pracowników 
> akurat siadło do kompa.
> 
> Brawo.

Apropo 500tys danych. Widziałeś kiedyś nowy aparat fotograficzny?
Robiłeś nim chociaż raz w życiu zdjęcie, a może zgrywałeś to 
zdjęcie na komputer? Sprawdziłeś jaki ma rozmiar dzisiejszy
przeciętny obrazek w formacie jpg? A może widzialeś kiedyś
jakiś portal ze zdjęciami który jakoś funkcjonuje pomimo dużego
rozmiaru zdjęć? Widziałeś czy nie? 

A może widziałeś kiedyś dane giełdowe, do których to defacto 
odwoływałem się w swoim przykładzie? Zwróciłeś uwagę, że dane 
giełdowe nie wahają się od plus inf do minus inf, tylko skaczą w 
niewielkim przedziale? A może jesteś świadomy
typu float, który zajmuje tylko 4 bajty pamięci? A może znasz
podstawy matematyki i wiesz że 500tys * 4 to raptem 2MB danych?
A może wiesz, że odpowiedzi serwera często się kompresuje gzipem?
A może też jesteś świadomy, że dane powtarzające sie gzip potrafi
skompresować 5-20 razy? A może wiesz, że 2MB po kompresji to może
być tylko 200KB danych, co stanowi pryszcz dla dzisiejszych dysków,
łącz internetowych i przeglądarek. A może jesteś świadomy, że
wysyłając te gołe dane do przeglądarek, skutecznie odciążasz serwery
od obliczeń, co nie tylko zmniejszy ilosć requestów, ale jeszcze 
ilość obliczeń po stronie serwera. A może wiesz, że ilość klientów
jest zwykle większa niż ilosć serwerów i opłaca się przerzucać
obliczenia na aplikacje klienckie? Co? Widzisz światełko w tunelu,
czy nadal kompletna ciemność i nadal Twoja broń ogranicza się
do wmawiania innym, że nie odróżniają PHP od HTMLA?

On Sunday, December 21, 2014 1:04:05 AM UTC+1, Kviat wrote:
> W dniu 2014-12-20 o 17:07, M.M. pisze:
> 
> >> Chyba znowu nie zrozumiałem co chciałeś przekazać.
> > Nie ma sensu, nie chce mi się, nic nie mam z ciągnięcia tej rozmowy...
> > Kręcimy się tylko w kółko.
> 
> Masz rację.
> Już mi się znudziło tłumaczenie podstaw.
Z 20 razy pisałem, że odróżniam php od htmla, nie wiem po
co w kółko tłumaczyłeś to samo. Sam chciałeś.

W dniu 2014-12-21 o 13:19, M.M. pisze:
>

> A może jesteś świadomy
> typu float, który zajmuje tylko 4 bajty pamięci? A może znasz
> podstawy matematyki i wiesz że 500tys * 4 to raptem 2MB danych?

I taka jest z tobą rozmowa. Mowa jest o 500 tys. _wierszach_ z bazy 
danych, a ty mi tutaj z 4 bajtami wyjeżdżasz.

Reszta twoich "argumentów" jest na podobnym poziomie. Jakiś przykłady z 
sufitu o galeriach zdjęć, nie masz pojęcia jak te zdjęcia są z serwera 
wysyłane, z php czy bez php (nadal nie odróżniasz php od html), jaka 
stoi za tym infrastruktura... ale w niczym nie przeszkadza ci to podać 
jako "argumentu".

W skrócie: nie masz pojęcia o czym piszesz i nie czytasz na co 
odpowiadasz. Dyskutujesz sam ze sobą.

EOT

Pozdrawiam
Piotr

On Sunday, December 21, 2014 2:04:46 PM UTC+1, Kviat wrote:
> W dniu 2014-12-21 o 13:19, M.M. pisze:
> >
> 
> > A może jesteś świadomy
> > typu float, który zajmuje tylko 4 bajty pamięci? A może znasz
> > podstawy matematyki i wiesz że 500tys * 4 to raptem 2MB danych?
> 
> I taka jest z tobą rozmowa. 
Zszedłem do Twojego poziomu, robię Ci coś w rodzaju lustra, albo
się czegoś nauczysz, albo nie, zobaczymy.

> Mowa jest o 500 tys. _wierszach_ z bazy 
> danych, a ty mi tutaj z 4 bajtami wyjeżdżasz.
No mowię, robię Ci lustro. Ja podałem przykład w którym nic nie
było o wierszach z bazy danych. Ty wyjechałeś z wierszami z 
bazy. Więc ja wyjeżdżam z tym że to da się upakować do 200kb.
I tak będziemy do osranej śmierci argumentować od rzeczy, 
chyba że się czegoś nauczysz.


> Reszta twoich "argumentów" jest na podobnym poziomie. 
No wiem, celowo takie są dla Ciebie. Dostosowałem je do 
argumentu "mylisz php z widokami".

> Jakiś przykłady z 
> sufitu o galeriach zdjęć, nie masz pojęcia jak te zdjęcia są z serwera 
> wysyłane, z php czy bez php (nadal nie odróżniasz php od html), jaka 
> stoi za tym infrastruktura... ale w niczym nie przeszkadza ci to podać 
> jako "argumentu".
Widzisz już sam co napisałeś? Odpowiedz sam, co można na to
odpisać? Mogę tak samo Ciebie potraktować jak ty mnie, np.
w ten sposób: Nie umiesz wysłać 200kb danych gdy się
zaloguje do systemu raptem 20 użytkowników na raz. Widocznie
nigdy nie robiłeś żadnego systemu, bo 20 użytkowników to 
przedszkole.

> W skrócie: nie masz pojęcia o czym piszesz i nie czytasz na co 
> odpowiadasz. Dyskutujesz sam ze sobą.
Bystrzacha. No ale lepiej że zauważyleś to po 10 postach 
niż w ogóle. Ciekawe czy weźmiesz z tego jakąś naukę.

Witam

Spytam sie dodatkowo czy obok http://dhtmlx.com/ biblioteka (framework) jQuery ma wizualny edytor interfejsu czy nalezy jednak recznie tworzyc i osadzac poszczegolne elementy edycyjne interfejsu uzytkownika ?

Pozdrawiam
M.K.

Witam ponownie.

Moze rozwiazanie stanowic bedzie Aptana Studio 3 jako narzedzie do integracji w jednym srodowisku programistycznym PHP i WWW. Pozwala takze na integracje z Eclipse.

M.K.

On Monday, December 22, 2014 8:12:04 AM UTC+1, silos...@gmail.com wrote:
> Witam ponownie.
> 
> Moze rozwiazanie stanowic bedzie Aptana Studio 3 jako narzedzie do integracji w jednym srodowisku programistycznym PHP i WWW. Pozwala takze na integracje z Eclipse.
> 
> M.K.
Nie wiem, ale gdy używałem ostatnio (jakieś 3-4 lata temu) to nawet
jako edytor nie chciało stabilnie działać. Czasami działało dobrze
przez np. miesiąc, potem padało i nie było wiadomo dlaczego. Strasznie
było wrażliwe na wersję javy, wersję systemu, po zmianie parametrów
konfiguracyjnych traciło stabilności, itd

Witam i dziekuje za informacje.

Wlasnie to srodowisko Aptana Studio 3 byloby idealne. Wywodzi sie z Eclipse (moze byc jako plugin). Do idealnosci brakuje wlasnie tego co jest w przypadku Androida i Eclipse. Tam przy torzeniu projektu moge wybrac sobie temat i w ramach niego budowac interfejs. Tutaj w przypadku PHP i Web tworzy sie pusty szablon. Nie ma mozliwosci wybrania np. template o okreslonym wygladzie i wstawiania elementow z powiedzmy biblioteki jQuery.

Dodatkowo dopytam:
Jezeli w przypadku Android korzystalem na starcie z tutoriala:
http://www.androidhive.info/2011/11/android-sqlite-database-tutorial/
gdzie podane bylo jak tworzyc dobie modul dostepu do bazy danych (CRUD), obiekty logiki aplikacji, interfejs wizualizujacy te dane, itp. to czy ktos spotkal sie z czyms takim dla aplikacji Web i PHP ?

Pozdrawiam
M.K.

On Tuesday, December 23, 2014 7:30:28 AM UTC+1, silos...@gmail.com wrote:
> Witam i dziekuje za informacje.
> 
> Wlasnie to srodowisko Aptana Studio 3 byloby idealne. Wywodzi sie z 
> Eclipse (moze byc jako plugin). 
Dlaczego byłoby idealne?

Pozdrawiam

Witam

Tzn. mialoby sie w jednym projekcie warstwe prezentacyjna (kontrolki) i 
od razu ich obsluge laczenie z dostepem do bazy danych bez latania po 
innych narzedziach.
Brak w Aptana Studio 3 predefiniowanych szablonow wygladu aplikacji 
webowej nawet takich topornych, prostych. Przydaloby sie osadzenie w tym 
srodowisku biblioteki/frameworka np. jQuery i jej komponentow wizualnych

M.K.

Witam ponownie

Trafilem na szybko na tutorial ktory wydawal sie ze pozwoli mi opanowac 
tworzenie aplikacji webowych z uzyciem standardowych elementow:
http://css-tricks.com/app-from-scratch-1-design/
Po przeczytaniu ogolnie masakra w tworzeniu nawet prostej, jednoplikowej 
aplikacji webowej. Warstwa PHP jeszcze OK (klasy i obiekty) natomiast 
tworzenie wartwy wizualnej jest straszne. Reczne rzezbienie w CSS, 
JavaScipt, HTML i potem laczenie tego w jedno + grafika.

M.K.

On Wednesday, December 24, 2014 2:54:48 PM UTC+1, MK wrote:
> Trafilem na szybko na tutorial ktory wydawal sie ze pozwoli mi opanowac 
> tworzenie aplikacji webowych z uzyciem standardowych elementow:
> http://css-tricks.com/app-from-scratch-1-design/
> Po przeczytaniu ogolnie masakra w tworzeniu nawet prostej, jednoplikowej 
> aplikacji webowej. Warstwa PHP jeszcze OK (klasy i obiekty) natomiast 
> tworzenie wartwy wizualnej jest straszne. Reczne rzezbienie w CSS, 
> JavaScipt, HTML i potem laczenie tego w jedno + grafika.


Kwestia wprawy. Jeśli ktoś zajmuje się tylko warstwą wizualną, zna 
gotowce, narzędzia, ma dużo swojego kodu który może przekopiować w
przypadku podobnych aplikacji... to żadna masakra. Osobiście też
nie przepadam. Optymalizuję kod w C++, nagle na za godzinę
muszę rzeźbić w JS, HTML i CSS - zawsze siadam do tego jak po 
jakimś praniu mózgu.

Pozdrawiam

Witam i przepraszam ze jeszcze cos dopytam

Jezeli mam vizualny edytor wygladu aplikacji webowej w stylu:
http://dhtmlx.com/docs/products/visualDesigner/
to tworzac interfejs aplikacji webowej dolaczamy biblioteke:
dhtmlx.js.

Moje pytanie dotyczy tego czy spotkaliscie sie z takim visual designerem 
dla najpopularniejszej biblioteki budowania interfejsu aplikacji jQuery ?

Pozdrawiam
M.K.

Dnia Wed, 04 Feb 2015 10:26:24 +0100, MK napisał(a):

> Moje pytanie dotyczy tego czy spotkaliscie sie z takim visual designerem 
> dla najpopularniejszej biblioteki budowania interfejsu aplikacji jQuery ?

jQuery nie służy do budowania interfejsu aplikacji.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Witam

Znalazlem cos takiego:
http://www.codecanvas.org/
korzystajace z jakiegos nieznanego pakietu App.js 
(appjs-0.0.20-win32-ia32.zip).

Ciezkie widze w dzialaniu ale wyglad formatek jest OK.

M.K.

Witam

A co myslicie o wykorzystaniu darmowego narzedzia Maqetta i podlaczenie 
wygenerowanych stron do srodowiska Aptana 3 ?

M.K.