🚀 go-pugleaf

W dniu 2011-10-08 09:27, sw pisze:
> Witam,
> Od nowego tygodnia rozpoczynam nowy projekt. Generalnie niewielka
> aplikacja usprawniajaca procesy biznesowe, dwa ekrany tylko i sporo
> tabelek, moze dwa formularze. Do tej pory pracowałem przy wykorzystaniu
> spring+spring mvc+jsp+displaytag+dwr+jcifs a to wszystko na tomcacie.
> Myśle ze fajnie by było przy okazji przejść na coś nowszego, przy czym
> raczej nie mam ochoty porzucac spring a raczej zmienić np sam widok. Co
> możecie polecić abym za bardzo nie utknął na nowym szkielecie czy widoku
> a jednocześnie skończył aplikacje w podobnym terminie co na obeznanych
> mi rozwiązaniach?

Może Wicket?
No i oczywiście GWT :)

-- 
MB

W dniu 2011-10-08 10:40, Marcin Biegan pisze:
> W dniu 2011-10-08 09:27, sw pisze:
>> Witam,
>> Od nowego tygodnia rozpoczynam nowy projekt. Generalnie niewielka
>> aplikacja usprawniajaca procesy biznesowe, dwa ekrany tylko i sporo
>> tabelek, moze dwa formularze. Do tej pory pracowałem przy wykorzystaniu
>> spring+spring mvc+jsp+displaytag+dwr+jcifs a to wszystko na tomcacie.
>> Myśle ze fajnie by było przy okazji przejść na coś nowszego, przy czym
>> raczej nie mam ochoty porzucac spring a raczej zmienić np sam widok. Co
>> możecie polecić abym za bardzo nie utknął na nowym szkielecie czy widoku
>> a jednocześnie skończył aplikacje w podobnym terminie co na obeznanych
>> mi rozwiązaniach?
> 
> Może Wicket?

popieram :) może nie jest w standardzie jee ale imho wygodniej się w nim
pisze a co dla mnie istotne łatwo pisze się własne komponenty

> No i oczywiście GWT :)

no ale to wymaga przemyślenia czy napewno, gwt tak ogólnie generuje
aplikację działającą w środowisku przeglądarki i jeśli na widok wpływają
elementy dziejące się na serwerze (nie tylko dane w formularzu) to może
nie być najlepszy wybór (to wtedy np wicket :))

W dniu 2011-10-08 12:56, Tomek Łabuz pisze:
> no ale to wymaga przemyślenia czy napewno, gwt tak ogólnie generuje
> aplikację działającą w środowisku przeglądarki i jeśli na widok wpływają
> elementy dziejące się na serwerze (nie tylko dane w formularzu) to może
> nie być najlepszy wybór (to wtedy np wicket :))

Każdy nietrywialny interfejs zależy w dużym stopniu od tego, co dzieje się na 
serwerze. Ja jestem gorącym zwolennikiem GWT:
+ JAVA! nie trzeba pisać kodu w JavaScript z którym zawsze są jakieś problemy, 
jest dużo narzędzi do Javy których można normalnie używać (eclipse!)
+ można debuggować!
+ można używać tych samych obiektów/klas po stronie serwera i klienta
+ skalowalne - całe renderowanie robi przeglądarka.
- kompilacja zajmuje tyle, że można się pochlastać. na szczęście w czasie 
developmentu nie trzeba kompilować bo jest 'dev mode'
- dane z serwera nie są dostępne "od razu", jak to jest w przypadku np. JSP, 
trzeba panować nad tym kiedy się je pobiera, ile się ich pobiera (użytkownicy 
nie lubią czekać długo...). Wymaga to wprowadzenia warstwy DTO, albo 
wykorzystania czegoś gotowego (np. RequestFactory)
- domyślny styl/wygląd interfejsu moim zdaniem nie jest profesjonalny, warto 
doszlifować CSS
- nie ma zbyt wielu bibliotek widgetów

-- 
pozdrawiam
Marcin Biegan

W dniu 2011-10-08 15:48, Marcin Biegan pisze:
> - dane z serwera nie są dostępne "od razu", jak to jest w przypadku np.
> JSP, trzeba panować nad tym kiedy się je pobiera, ile się ich pobiera
> (użytkownicy nie lubią czekać długo...). Wymaga to wprowadzenia warstwy
> DTO, albo wykorzystania czegoś gotowego (np. RequestFactory)

i to jest czasem taki problem, że robi się tydzień coś co np w wicket
można zrobić w dzień, do tego np w wicket można łatwiej zrobić
komponenty, których stan będzie walidowany po stronie serwera i klienta
jednocześnie (np pod kątem zakresu wprowadzanych danych)
nie zmierzam do tego, że gwt jest złe (choć ja po swoich doświadczeniach
z nim mało go lubię :) ) tylko, że należy choć 5 minut poświęcić na
przemyślenia

> - domyślny styl/wygląd interfejsu moim zdaniem nie jest profesjonalny,
> warto doszlifować CSS
jakbyś mógł rozwinąć temat - co to jest profesjonalny wygląd :) ?

On 10/08/2011 03:48 PM, Marcin Biegan wrote:
> Każdy nietrywialny interfejs zależy w dużym stopniu od tego, co dzieje
> się na serwerze. Ja jestem gorącym zwolennikiem GWT:
> + JAVA! nie trzeba pisać kodu w JavaScript z którym zawsze są jakieś
> problemy, jest dużo narzędzi do Javy których można normalnie używać
> (eclipse!)
> + można debuggować!
> + można używać tych samych obiektów/klas po stronie serwera i klienta

GWT to doskonały przykład "przeciekającej abstrakcji"[1]. Niby piszesz w 
Javie – ale tak na prawdę to tylko podzbiór języka, niby jest 
development mode – ale nie zawsze działa tak, jak końcowa aplikacja, 
niby nie musisz znać JavaScript – ale bez tego nie zrozumiesz wielu 
subtelnych bugów, niby możesz korzystać z bibliotek Javy – ale nie 
wszystkie są kompatybilne z GWT, i tak dalej...

[1] http://www.joelonsoftware.com/articles/LeakyAbstractions.html

-- 
Adam Byrtek

W dniu 2011-10-08 16:09, Tomek Łabuz pisze:
> W dniu 2011-10-08 15:48, Marcin Biegan pisze:
>>  - dane z serwera nie są dostępne "od razu", jak to jest w przypadku np.
>>  JSP, trzeba panować nad tym kiedy się je pobiera, ile się ich pobiera
>>  (użytkownicy nie lubią czekać długo...). Wymaga to wprowadzenia warstwy
>>  DTO, albo wykorzystania czegoś gotowego (np. RequestFactory)
>
> i to jest czasem taki problem, że robi się tydzień coś co np w wicket
> można zrobić w dzień, do tego np w wicket można łatwiej zrobić
> komponenty, których stan będzie walidowany po stronie serwera i klienta
> jednocześnie (np pod kątem zakresu wprowadzanych danych)
> nie zmierzam do tego, że gwt jest złe (choć ja po swoich doświadczeniach
> z nim mało go lubię :) ) tylko, że należy choć 5 minut poświęcić na
> przemyślenia
>
>>  - domyślny styl/wygląd interfejsu moim zdaniem nie jest profesjonalny,
>>  warto doszlifować CSS
> jakbyś mógł rozwinąć temat - co to jest profesjonalny wygląd :) ?

brzydki i toporny: http://gwt.google.com/samples/Showcase/Showcase.html

znacznie lepszy: http://demo.vaadin.com/chameleontheme

Po prostu dobór kolorystyki czy ikonek do mnie nie przemawia, np. brzydkie 
żółte tło elementu wybranego klawiaturą na cell liście albo niebieski gradient 
klikniętego. Specjalnie to problem nie jest, bo pewnie każdy zrobi jakiś swój 
'theme', ale przy porównaniu domyślnego wyglądu vaadina i gwt, vaadin jest 
bardziej kuszący :)

-- 
MB

-- 
MB

W dniu 2011-10-08 16:09, Tomek Łabuz pisze:
> W dniu 2011-10-08 15:48, Marcin Biegan pisze:
>
>> - domyślny styl/wygląd interfejsu moim zdaniem nie jest profesjonalny,
>> warto doszlifować CSS
> jakbyś mógł rozwinąć temat - co to jest profesjonalny wygląd :) ?

Jak jako programiści (niektórzy rasowi javowcy, żadne tam kadzenie) 
sobie radzicie z designem graficznym , CSS itp?
Czysty XHTML i CSS jest super, ale najlepiej jak się tam porusza 
inteligentnie i z wiedzą, a nie strzela z armat i koloruje absolutnie 
wszystko.

Dwa lata temu "pokolorowałem" nawigację, rozwijające się strukturalne 
menu bez JS, czysty CSS, a dwoma tomami Erica Meyer'a na blacie. Fajne 
wyniki uzyskane precyzyjnymi środkami.

Teraz chcę zapanować nad dwoma (trzeba przyznać sensownie oznaczonymi) 
<div> które nie pochodzą z mojego kodu (komponenty Wicketa), okazuje się 
nic z tych precyzyjnych metod nie pamiętam.

Czy najprościej znaleźć partnera do oprawy wizualnej? Prawdę mówiąc tego 
typu "precyzyjnych" projektantów nie trafiam, jadą jakimś narzędziem 
zwykle Adobe i tyle.

W dniu 2011-10-09 19:55, Jacek Czerwinski pisze:
> W dniu 2011-10-08 16:09, Tomek Łabuz pisze:
>> W dniu 2011-10-08 15:48, Marcin Biegan pisze:
>>
>>> - domyślny styl/wygląd interfejsu moim zdaniem nie jest profesjonalny,
>>> warto doszlifować CSS
>> jakbyś mógł rozwinąć temat - co to jest profesjonalny wygląd :) ?
> 
> Jak jako programiści (niektórzy rasowi javowcy, żadne tam kadzenie)
> sobie radzicie z designem graficznym , CSS itp?
> Czysty XHTML i CSS jest super, ale najlepiej jak się tam porusza
> inteligentnie i z wiedzą, a nie strzela z armat i koloruje absolutnie
> wszystko.

albo sobie radzimy (znaczy mówię za siebie :) ) średnio albo zlecamy
komuś kto się zna lepiej :)

> 
> Czy najprościej znaleźć partnera do oprawy wizualnej? 

wg mnie tak, teraz tyle technologii, że ja już nie ogarniam :)

W dniu 2011-10-09 19:59, Tomek Łabuz pisze:

>> Jak jako programiści (niektórzy rasowi javowcy, żadne tam kadzenie)
>> sobie radzicie z designem graficznym , CSS itp?
>> Czysty XHTML i CSS jest super, ale najlepiej jak się tam porusza
>> inteligentnie i z wiedzą, a nie strzela z armat i koloruje absolutnie
>> wszystko.
>
> albo sobie radzimy (znaczy mówię za siebie :) ) średnio albo zlecamy
> komuś kto się zna lepiej :)

Pewnie tak, znam kupę ludzi co robi strony, ale żaden nie robi tego w 
tej metodzie o jaką mi chodzi.
Fajnie jest samemu "trochę" rozumieć jak to zależy, ale do pełni wiedzy 
i praktyki, dużo brakuje.

Co do tzw "frajdy", widzę w swoje ścieżce emocjonalne podejście do javy 
dopiero od 1.5 (choć lekko walczyłem wcześniej), a na www dopiero 
filozofia czystego HTML/XHTML i CSS, to jest coś co mnie ujęło (choć 
czasem robiłem 'siłowe strony' wcześniej).

W dniu 2011-10-09 20:19, Jacek Czerwinski pisze:
> W dniu 2011-10-09 19:59, Tomek Łabuz pisze:
> 
>>> Jak jako programiści (niektórzy rasowi javowcy, żadne tam kadzenie)
>>> sobie radzicie z designem graficznym , CSS itp?
>>> Czysty XHTML i CSS jest super, ale najlepiej jak się tam porusza
>>> inteligentnie i z wiedzą, a nie strzela z armat i koloruje absolutnie
>>> wszystko.
>>
>> albo sobie radzimy (znaczy mówię za siebie :) ) średnio albo zlecamy
>> komuś kto się zna lepiej :)
> 
> Pewnie tak, znam kupę ludzi co robi strony, ale żaden nie robi tego w
> tej metodzie o jaką mi chodzi.
matko... albo masz jakieś dziwne wymagania albo żyjesz w jakiejś niszy
gdzie wszyscy robią "po swojemu" :)
ale zawsze możesz poszukać zdalnie, to nawet czasem działa :)

On 2011-10-08 15:48, Marcin Biegan wrote:
> W dniu 2011-10-08 12:56, Tomek Łabuz pisze:
>> no ale to wymaga przemyślenia czy napewno, gwt tak ogólnie generuje
>> aplikację działającą w środowisku przeglądarki i jeśli na widok wpływają
>> elementy dziejące się na serwerze (nie tylko dane w formularzu) to może
>> nie być najlepszy wybór (to wtedy np wicket :))
>
> Każdy nietrywialny interfejs zależy w dużym stopniu od tego, co dzieje
> się na serwerze. Ja jestem gorącym zwolennikiem GWT:
> + JAVA! nie trzeba pisać kodu w JavaScript z którym zawsze są jakieś
> problemy, jest dużo narzędzi do Javy których można normalnie używać
> (eclipse!)
> + można debuggować!
> + można używać tych samych obiektów/klas po stronie serwera i klienta
> + skalowalne - całe renderowanie robi przeglądarka.

Tu bym sie zatrzymal troche:
1) Wcale niekoniecznie skalowalne: duze aplikacje potrafia po prostu 
zarznac przegladarke (szczegolnie starsze jak np. IE6)
2) Sprobuj dobrze obsluzyc historie/bookmarki itd (fakt, ze inne -nawet 
"server side" - "komponentowe" frameworki tez maja z tym problem)
3) Sprobuj zrealizowac wymaganie, ze twoj site/aplikacja da sie dobrze 
pozycjonowac w wyszukiwarkach

-- 
Michal

On 2011-10-08 16:16, Adam Byrtek wrote:
> On 10/08/2011 03:48 PM, Marcin Biegan wrote:
>> Każdy nietrywialny interfejs zależy w dużym stopniu od tego, co dzieje
>> się na serwerze. Ja jestem gorącym zwolennikiem GWT:
>> + JAVA! nie trzeba pisać kodu w JavaScript z którym zawsze są jakieś
>> problemy, jest dużo narzędzi do Javy których można normalnie używać
>> (eclipse!)
>> + można debuggować!
>> + można używać tych samych obiektów/klas po stronie serwera i klienta
>
> GWT to doskonały przykład "przeciekającej abstrakcji"[1]. Niby piszesz w
> Javie – ale tak na prawdę to tylko podzbiór języka, niby jest
> development mode – ale nie zawsze działa tak, jak końcowa aplikacja,
> niby nie musisz znać JavaScript – ale bez tego nie zrozumiesz wielu
> subtelnych bugów, niby możesz korzystać z bibliotek Javy – ale nie
> wszystkie są kompatybilne z GWT, i tak dalej...
>
> [1] http://www.joelonsoftware.com/articles/LeakyAbstractions.html
>

Bo GWT nigdy nie mial za zadanie byc implementacja Javy (tm) - to po 
prostu sposob gugla na zwabienie duzej ilosci programistow do swoich 
narzedzi/platform (podobnie jak Android) poprzez uczynienie ich bardziej 
znajomymi dla programistow Java.

-- 
Michal

Użytkownik "Michal Kleczek"  napisał w wiadomości grup 
dyskusyjnych:j6u67g$v3s$2@news.onet.pl...

>
> GWT to doskonały przykład "przeciekającej abstrakcji"[1]. Niby piszesz w
> Javie – ale tak na prawdę to tylko podzbiór języka, niby jest
> development mode – ale nie zawsze działa tak, jak końcowa aplikacja,

Dokładnie to samo można napisać o Hibernate :) 

On 2011-10-10 11:17, William Bonawentura wrote:
>
>
> Użytkownik "Michal Kleczek" napisał w wiadomości grup
> dyskusyjnych:j6u67g$v3s$2@news.onet.pl...
>
>>
>> GWT to doskonały przykład "przeciekającej abstrakcji"[1]. Niby piszesz w
>> Javie – ale tak na prawdę to tylko podzbiór języka, niby jest
>> development mode – ale nie zawsze działa tak, jak końcowa aplikacja,
>
> Dokładnie to samo można napisać o Hibernate :)

Jakbys byl tak dobry i pilnowal, zeby zgadzaly sie cytaty z autorami. Bo 
wyglada tak jakbys odpowiadal na moj post, a cytowane slowa naleza do 
kogos innego (dokladnie do kogos, komu ja odpowiedzialem).

Jezeli to jest problem oprogramowania, ktorego uzywasz, to po prostu 
zmien to oprogramowanie (to pisze tak na wszelki wypadek - nic tobie 
osobiscie nie imputujac - zeby z gory wykluczyc idiotyczne 
usprawiedliwienia typu "to google groups tak robia").

-- 
Michal

On 10/10/2011 11:17 AM, William Bonawentura wrote:
> Dokładnie to samo można napisać o Hibernate

Oczywiście, jak każdy inny ORM. Po prostu model relacyjny jest na tyle 
odmienny od obiektowego, że nie można go całkowicie zamaskować.

http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

-- 
Adam Byrtek

W dniu 2011-10-10 09:15, Michal Kleczek pisze:
> Tu bym sie zatrzymal troche:
> 1) Wcale niekoniecznie skalowalne: duze aplikacje potrafia po prostu
> zarznac przegladarke (szczegolnie starsze jak np. IE6)
Ciężko mi się tutaj wypowiedzieć, może po prostu nie miałem styczności z 
wystarczająco dużymi aplikacjami. Reguła - przesyłać mało danych, ale często - 
rozwiązuje wiele problemów automatycznie.

Była prelekcja, chyba na Google IO 2009, gdzie ktoś prezentował projekt, 
którego jedną z funkcji było rysowanie jakiegoś diagramu. Przeliczanie layoutu 
tego diagramu zajmowało najwięcej czasu i rozwiązano to tak, że robione to było 
jednocześnie na serwerze i kliencie, a wybierany był ten wynik który otrzymano 
szybciej - można by takie rozwiązanie zastosować też tylko w przypadku 
kiepskich przeglądarek (ie6,7). W GWT take rozwiązanie łatwo zrealizować - 
wystarczy ten sam kod wywołać po drugiej stronie RPC, w innym frameworku trzeba 
by go zduplikować/napisać w JavaScript.

> 2) Sprobuj dobrze obsluzyc historie/bookmarki itd (fakt, ze inne -nawet
> "server side" - "komponentowe" frameworki tez maja z tym problem)
Przy podejściu proponowanym przez team GWT [1] działa to całkiem nieźle.

> 3) Sprobuj zrealizowac wymaganie, ze twoj site/aplikacja da sie dobrze
> pozycjonowac w wyszukiwarkach
Z tym jest problem, ale też się da [2]. Za to problemem który nie wiem jak 
rozwiązać jest używanie adwords
czy umieszczenie innych reklam - skoro strona się nie zmienia, to kiedy 
zmieniać reklamy? O ile w ogóle
usługa na to pozwala.

[1] http://tiny.pl/h1ccn ew. inne podejście: http://code.google.com/p/gwt-platform
[2] np. http://code.google.com/p/gwt-platform/wiki/CrawlerSupport

-- 
pozdrawiam
Marcin Biegan