Czy warto używać Seam do

[Grzesiek]

Witam

Mam do wykonania projekt i zastanawia mnie wasza opinia na temat tego
z jakiego frameworka skorzystać od początku i o co go ewentualnie
wzbogacić.

Jestem ciekaw waszej opinii na zastosowanie Jboss Seam 2 + rich faces
tylko z wyglądem customowym bo frontend robi zupełnie inna firma.
Do tego baza na postgresie.
Co do stosowania Seam 3 mam pewne obawy bo widziałem że jeszcze mało
supportu jest i różne bugi.
Generalnie z tym frameworkiem miałem do czynienia z innymi jest nieco
gorzej. Ale poza tym ostanio nie siedziałem w temacie frameworków
javy. Co byście ewentualnie polecili ?

Projekt ma dotyczyć aplikacji biznesowej do zarządzania standaryzacją
w firmach. Różne workflowy, rodzaje dokumentów, formularzy, dostępów
itp.
Nic gigantycznego bo pewnie dal max 5 tyś firm.

Pozdrawiam
Grzegorz

[Krzysztof Miksa]

Hej

Na Twoim miejscu nie bawił bym się już w Seam 2. Uważam, że miał on
już swoje 5 minut i teraz jest czas na Seam 3 (chociaż jego koniec też
już jest bliski ponieważ nadchodzi DeltaSpike)
Support jest jaki jest, ale to nie znaczy, że dla Seama 2 będzie on lepszy.
Osobiście od roku używam Seama 3 wykonałem dzięki niemu kilka
projektów oraz część wciąż rozwijam. Gdyby było w nim aż tak wiele
błędów to napewno pozostałbym przy 2 ;)

Pozdrawiam
Krzysztof Miksa


W dniu 15 maja 2012 22:04 użytkownik Grzesiek
<grzegor...@gmail.com> napisał:

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Adam Lider]

Nie warto, ani w wersji 2, ani 3, ani zadnej innej opartej na JSF. Wystarczy juz tych JSFowych projektow (jak i GWT).

Bezpieczny i "zgodny z natura" wybor to: Spring MVC + HTML/CSS + JavaScript + (w zaleznosci od tego jak bardzo "rich" ten frontend ma byc) np. jQuery, Backbone.js, ExtJS

Jesli aplikacja ma byc w miare klasyczna, stronicowa ("klikajac link x uzytkownik przechodzi na strone y z lista ...") to spokojnie Javoviec sobie poradzi. Sugeruje podejscie Unobtrusive JS, gdzie zawsze wychodzimy od strony/widoku z czystym HTML/CSSem i dopiero majac funkcjonalnosc zrobiona dodajemy efekty za pomoca jQuery (najlepiej w osobnym pliku bez modifykacji HTMLa). Wcale nie chodzi tutaj o to ze nasza strona bedzie dzialala bez JS wlaczonego w przegladarce u klienta, ale robiac w ten sposob powstania aplikacja dosc czysta i latwa w utrzymaniu. Fajnie tez to podejscie dziala przy wspolpracy z grafikami, ale to troche dluzszy temat.

Jesli natomiast ta aplikacja ma byc w stylu okienkowym ("w okienku x uzytkownik wybiera opcje y i wyswietla sie okienko z") to choc wiele takich frameworkow istnieje (ExtJS) to jednak sugeruje JSowca w teamie.

Adam.

[Jacek Laskowski]

2012/5/16 Krzysztof Miksa <k.m...@blogu.pl>:

> Na Twoim miejscu nie bawił bym się już w Seam 2. Uważam, że miał on
> już swoje 5 minut i teraz jest czas na Seam 3 (chociaż jego koniec też
> już jest bliski ponieważ nadchodzi DeltaSpike)

Zaintrygowała mnie ta odpowiedź. Rozumiem Seam 3 jako uzupełnienie API
w Java EE 6, co wcześniej było właśnie wydawane jako całościowe
rozwiązanie Seam 2 (czasy Java EE 5). Co jest użytecznego w Seam 3,
czego brakuje w Java EE 6?!

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[Jacek Laskowski]

2012/5/16 Adam Lider <adam....@googlemail.com>:

> Nie warto, ani w wersji 2, ani 3, ani zadnej innej opartej na JSF. Wystarczy juz tych JSFowych projektow (jak i GWT).

Jakkolwiek nie byłbym tak stanowczy w forowaniu tej opinii, to coraz
bardziej skłaniałbym się ku niej (wystarczyłoby mnie trochę bardziej
przyprzeć do ściany i trochę poopalać z boczku :)) Za mało mam
praktycznego doświadczenia w stosowaniu tych rozwiązań, ale mam
nieodparte wrażenie, że w korporacjach inne stosy nie mają
zastosowania, bo są za mało...ustandaryzowane. Cóż, taki lajf.

Mógłbym również rozważyć tezę, że JSF2 ma swój potencjał, tylko, że
zwykle chcielibyśmy od tego znacznie więcej, a to więcej, to już
przegięcie i późniejsze problemy w projektach (o ostatnich problemach
z JSF2 słyszałem od Łukasza i spółki z SMT, i od nich oczekiwałbym
największego doświadczenia, aby obalić/utrzymać JSF2 w projekcie).

[Jakub Nabrdalik]

W dniu 16 maja 2012 06:15 użytkownik Adam Lider
<adam....@googlemail.com> napisał:

> Nie warto, ani w wersji 2, ani 3, ani zadnej innej opartej na JSF. Wystarczy juz tych JSFowych projektow (jak i GWT).
>
> Bezpieczny i "zgodny z natura" wybor to: Spring MVC + HTML/CSS + JavaScript + (w zaleznosci od tego jak bardzo "rich" ten frontend ma byc) np. jQuery, Backbone.js, ExtJS

+1

Nie ignoruj technologii najbliższych webowi (html/js/coś prostego w
backendzie), są zwykle dużo łatwiejsze w utrzymaniu niż np. frameworki
komponentowe. Jeśli bardzo nienawidzisz js (tak jak ja), popatrz na
CoffeeScripta.

--
Jakub Nabrdalik
http://blog.solidcraft.eu

[Michal Margiel]

W dniu 16 maja 2012 09:53 użytkownik Jakub Nabrdalik <jak...@gmail.com> napisał:

W dniu 16 maja 2012 06:15 użytkownik Adam Lider
<adam....@googlemail.com> napisał:

> Nie warto, ani w wersji 2, ani 3, ani zadnej innej opartej na JSF. Wystarczy juz tych JSFowych projektow (jak i GWT).
>
> Bezpieczny i "zgodny z natura" wybor to: Spring MVC + HTML/CSS + JavaScript + (w zaleznosci od tego jak bardzo "rich" ten frontend ma byc) np. jQuery, Backbone.js, ExtJS

+1

Nie ignoruj technologii najbliższych webowi (html/js/coś prostego w
backendzie), są zwykle dużo łatwiejsze w utrzymaniu niż np. frameworki
komponentowe. 

 

Serio Wicket ze swoim WicketTesterem jest cieższy w utrzymaniu niż spring mvc/servlety? Nie mówie że jest to idealny/najlepszy framework - ale na pewno nie skazywał bym go od razu na śmierć.

Jak czytam "Tylko Spring MVC - a reszta się do niczego nie nadaje" to przypomina mi się scena z Dnia świra o "najmojszej racji". Myślę że temat nie jest aż tak prosty.

--
Pozdrawiam/Best regards
Michał Margiel

http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu

[Wojciech Erbetowski]

W dniu 16 maja 2012 10:03 użytkownik Michal Margiel <michal....@gmail.com> napisał:

Serio Wicket ze swoim WicketTesterem jest cieższy w utrzymaniu niż spring mvc/servlety? Nie mówie że jest to idealny/najlepszy framework - ale na pewno nie skazywał bym go od razu na śmierć.

Jak czytam "Tylko Spring MVC - a reszta się do niczego nie nadaje" to przypomina mi się scena z Dnia świra o "najmojszej racji". Myślę że temat nie jest aż tak prosty.

To oczywiście zależy od osobistych preferencji, ale jeśli masz do tworzenia portal, z którego korzysta dużo ludzi a klient skupia się na GUIu to Wicket, JSF i GWT sprawią, że będziesz klął.

Generalnie generowanie JS (jak we wszystkich trzech wymienionych) prędzej czy później lubi się jakoś mścić.

Ale jeśli jesteś deweloperem, który ma zakodzić w firmie system do raportowania czasu pracy dla pracowników to to jest rewela, zwłaszcza dla fanów OOP :-)

Tester w Wickecie naprawdę jest godny pozazdroszczenia, ale nie pomoże Ci jeśli się okaże, że musisz wycisnąć 'więcej' z HTTP.

Pozdrawiam,

Wojtek

[Łukasz Lenart]

W dniu 16 maja 2012 09:44 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:
> Mógłbym również rozważyć tezę, że JSF2 ma swój potencjał, tylko, że
> zwykle chcielibyśmy od tego znacznie więcej, a to więcej, to już
> przegięcie i późniejsze problemy w projektach (o ostatnich problemach
> z JSF2 słyszałem od Łukasza i spółki z SMT, i od nich oczekiwałbym
> największego doświadczenia, aby obalić/utrzymać JSF2 w projekcie).

Dość często to nie w tym problem, w większości przypadków okazuje się,
że nawet standardowe rzeczy zrobić jest ciężko, a bo to bug w
implementacji, albo braki dokumentacji.

JSF to jednak standard i znając gdzie są miny można go używać - tylko
wpierw trzeba na te miny wejść ;-)


Pozdrawiam
--
Łukasz http://www.lenart.org.pl/
mobile +48 606 323 122, office +27 11 0838747
Warszawa JUG conference - Confitura http://confitura.pl/

[Łukasz Lenart]

W dniu 16 maja 2012 10:15 użytkownik Wojciech Erbetowski
<wojc...@erbetowski.pl> napisał:

> Tester w Wickecie naprawdę jest godny pozazdroszczenia, ale nie pomoże Ci
> jeśli się okaże, że musisz wycisnąć 'więcej' z HTTP.

Tego właśnie mi brakuje w porównywaniu łebfrejmłorków - wydajności czy
też skalowalności. Nawet wspominany tu devrates.com pokazuje jakieś
pierdy w stylu Usability, Simplicity,... ;-)

[Adam Lider]

On May 16, 2012, at 10:03 AM, Michal Margiel wrote:

> Serio Wicket ze swoim WicketTesterem jest cieższy w utrzymaniu niż spring mvc/servlety? Nie mówie że jest to idealny/najlepszy framework - ale na pewno nie skazywał bym go od razu na śmierć.
>
> Jak czytam "Tylko Spring MVC - a reszta się do niczego nie nadaje" to przypomina mi się scena z Dnia świra o "najmojszej racji". Myślę że temat nie jest aż tak prosty.

Chodzilo mi bardziej o "Tylko nie JSF". Springa MVC moge polecic prawie w ciemno, ale oczywiscie sa tez inne dobre opcje jak np. Wicket.

Dla lubiacych eksperymetowac moge polecic podejscie "logic less templating".

[Jakub Nabrdalik]

W dniu 16 maja 2012 10:03 użytkownik Michal Margiel

<michal....@gmail.com> napisał:

> W dniu 16 maja 2012 09:53 użytkownik Jakub Nabrdalik <jak...@gmail.com>
> napisał:
>
>> W dniu 16 maja 2012 06:15 użytkownik Adam Lider
>> <adam....@googlemail.com> napisał:
>> > Nie warto, ani w wersji 2, ani 3, ani zadnej innej opartej na JSF.
>> > Wystarczy juz tych JSFowych projektow (jak i GWT).
>> >
>> > Bezpieczny i "zgodny z natura" wybor to: Spring MVC + HTML/CSS +
>> > JavaScript + (w zaleznosci od tego jak bardzo "rich" ten frontend ma byc)
>> > np. jQuery, Backbone.js, ExtJS
>>
>> +1
>>
>> Nie ignoruj technologii najbliższych webowi (html/js/coś prostego w
>> backendzie), są zwykle dużo łatwiejsze w utrzymaniu niż np. frameworki
>> komponentowe.
>
>
> Serio Wicket ze swoim WicketTesterem jest cieższy w utrzymaniu niż spring
> mvc/servlety? Nie mówie że jest to idealny/najlepszy framework - ale na
> pewno nie skazywał bym go od razu na śmierć.

Ja też :) Ale i tak łatwiej mi się robi w grailsach (czyli spring mvc
pod spodem).

WicketTester jest super (choć mógłby być szybszy). Co mi przypomniało,
że mam kilka testów do napisania :D

[Adam Lider]

On May 16, 2012, at 10:17 AM, Łukasz Lenart wrote:

> Dość często to nie w tym problem, w większości przypadków okazuje się,
> że nawet standardowe rzeczy zrobić jest ciężko, a bo to bug w
> implementacji, albo braki dokumentacji.
>
> JSF to jednak standard i znając gdzie są miny można go używać - tylko
> wpierw trzeba na te miny wejść ;-)

Standard - magiczne slowo, dzieki ktoremu tak wiele jest wybaczane tej technologii. Choc sam nie mam duzego doswiadczenia z JSF (omijam to jak moge) to wiedzialem z bliska kilka projektow, gdzie development stal w miejscu przez szukanie obejsc i hakow, a mimo to w nastepnym projekcie wybierany byl JSF. Pojde moze za daleko, ale wrecz mialem przekonanie, ze raz czy dwa to wcale nie klient nalegal na standard, ale to developerzy (znajacy JSF i wszystkie problemy) podpierali sie standardem nie do konca chyba uczciwie (mowie tutaj o moich konkretnych przypadkach).

Adam.

[Michal Margiel]

W dniu 16 maja 2012 10:29 użytkownik Jakub Nabrdalik <jak...@gmail.com> napisał:

Ja też :) Ale i tak łatwiej mi się robi w grailsach (czyli spring mvc
pod spodem).

nie no.. grails to grails a nie Spring MVC. W przeciwnym wypadku wszyscy moglibyś powiedzieć że robimy w servletach a nie we frameworku XYZ ;)

[Jakub Nabrdalik]

W dniu 16 maja 2012 10:38 użytkownik Michal Margiel
<michal....@gmail.com> napisał:

> nie no.. grails to grails a nie Spring MVC. W przeciwnym wypadku wszyscy
> moglibyś powiedzieć że robimy w servletach a nie we frameworku XYZ ;)

http://grails.org/Developer+-+Spring+MVC+Integration

"Grails uses Spring MVC as the underlying web application framework.
Spring MVC might not be the simplest framework to use but it is most
definitely one of the most extensible making it perfect for Grails.
The Grails servlet extends Spring's DispatcherServlet to bootstrap the
Grails environment, there is then a single Spring MVC controller
called org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsController
that handles all Grails controller requests."

[Jakub Nabrdalik]

2012/5/16 Jakub Nabrdalik <jak...@gmail.com>:

W tym znaczeniu napisałem "pod spodem".

[Piotr Przybylak]

16-05-2012 10:42 użytkownik "Jakub Nabrdalik" <jak...@gmail.com> napisał:

> W tym znaczeniu napisałem "pod spodem".

I w tym samym znaczeniu grails to samo co jsf: servlety pod spodem ;)

[Jakub Nabrdalik]

On 16.05.2012 14:16, Piotr Przybylak wrote:
>
> 16-05-2012 10:42 użytkownik "Jakub Nabrdalik" <jak...@gmail.com

> <mailto:jak...@gmail.com>> napisał:

>
> > W tym znaczeniu napisałem "pod spodem".
>
> I w tym samym znaczeniu grails to samo co jsf: servlety pod spodem ;)

Ok, I've seen enough of Hentai, to know where this is going.

So yes, I really like this bytecode grails produces underneath :)

--
Jakub Nabrdalik
blog.solidcraft.eu

[Olaf Matyja]

A która to była wersja JSF?

Od czasu przejścia w jsf 2.0 z JSP na facelety sporo problemów zniknęło bo były spowodowane przez niekompatybilność cyklu zycia stron jsf i jsp. Poprawiła się też współpraca z warstwą modelu.

Primefaces w końcu zapewniają ładny i szeroki zestaw komponentów, a Prettyfaces sensowne mapowanie URLi. Choć to już oczywiście nie są produkty ze "standardu".

Więc teraz w zasadzie niepotrzebnie nazywają to ciągle starą, źle się kojarzącą nazwą, bo to już jest całkiem inny framework.

Pozdrawiam,
Olaf

On 16 May 2012 10:34, "Adam Lider" <adam....@googlemail.com> wrote:

On May 16, 2012, at 10:17 AM, Łukasz Lenart wrote:

> Dość często to nie w tym problem, w większośc...

Standard - magiczne slowo, dzieki ktoremu tak wiele jest wybaczane tej technologii. Choc sam nie mam duzego doswiadczenia z JSF (omijam to jak moge) to wiedzialem z bliska kilka projektow, gdzie development stal w miejscu przez szukanie obejsc i hakow, a mimo to w nastepnym projekcie wybierany byl JSF. Pojde moze za daleko, ale wrecz mialem przekonanie, ze raz czy dwa to wcale nie klient nalegal na standard, ale to developerzy (znajacy JSF i wszystkie problemy) podpierali sie standardem nie do konca chyba uczciwie (mowie tutaj o moich konkretnych przypadkach).

Adam.

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).

Więcej informacji na stronie http://...

[Grzesiek]

Dzięki za informacje i zaangażowanie. Jak zawsze można na was liczyć
chociaż przyznam, że ciężko mi skupić się na jednej odpowiedzi bo
widzę ze zdania są podzielone.

Ponieważ do pomocy planuje jeszcze kogoś zatrudnić to muszę się też
kierować faktem do czego najłatwiej kogoś znaleźć :)

A jeśli miałbym wybierać nauke Springa MVC od zera a pisnie w Seam 2,
w którym mam doświadczenie to jednak wiele musiałby przeważyć na
szali.

Co do User interface to wymagania są spore ale nie nam stawiane tylko
drugiej firmie która robi html + css + js, włącznie z animacjami.
Dlatego nie ma mowy o generowaniu js chyba ze do walidacji.

Pozdrawiam
Grzesiek

[Łukasz Lenart]

JSF 2.0 i wprowadzenie facletow wprowadzilo nowe problemy ;-)

I mysle ze najwieksza bolaczka jest compile time i render time :-/

/Lukasz

W dniu 2012-05-16 16:05 użytkownik "Olaf Matyja" <ola...@gmail.com> napisał:

A która to była wersja JSF?

Od czasu przejścia w jsf 2.0 z JSP na facelety sporo problemów zniknęło bo były spowodowane przez niekompatybilność cyklu zycia stron jsf i jsp. Poprawiła się też współpraca z warstwą modelu.

Primefaces w końcu zapewniają ładny i szeroki zestaw komponentów, a Prettyfaces sensowne mapowanie URLi. Choć to już oczywiście nie są produkty ze "standardu".

Więc teraz w zasadzie niepotrzebnie nazywają to ciągle starą, źle się kojarzącą nazwą, bo to już jest całkiem inny framework.

Pozdrawiam,
Olaf

>
> On 16 May 2012 10:34, "Adam Lider" <adam....@googlemail.com> wrote:
>

>
> On May 16, 2012, at 10:17 AM, Łukasz Lenart wrote:
>

> Dość często to nie w tym problem, w większośc...

>
> Standard - magiczne slowo, dzieki ktoremu tak wiele jest wybaczane tej technologii. Choc sam ni...

>
>
> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).

Więcej informacji na stronie http://...

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).

Więcej informacji na stronie http:/...

[Sławek Sobótka]

Co do User interface to wymagania są spore ale nie nam stawiane tylko
drugiej firmie która robi html + css + js, włącznie z animacjami.
Dlatego nie ma mowy o generowaniu js chyba ze do walidacji.

Swego czasu dużo siedziałem w JSF (ze springiem), później Seam 2, do tego jeszcze równolegle Spring MVC + lekkie templaty.

Uważaj na jedną rzecz: zrobicie sobie widoki w jakiś bibliotekach komponentów *Faces i będziecie próbować "ostylować" je czymś co dostaniecie od firmy graficznej.

Mission impossible.

Przykładowo słynne "skinability" w RichFaces. W rzeczywistości jest tak, że możesz co najwyżej kolorki zmienić. Ilość i struktura divów oraz tabelek jest taka, że nigdy nie nałożysz na to grafiki pociętej przez firmę trzecią.

Z tego co wiem, to w jednej dużej stołecznej firmie zatonął przez to projekt, który miał już prawie backend:)

Może jakiś rozbitek coś opowie..:)

Jedyny mający szansę powodzenia  proces produkcji UI, które ma wyglądać zgodnie z wytycznymi "artysty" jest taki jak już wspomniano:

- dostajesz pociętego HTMLa i CSS od firmy graficznej

- strukturyzujesz to do szablonów (np facelets) i ew reużywalnych "strzępków html" / "płytek"

- zamieniasz inputy na dynamiczne komponenty (np jsf)

- dodajesz sobie cukierki w jQuery

(np. zakładki, które mają mieć słodko zaokrąglone rogi wg wizji grafika robisz przez jQuery a nie komponenty typu RichFaces)

powodzenia

Sławek Sobóka

http://art-of-software.blogspot.com/ 

http://ssepp.pl

[Piotrek]

ja nie jestem frontendowcem ale temat poszedl w ciekawa strone wiec
zapytam jak to u was w praktyce wyglada. frameworki, ktorych glowna
zaleta jest duza baza komponentow (np. jsf, smartgwt) maja
zastosowanie tylko do projektow, w ktorych klienta nie obchodzi wyglad
aplikacji? intranet, tam gdzie aplikacja ma po prostu dzialac. wtedy
szybko mozna zrobic cos calkiem ladnego i mile zaskoczyc klienta.
natomiast tam gdzie dla klienta wazny jest promien zaokraglenia
przyciskow, kierunek i szybkosc rozwijania sie hintow itp, nalezy
stosowac frameworki (badz ich fragmenty), ktore omijaja tworzenie
html'a szerokim lukiem (np spring mvc, struts)? a caly uklad graficzny
robic w czystym html + biblioteki js?

[Jakub Nabrdalik]

On 19.05.2012 16:06, Piotrek wrote:
> ja nie jestem frontendowcem ale temat poszedl w ciekawa strone wiec
> zapytam jak to u was w praktyce wyglada. frameworki, ktorych glowna
> zaleta jest duza baza komponentow (np. jsf, smartgwt) maja
> zastosowanie tylko do projektow, w ktorych klienta nie obchodzi wyglad
> aplikacji? intranet, tam gdzie aplikacja ma po prostu dzialac. wtedy
> szybko mozna zrobic cos calkiem ladnego i mile zaskoczyc klienta.
> natomiast tam gdzie dla klienta wazny jest promien zaokraglenia
> przyciskow, kierunek i szybkosc rozwijania sie hintow itp, nalezy
> stosowac frameworki (badz ich fragmenty), ktore omijaja tworzenie
> html'a szerokim lukiem (np spring mvc, struts)? a caly uklad graficzny
> robic w czystym html + biblioteki js?

Mniej więcej. Ale w pierwszym przypadku (gdy gui nie musi być slitaśne),
bardziej liczy się to że frameworki komponentowe dają z pudełka
look&feel desktopowy (sortowanie, page'owanie, filtrowanie tabelek,
zmiany wielkości, przeciąganie, etc.) i nie wyglądają jak dupa zza
krzaka, bez kilku dni zabawy w css'y.

A przynajmniej tak to racjonalizuje moje szefostwo :)


--
Jakub Nabrdalik
blog.solidcraft.eu

[Irek Matysiewicz]

Wg mnie to wszystko zależy od tego co ma być zrobione:
- superwypasiony design robiony przez grafika -> babramy się niskopoziomowo w HTML + JavaScript + CSS
- przyciski, formularze, sortowalne tabelki i takie tam -> używamy wypasionych "wysokopoziomowych" komponentów np. z GWT czy JSF

[Sławek Sobótka]

Tworząc małą *aplikację* można przyjąć pewne założenia i dostosować do nich architekturę (w tym stos frameworkwó).

Natomiast większy *system* zawsze będzie zawierał w sobie funkcjonalności (być może zamapowane na moduły) różnej klasy:

- backofficowe ficzery, które można zbudować np. w JSF  + Hibernate

- w tym sporą część CRUDowych ficzerów, które można "wyklikać" w kolejnych frameworkach tworzonych przez ludzi, którzy urodzili się po erze MS Access i próbują powielić jego produktywność:)

- ficzery publikowane na świad zewnętrzny, które ze względu na wymagania niefunkcjonalne (wydajność, usability, ui design) nie da się zrobić w Hibernate i np JSF a będą wymagać NoSQLa lub SQLa dopieszczonego przez DB-Nazi, lekkich templateów HTML z cachoewaniem framgentów stron, arch. "share-nothing", zdarzeń i kompromisów typu eventual consistency w celu osiągnięcia skalowania, 

Wszystkim tym może zawiadywać np Spring ze swoim Security...

powodzenia:)

Sławek Sobótka

http://art-of-software.blogspot.com/

http://ssepp.pl

[Adam Lider]

On May 20, 2012, at 7:37 PM, Irek Matysiewicz wrote:

> Wg mnie to wszystko zależy od tego co ma być zrobione:
> - superwypasiony design robiony przez grafika -> babramy się niskopoziomowo w HTML + JavaScript + CSS
> - przyciski, formularze, sortowalne tabelki i takie tam -> używamy wypasionych "wysokopoziomowych" komponentów np. z GWT czy JSF

Chcialbym zwrocic uwage na zwrot "babramy się niskopoziomowo w HTML + JavaScript + CSS". Dosc czesto w dyskusjach projektowych mozna uslyszec takie lub w podobnym stylu zwroty. Mi tez sie to zdarza. Wynika to przede wszystkim z faktu ze Web dla nas, Javowcow nie jest przyjaznym srodowiskiem.

Po roku, czy dwoch siedzenia w Struts 1 sam zaczalem myslec na bardziej komponentowym frameworkiem (pewnie nie jestem wyjatkiem ;). Zaczalem wlasnie od tabelki, ktorej mozna przekazac jakis DataSet i skonfigurowac wszystko (kolumny, stronicowanie, sortowanie itp) tak aby tego htmla nie dotykac (bylo to ok 2004 roku). Wtedy nawet dynamika (ajax) nie byla potrzebna. Jednak po pierwszych probach zastosowania tej tabelki w 2 konkretnych problemach zrozumialem jak trudne to zadanie i ze ilosc opcji konfiguracyjnych, aby spelnic wymagania obu projektow, zaczyna byc problemem. Potem doszedl kolejny projekt, w ktorych tez chcialem uzyc cudownej tabelki i zrozumialem, ze nie tedy droga i tabelka poszla do kosza. Mniej wiecej wtedy uslyszalem o JSF i powiem szczerze, majac na uwadze swoje doswiadczenie bylem zaciekawiony jak im pojdzie, w koncu idea podobna. Wrocilem do babrania sie w HTMLu (a sorry jeszcze byl eksperyment z GWT - wersja 1.3 wtedy, ale to inna historia ;), chociaz typowym frontendowcem nie jestem.

Sam nigdy JSF nie zastosowalem, ale bylem w kilku projektach gdzie ten framework byl uzyty. Nie wszystkie z nich to porazka, niektore jakos sie trzymaja, ale powazne i specyficzne dla tej technologii problemy byly wszedzie. Wynikaja one nie z samej technologii, ale z zalozen na jakich zostala zbudowana. W niektorych aspektach mozna porownac JSF i JPA/Hibernate. Oba rozwiazania sa abstrakcjami opartymi na jakims zestawie technologii ponizej nich. Jednak JPA jest oparta na bardzo stabilnej warstwie jaka jest SQL. Tutaj chociaz tez sa odstepstwa od standardu to jednak nawet one sa stabilne i udokumentowane. Mimo to czasem JPA tez czasem cieknie jako abstrakcja. Na takiej podstawie mozna probowac budowac jakies abstrakcje. Natomiast Web jest inny. Web is open, jak niektorzy mawiaja. Tutaj praktycznie nie ma standardow, implementacji jest kilka, silnie ze soba rywalizujacych.
O ile powstanie JSF jest dosc naturalna proba i mozna zrozumiec, to JSF2 dla mnie jest juz wyrazem arogancji jej tworcow. Nie mam nic przeciwko ulepszeniom w JSF2, ale sama nazwa sugeruje jakoby to podejscie bylo sukcesem, ktory warto kontyuowac. Co wiecej JSF i JSF2 powstaly w zupelnie innych Webach. Gdy powstawalo JSF2 dynamika zmian zachodzacych w Webie byla juz duza (zapowiedz nowych wersji JS,HTML,CSS, popularyzacja AJAX), powstalo rowniez tez kilka narzedzi, ktore glowny problem, czyli brak kompatyblinosci rozwiazuja bilzej zrodla (jQuery). Web jest trudny jako srodowisko, ale myslenie ze my ze swoja Java i abstrakcja, rozwiazemy jego problemy jest podejsciem aroganckim i naiwnym. Prawda jest taka ze my jestesmy goscmi w tym swiecie (rok temu to zrozumialem, dzieki devmeetings.pl).

Jesli chcemy robic rich frontendy to bez specjalistow (programistowa JS) nie damy rady. Jesli nasz interfejs ma byc w miare lady i lekko dynamiczny to wystarczy jakis prosty CSS (gotowe sa wszedzie) i przyjazny jQuery. Mozna spojrzec na Bootstrap. Akutalnie jest tego duzo i sa to rozwiazania, ktore ogranicznaja nas w b. malym stopniu w przeciwienstwie do JSF. Natomiast nasz framework powinien zapewnic w miare dobry silnik szablonow, proste gotowe komponenty jak linki, przyciski, elementy formularzy i ulatwiac oblsuge HTTP, reszte zostawmy specjalistom.

Swoja droga, to tyle sie mowie o nauce Scali, ktora prosta nie jest i o konkretne argumenty ciezko, a jakos brak checi lepszego poznania trojcy HTML/CSS/JS + jQuery.

Adam.

[Grzegorz Balcerek]

> Swoja droga, to tyle sie mowie o nauce Scali, ktora prosta nie jest i o

> konkretne argumenty ciezko (...)

Podaj� konkretny argument: w Scali �atwiej si� programuje funkcyjnie.
Pozdrawiam,
Grzegorz

[Adam Lider]

On May 21, 2012, at 12:46 PM, Grzegorz Balcerek wrote:

>> Swoja droga, to tyle sie mowie o nauce Scali, ktora prosta nie jest i o konkretne argumenty ciezko (...)
>

> Podaję konkretny argument: w Scali łatwiej się programuje funkcyjnie.

Fakt, ale na ile ta funkcyjnosc jest nam potrzebna? W moich projektach (tych co robilem), gdzie glownie chodzilo o dosc zlozona domene, aspekty integracyjne, sporo IO, nie widze miejsca dla tej funkcyjnosci. Gdybym jednak robil cos bardziej obliczeniowego to moze i tak.

JavaScript to tez (czesciowo) funkcyjny jezyk ;)

Adam.

[Jacek Laskowski]

2012/5/21 Adam Lider <adam....@googlemail.com>:

> Fakt, ale na ile ta funkcyjnosc jest nam potrzebna?

Mi nasuwa się odpowiedź: "Wszędzie tam, gdzie obecnie pakujemy obiektowość".

Czy mógłbyś przyjąć tezę, że wszystkie bolączki Seam 2, JSF 2 i kilku
innych górnopoziomowych rozwiązań wynikają z braków uwagi dla podstaw,
na których się one opierają? Odnoszę wrażenie, że wielu po prostu
upiera się przy zastosowaniu znanego do większości problemów,
bo...znane. Nieznane pozostają takimi, bo...brak chęci i czasu na ich
poznanie.

[Olaf Matyja]

Zaciekawiłeś mnie. W jakim sensie funkcyjność jest zamiennikiem obiektowości?

Chociaż... programowanie sieciowe sprowadza się koniec końców do wyliczenia treści strony lub (ajax, portlety) jej fragmentu. To by świetnie pasowało do paradygmatu programowania funkcyjnego, gdzie wszystko jest funkcją, tylko czy istnieje jakikolwiek funkcyjny web framework? Np. wykorzystujący funkcyjne możliwości Scali?

Pozdrawiam,
Olaf

On 21 May 2012 14:21, "Jacek Laskowski" <ja...@japila.pl> wrote:

2012/5/21 Adam Lider <adam....@googlemail.com>:

> Fakt, ale na ile ta funkcyjnosc jest nam potrzebna?

Mi nasuwa się odpowiedź: "Wszędzie tam, gdzie obecnie pakujemy obiektowość".

Czy mógłbyś przyjąć tezę, że wszystkie bolączki Seam 2, JSF 2 i kilku
innych górnopoziomowych rozwiązań wynikają z braków uwagi dla podstaw,
na których się one opierają? Odnoszę wrażenie, że wielu po prostu
upiera się przy zastosowaniu znanego do większości problemów,
bo...znane. Nieznane pozostają takimi, bo...brak chęci i czasu na ich
poznanie.

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -

http://blog...

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).

Więcej informacji na stronie http://g...

[Jacek Laskowski]

2012/5/21 Olaf Matyja <ola...@gmail.com>:

> Zaciekawiłeś mnie. W jakim sensie funkcyjność jest zamiennikiem
> obiektowości?
>
> Chociaż... programowanie sieciowe sprowadza się koniec końców do wyliczenia
> treści strony lub (ajax, portlety) jej fragmentu. To by świetnie pasowało do
> paradygmatu programowania funkcyjnego, gdzie wszystko jest funkcją, tylko
> czy istnieje jakikolwiek funkcyjny web framework? Np. wykorzystujący
> funkcyjne możliwości Scali?

W końcu komuś zaskoczyło! :-) Czym więcej siedzę przy Clojure, tym
bardziej zastanawiam się, dlaczego przyszło nam do głowy babrać się z
webem w Javie?!

Teraz kolejna zabawa umysłowa - nie potrzeba Ci "funkcyjnego web
frameworka", a jedynie zestawu funkcji. Ale skoro nalegasz - szukaj
noir, albo compojure. Od tego zacznij, a pewnie skończysz na zestawie
bibliotek. Zachęcam do popróbowania i raportowania postępów.

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -

[Grzegorz Balcerek]

Znacie esej Paula Grahama "Beating the Averages"? Nie dotyczy co prawda
Clojure, ale lispa, wi�c blisko. No i dotyczy aplikacji webowej.
http://paulgraham.com/avg.html
Grzegorz
----- Original Message -----
From: "Jacek Laskowski" <ja...@japila.pl>
To: <warsza...@googlegroups.com>
Sent: Monday, May 21, 2012 11:44 PM
Subject: Re: [warszawa-jug] Re: Czy warto u�ywa� Seam do


2012/5/21 Olaf Matyja <ola...@gmail.com>:
> Zaciekawi�e� mnie. W jakim sensie funkcyjno�� jest zamiennikiem
> obiektowo�ci?
>
> Chocia�... programowanie sieciowe sprowadza si� koniec ko�c�w do
> wyliczenia
> tre�ci strony lub (ajax, portlety) jej fragmentu. To by �wietnie pasowa�o
> do
> paradygmatu programowania funkcyjnego, gdzie wszystko jest funkcjďż˝, tylko
> czy istnieje jakikolwiek funkcyjny web framework? Np. wykorzystuj�cy
> funkcyjne mo�liwo�ci Scali?

W ko�cu komu� zaskoczy�o! :-) Czym wi�cej siedz� przy Clojure, tym
bardziej zastanawiam si�, dlaczego przysz�o nam do g�owy babra� si� z
webem w Javie?!

Teraz kolejna zabawa umys�owa - nie potrzeba Ci "funkcyjnego web

frameworka", a jedynie zestawu funkcji. Ale skoro nalegasz - szukaj

noir, albo compojure. Od tego zacznij, a pewnie sko�czysz na zestawie
bibliotek. Zach�cam do popr�bowania i raportowania post�p�w.

Jacek

--
Jacek Laskowski
Functional languages (Clojure), Java EE, and IBM WebSphere -
http://blog.japila.pl
"Never discourage anyone who continually makes progress, no matter how
slow." Plato

--
Wiadomo�� z grupy Warszawa Java User Group (Warszawa JUG).
Wi�cej informacji na stronie
http://groups.google.com/group/warszawa-jug?hl=pl
Zach�camy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na
http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Grzegorz Balcerek]

Jeszcze to powinienem byďż˝ podlinkowaďż˝ (to teďż˝ Paul Graham i teďż˝ o tej samej
aplikacji webowej, no i bardziej na temat chyba).
"Lisp in Web-Based Applications"
http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt

[Krzysztof Miksa]

> Przykładowo słynne "skinability" w RichFaces. W rzeczywistości jest tak, że
> możesz co najwyżej kolorki zmienić. Ilość i struktura divów oraz tabelek
> jest taka, że nigdy nie nałożysz na to grafiki pociętej przez firmę trzecią.

Nie mogę się z Tobą zgodzić. Dla klientów, dla których pracuję, bardzo
liczy się wygląd aplikacji i to on dostarcza nam grafikę. Albo jestem
niedoświadczony albo grafika którą dostarcza klient zawsze idealnie
pasuje do RichFaces ale jeszcze ani razu nie powiedzieliśmy 'sorry ale
nie da się tego zrobić'. Według mnie można ładnie manipulować wyglądem
komponentami RF'owymi.

Pozdrawiam
Krzysiek

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie

> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

[Olaf Matyja]

From: Jacek Laskowski

>2012/5/21 Olaf Matyja <ola...@gmail.com>:
>> Zaciekawi�e� mnie. W jakim sensie funkcyjno�� jest zamiennikiem
>> obiektowo�ci?
>>
>> Chocia�... programowanie sieciowe sprowadza si� koniec ko�c�w do
wyliczenia

>> tre�ci strony lub (ajax, portlety) jej fragmentu. To by �wietnie pasowa�o
do

>> paradygmatu programowania funkcyjnego, gdzie wszystko jest funkcjďż˝, tylko
>> czy istnieje jakikolwiek funkcyjny web framework? Np. wykorzystuj�cy
>> funkcyjne mo�liwo�ci Scali?
>
>W ko�cu komu� zaskoczy�o! :-) Czym wi�cej siedz� przy Clojure, tym
>bardziej zastanawiam si�, dlaczego przysz�o nam do g�owy babra� si� z
>webem w Javie?!

No, wi�kszo�� �wiata dosz�a do podobnego wniosku i robi to w PHP-ie i
.necie, cho� mo�e z innych przyczyn. ;-)
Java obs�uguje 3.9% backend�w (�r�d�o:
http://w3techs.com/technologies/overview/programming_language/all ).

>Teraz kolejna zabawa umys�owa - nie potrzeba Ci "funkcyjnego web

>frameworka", a jedynie zestawu funkcji. Ale skoro nalegasz - szukaj

>noir, albo compojure. Od tego zacznij, a pewnie sko�czysz na zestawie
>bibliotek. Zach�cam do popr�bowania i raportowania post�p�w.

To jest zabawa, ale nie umys�owa, tylko gra s��w. Je�li nie chc� wy�uskiwa�
parametr�w ��dania z nag��wka HTTP, czy programowa� osobi�cie identyfikatora
sesji, to potrzebuj� kodu, kt�ry zrobi cho�by tylko to za mnie. Mog� tego
nie nazywa� frameworkiem, je�li wolisz, ale czasy CGI i pisania wszystkiego
samemu jednak odesz�y (na szcz�cie).

Obejrza�em sobie przyk�ady do Compojure i Noir tutaj:
https://github.com/weavejester/compojure-example/blob/master/src/compojure/e
xample/views.clj i tutaj: http://webnoir.org/tutorials

Pierwsze wra�enia (by� mo�e mylne, bo przyznaj�, �e nic w tym nie robi�em):

1. Podoba mi si� to, �e mog� zrobi� filtr, szablon, itp. w naturalny spos�b
za pomocďż˝ funkcji.

2. Generowanie HTML-a wydaje mi siďż˝ za to trudniejsze i bardziej zagmatwane
nawet ni� wpisywanie kodu HTML bezpo�rednio do serwlet�w, bo ka�demu tagowi
odpowiada tablica lub funkcja o odmiennej sk�adni. Grafik znaj�cy HTML i CSS
b�dzie mia� z tym k�opot, �aden program do wizualnego projektowania tego nie
z�apie (chyba �e istnieje jaki� dedykowany do Closure, albo translator HTML
na ten j�zyk). Je�li kto� krytykuje JSP, JSF czy GWT za to, �e nie
korzystaj� z czystego HTML-a i trudno edytowa� ich widoki, to tutaj wygl�da
to znacznie gorzej.

3. W �adnym z tych dw�ch framework�w nie widzia�em jakiego� wsparcia dla
wygl�du strony, id�cego dalej ni� szablonizacja go�ego HTML. Wszystko ko�czy
si� w tym miejscu, co JSP - jest technologia template-�w, ale �adnych
bardziej z�o�onych widget�w ni� dost�pne w HTML. Brakuje mi te� wbudowanych
temat�w CSS, cho�by czego� takiego jak jQuery UI, przeniesione do �wiata
Javy przez PrimeFaces. Trzeba wi�c zrobi� frontend za pomoc� CSS-a i JQuery,
ale nie widz�c HTML-a, tylko edytuj�c tablice specyficzne dla danego
frameworka. Pewnie wszystkiego da si� nauczy�, ale nie wygl�da to na
u�atwienie.

4. Nie widzia�em wsparcia dla Ajaxa, ale mo�e gdzie� jest, tylko nie
znalaz�em. Oczywi�cie zawsze mo�na samemu...

5. Wydaje mi si� (mo�e si� myl�), �e integracja z warstw� modelu wygl�da
tak, �e model mo�e sobie przeczyta� parametry ��dania i sesji. Czyli
wsparcie dla wzorca MVC jest �adne, nie ma izolacji, jak� zapewnia cho�by
Spring, nie ma te� jakiego� wstrzykiwania parametr�w ��dania jak cho�by w
JSP czy JSF.

6. Mia�em nadziej� na jakie� hardcorowe programowanie funkcyjne, typu monady
z Haskella, a tu takie sobie po prostu tablice, i funkcje niczym z Logo. ;-)
Ale w sumie s�usznie, pewnie wi�cej nie trzeba, a to by jeszcze bardziej
podnios�o pr�g wej�cia.

7. Kod wygl�da na kr�tki, z pewno�ci� pewne rzeczy s� prostsze i bardziej
naturalne niďż˝ w Javie.

Mam pytanie - Pr�bowa�e� wykorzysta� Closure do generacji widok�w w jakim�
wi�kszym projekcie webowym? Bo o ile podoba mi si� idea template-�w opartych
na funkcjach, to spos�b zakodowania tych widok�w sprawia chyba, �e trudno to
po��czy� z dostarczonym przez grafik�w HTML-em. Owszem, mo�na go ca�ego
wczyta� w jakiej� funkcji, ale to wszystko, ka�da pr�ba przerobienia go na
parametryzowany szablo to ju� b�dzie grzebanina w stringach, bo tekst HTML
nie wywo�a chyba funkcji Closure. Mam wi�c wra�enie, �e przer�bk� HTML-a na
parametryzowany szablon pro�ciej zrobi� nawet w JSP, nie m�wi�c o JSF, czy
Wickecie. Ale mam nadziej�, �e mnie wyprowadzisz z b��du.

Pozdrawiam,
Olaf

[Adam Lider]

On May 21, 2012, at 2:21 PM, Jacek Laskowski wrote:

> 2012/5/21 Adam Lider <adam....@googlemail.com>:
>
>> Fakt, ale na ile ta funkcyjnosc jest nam potrzebna?
>
> Mi nasuwa się odpowiedź: "Wszędzie tam, gdzie obecnie pakujemy obiektowość".

Jak juz pisalem, moje projekty to glownie systemy transakcyjne, integracyjne i troche Weba. W takim srodowisku OO fajnie spelnia role strukturyzujaca cala aplikacje i ciezko mi sobie wybrazic te systemy bez tego (nie ogarniam jeszcze;). Natomiast widze miejsce dla funkcyjnych implementacji niektorych aspektow tych systemow. Dobrym przykladem jest dosc zaawansowany kalkulator leasingowy. Domena byla/jest dosc skomplikowana (mnogosc produktow, zaleznosci pomiedzy nimi, opcje konfiguracyjne itp) i strukturyzacja OO ma swoje miejsce, ale obliczenia i pewne operacje fajnie by (chyba) wygladaly w implementacji funkcyjnej (teraz to sa dosc dlugie procedury).

Generalnie model gdzie OO spelnia role szkieletu i podstawy dla elementow np. funkcyjnych wydaje mi sie tym naturalnym, szczegolnie w wiekszych systemach. Tak wiec, wedlug mnie, dla moich projektow to funkcyjnosc jest/moze byc uzupelnieniem obiektowosci niz jego alternatywa.

> Czy mógłbyś przyjąć tezę, że wszystkie bolączki Seam 2, JSF 2 i kilku
> innych górnopoziomowych rozwiązań wynikają z braków uwagi dla podstaw,
> na których się one opierają? Odnoszę wrażenie, że wielu po prostu
> upiera się przy zastosowaniu znanego do większości problemów,
> bo...znane. Nieznane pozostają takimi, bo...brak chęci i czasu na ich
> poznanie.

Tak.

Adam.

[Jacek Laskowski]

2012/5/22 Adam Lider <adam....@googlemail.com>:

> Tak wiec, wedlug mnie, dla moich projektow to funkcyjnosc jest/moze byc uzupelnieniem obiektowosci niz jego alternatywa.

Cześć,

Pełna zgoda! Tak też prowadziłem dzisiejszą prezentację.

[Jacek Laskowski]

2012/5/22 Olaf Matyja <ola...@gmail.com>:

> To jest zabawa, ale nie umysłowa, tylko gra słów.

Framework == oprogramowanie, które woła Ciebie.
Biblioteka == oprogramowanie, które wołasz.

Dla mnie różnica znaczna i uzmysławia problem.

> 3. W żadnym z tych dwóch frameworków nie widziałem jakiegoś wsparcia dla
> wyglądu strony, idącego dalej niż szablonizacja gołego HTML.

Compojure i Noir się tym nie zajmują. To zadanie dla enlive, hiccup i
pewnie kilku innych.

> 4. Nie widziałem wsparcia dla Ajaxa, ale może gdzieś jest, tylko nie
> znalazłem. Oczywiście zawsze można samemu...

Ajax to technologia po stronie przeglądarki. Co chciałbyś po stronie
serwera? Obsługę żądania - nic innego niż obsługa zwykłego żądania. Co
więcej chciałbyś?!

> 5. Wydaje mi się (może się mylę), że integracja z warstwą modelu wygląda
> tak, że model może sobie przeczytać parametry żądania i sesji. Czyli
> wsparcie dla wzorca MVC jest żadne, nie ma izolacji, jaką zapewnia choćby
> Spring, nie ma też jakiegoś wstrzykiwania parametrów żądania jak choćby w
> JSP czy JSF.

Jeśli zaczniesz wyszukiwać czego brakuje Clojure czy innemy językowi
funkcyjnemu, a co masz dostępne w Javie i jego świecie, nie powinieneś
się dziwić, że znajdujesz te i inne kwiatki. Pewnie będzie tego
więcej.

Może pora postawić inne pytanie? Jakich funkcji (w sensie bytów w
Clojure) Ci potrzeba?

> 7. Kod wygląda na krótki, z pewnością pewne rzeczy są prostsze i bardziej
> naturalne niż w Javie.

To dzisiaj było oczekiwaniem kilku uczestników i mam wrażenie, że nie
byłem przygotowany na odpowiedź.

> Mam pytanie - Próbowałeś wykorzystać Closure do generacji widoków w jakimś
> większym projekcie webowym? Bo o ile podoba mi się idea template-ów opartych
> na funkcjach, to sposób zakodowania tych widoków sprawia chyba, że trudno to
> połączyć z dostarczonym przez grafików HTML-em. Owszem, można go całego
> wczytać w jakiejś funkcji, ale to wszystko, każda próba przerobienia go na
> parametryzowany szablo to już będzie grzebanina w stringach, bo tekst HTML
> nie wywoła chyba funkcji Closure. Mam więc wrażenie, że przeróbkę HTML-a na
> parametryzowany szablon prościej zrobić nawet w JSP, nie mówiąc o JSF, czy
> Wickecie. Ale mam nadzieję, że mnie wyprowadzisz z błędu.

Tutaj, brak odpowiedzi zrzucę to na barki wciąż skromnego
doświadczenia w temacie. Skoro jest zainteresowanie, zaczynam
poszukiwanie odpowiedzi.

[Olaf Matyja]

From: Jacek Laskowski
>2012/5/22 Olaf Matyja <ola...@gmail.com>:
>

>> To jest zabawa, ale nie umys�owa, tylko gra s��w.
>

>Framework == oprogramowanie, kt�re wo�a Ciebie.
>Biblioteka == oprogramowanie, kt�re wo�asz.
>
>Dla mnie r�nica znaczna i uzmys�awia problem.

Zaraz, w takim razie z definicji nie da si� napisa� serwerowej cz�ci
aplikacji sieciowej inaczej ni� wewn�trz jakiego� frameworka, zawsze jakie�
oprogramowanie wywo�uje m�j kod w odpowiedzi na ��dania klienta. Nawet
zreszt� je�li odr�ni� kontener od frameworka (a w�a�ciwie w kt�rym miejscu
jest granica? czy JSP to jeszcze kontener serwlet�w, czy ju� framework? A
ASP.NET?), to ci�gle s� pewne operacje wykonywane przez doros�e frameworki,
kt�rych nie robi sam kontener serwlet�w, np. zbieranie multipart/form-data
do kupy czy przechowywanie zmiennych sesyjnych.

>> 3. W �adnym z tych dw�ch framework�w nie widzia�em jakiego� wsparcia dla
>> wygl�du strony, id�cego dalej ni� szablonizacja go�ego HTML.
>

>Compojure i Noir siďż˝ tym nie zajmujďż˝. To zadanie dla enlive, hiccup i
>pewnie kilku innych.

Popraw mnie, je�li si� myl�, ale Enlive to system szablon�w, a Hiccup to
reprezentacja HTML-a w postaci funkcji Clojure. Czyli nadal mamy
przekodowany HTML i system szablon�w. Nie mamy widget�w, AJAX-a, HTMLa
daj�cego si� obrabia� w edytorze wizualnym, gotowych temat�w CSS...

>> 4. Nie widzia�em wsparcia dla Ajaxa, ale mo�e gdzie� jest, tylko nie

>> znalaz�em. Oczywi�cie zawsze mo�na samemu...
>
>Ajax to technologia po stronie przegl�darki. Co chcia�by� po stronie
>serwera? Obs�ug� ��dania - nic innego ni� obs�uga zwyk�ego ��dania. Co
>wi�cej chcia�by�?!

Ajax to technologia po obydwu stronach, wymaga wsparcia i na serwerze.
Przyda�by si� np. znacznik <ajax> z JSF, bo ju� kompilacji Clojure do
JavaScriptu a la GWT nie wymagam ;-) Potrzeba po prostu czegoďż˝ na tyle
wysokopoziomowego, �ebym m�wi� tylko kt�re cz�ci strony kiedy renderowa�
AJAX-em, a nie musia� pisa� obs�uguj�cego tego JavaScriptu, osobnych
serwlet�w do ��da� tworzenia JSON-a z opisem cz�ci strony, itp. Niekt�re
frameworki (np. SmartGWT w p�atnej wersji) id� jeszcze dalej, deklarujesz
tylko "tu chc� mie� wynik tego SQL-a", a one ��cz� si� z serwerem, odpytuj�
baz� danych, renderuj� �adn� tabelk�, i przesy�aj� dane do klienta, a
wszystko na podstawie jednego tylko tagu XML-a. Co prawda potem sďż˝ problemy,
gdy odbiorca coďż˝ chce w tabelce zmieniďż˝, a framework akurat tego nie ma w
zestawie, ale do tworzenia na szybko raport�w "biznesiowych" jak znalaz�.
;-)

>> 5. Wydaje mi si� (mo�e si� myl�), �e integracja z warstw� modelu wygl�da
>> tak, �e model mo�e sobie przeczyta� parametry ��dania i sesji. Czyli
>> wsparcie dla wzorca MVC jest �adne, nie ma izolacji, jak� zapewnia cho�by
>> Spring, nie ma te� jakiego� wstrzykiwania parametr�w ��dania jak cho�by w
>> JSP czy JSF.
>

>Je�li zaczniesz wyszukiwa� czego brakuje Clojure czy innemy j�zykowi
>funkcyjnemu, a co masz dost�pne w Javie i jego �wiecie, nie powiniene�
>si� dziwi�, �e znajdujesz te i inne kwiatki. Pewnie b�dzie tego
>wi�cej.

No w�a�nie. Proponujesz przej�cie z Javy na Clojure, automatycznie
rezygnuj�c ze wsparcia tego, co jest w Javie, i twierdz�c, �e to rozwi�zuje
dotychczasowe bol�czki, gdy� wynikaj� one z obiektowo�ci a nie funkcyjno�ci
j�zyka. A mi si� wydaje, �e istniej�ce rozwi�zania webowe dla Clojure s� w
por�wnaniu z Jav� po prostu niedojrza�e i problem�w framework�w
komponentowych nie rozwi�zuj�, bo w og�le nie dochodz� do tego poziomu
abstrakcji. To jest fajna zabawka, ciekawa poznawczo, zapewne u�yteczna w
programowaniu pewnych algorytm�w, kt�re akurat lepiej pasuj� do paradygmatu
funkcyjnego, ale obawiam si�, �e niespecjalnie nadaj�ca si� do realnych
zastosowaďż˝.

>Mo�e pora postawi� inne pytanie? Jakich funkcji (w sensie byt�w w
>Clojure) Ci potrzeba?

W�a�nie k�opot w tym, �e tym pytaniem zamykasz wszelkie inne mo�liwo�ci.
Tego raczej nie nale�y zamkyka� w samych funkcjach, tak jak nie da�o si� w
samych obiektach. Zauwa�, �e frameworki Javy ewoluuj� od go�ych serwlet�w z
kodem HTML w postaci string�w w stron� widoku coraz bli�szego czystemu
HTML-owi. Bo tak jest wygodniej. A Clojure poszed� w przeciwn� stron�, ka��c
kodowaďż˝ HTML za pomocďż˝ funkcji i tablic.

Pozdrawiam,
Olaf

[Jacek Laskowski]

2012/5/23 Olaf Matyja <ola...@gmail.com>:

> A Clojure poszedł w przeciwną stronę, każąc kodować HTML za pomocą funkcji i tablic.

Proponuję przyjrzeć się ClojureScript, który pozwala na programowanie
w Clojure do budowania aplikacji webowych, w których więcej JavaScript
+ innych goodies dla przeglądarki niż można byłoby sobie tego
wyobrazić. Projekt korzysta z Google Closure to kompilacji kodu
javowego do odpowiednika w JavaScript. Jeszcze nad tym nie siadłem,
ale mam wrażenie, że to rozwiązałoby wiele z Twoich kwestii (w
kontekście aplikacji webowych na pewno!)

[Łukasz Lenart]

W dniu 23 maja 2012 11:42 użytkownik Jacek Laskowski <ja...@japila.pl> napisał:
> Proponuję przyjrzeć się ClojureScript, który pozwala na programowanie
> w Clojure do budowania aplikacji webowych, w których więcej JavaScript
> +  innych goodies dla przeglądarki niż można byłoby sobie tego
> wyobrazić. Projekt korzysta z Google Closure to kompilacji kodu
> javowego do odpowiednika w JavaScript. Jeszcze nad tym nie siadłem,
> ale mam wrażenie, że to rozwiązałoby wiele z Twoich kwestii (w
> kontekście aplikacji webowych na pewno!)

Chyba trochę pomotałeś, ClojureScript kompliluje Clojure do JavaScript
a Google Closure optymalizuje JavaScript


Pozdrawiam
--
Łukasz http://www.lenart.org.pl/
mobile +48 606 323 122, office +27 11 0838747
Warszawa JUG conference - Confitura http://confitura.pl/

[Daniel Janus]

W dniu wtorek, 22 maja 2012 22:39:29 UTC+1 użytkownik Jacek Laskowski napisał:

> Mam pytanie - Próbowałeś wykorzystać Closure do generacji widoków w jakimś
> większym projekcie webowym? Bo o ile podoba mi się idea template-ów opartych
> na funkcjach, to sposób zakodowania tych widoków sprawia chyba, że trudno to
> połączyć z dostarczonym przez grafików HTML-em. Owszem, można go całego
> wczytać w jakiejś funkcji, ale to wszystko, każda próba przerobienia go na
> parametryzowany szablo to już będzie grzebanina w stringach, bo tekst HTML
> nie wywoła chyba funkcji Closure. Mam więc wrażenie, że przeróbkę HTML-a na
> parametryzowany szablon prościej zrobić nawet w JSP, nie mówiąc o JSF, czy
> Wickecie. Ale mam nadzieję, że mnie wyprowadzisz z błędu.

Tutaj, brak odpowiedzi zrzucę to na barki wciąż skromnego
doświadczenia w temacie. Skoro jest zainteresowanie, zaczynam
poszukiwanie odpowiedzi.

 

Jest https://github.com/davidsantiago/tinsel :)

pozdrawiam,

Daniel

[Olaf Matyja]

> Jest https://github.com/davidsantiago/tinsel :)
> pozdrawiam,
> Daniel

O, to ju� jakie� �adniejsze. :-)
Bior� HTML-a i przekszta�caj� go funkcjami, zamiast bra� funkcje i udawa� �e
sďż˝ HTML-em.

Olaf

[Jacek Laskowski]

2012/5/23 Łukasz Lenart <lukasz...@googlemail.com>:

> Chyba trochę pomotałeś, ClojureScript kompliluje Clojure do JavaScript
> a Google Closure optymalizuje JavaScript

Za https://github.com/clojure/clojurescript#readme:

"ClojureScript is a new compiler for Clojure that targets JavaScript.
It is designed to emit JavaScript code which is compatible with the
advanced compilation mode of the Google Closure optimizing compiler."

[Łukasz Lenart]

2012/5/23 Jacek Laskowski <ja...@japila.pl>:

> "ClojureScript is a new compiler for Clojure that targets JavaScript.
> It is designed to emit JavaScript code which is compatible with the
> advanced compilation mode of the Google Closure optimizing compiler."

Dokładnie tak jak napisałem, bo nie jest to "Projekt korzysta z Google
Closure to kompilacji kodu javowego do odpowiednika w JavaScript.", a
za https://developers.google.com/closure/ "The Closure Compiler
compiles JavaScript into compact, high-performance code", bo z twojej
wypowiedzi można odnieś wrażenie, że Google Closure kompiluje Javę do
JavaScript, co nie jest prawdą ;-)

[Jacek Laskowski]

2012/5/24 Łukasz Lenart <lukasz...@googlemail.com>:

> 2012/5/23 Jacek Laskowski <ja...@japila.pl>:
>> "ClojureScript is a new compiler for Clojure that targets JavaScript.
>> It is designed to emit JavaScript code which is compatible with the
>> advanced compilation mode of the Google Closure optimizing compiler."
>
> Dokładnie tak jak napisałem, bo nie jest to "Projekt korzysta z Google
> Closure to kompilacji kodu javowego do odpowiednika w JavaScript.", a
> za https://developers.google.com/closure/ "The Closure Compiler
> compiles JavaScript into compact, high-performance code", bo z twojej
> wypowiedzi można odnieś wrażenie, że Google Closure kompiluje Javę do
> JavaScript, co nie jest prawdą ;-)

Pasuje mi ta wersja. Dzięki.

[Tomek Lipski]

On Wednesday, May 16, 2012 6:15:52 AM UTC+2, Adam Lider wrote:

Nie warto, ani w wersji 2, ani 3, ani zadnej innej opartej na JSF. Wystarczy juz tych JSFowych projektow (jak i GWT).

Bezpieczny i "zgodny z natura" wybor to: Spring MVC + HTML/CSS + JavaScript + (w zaleznosci od tego jak bardzo "rich" ten frontend ma byc) np. jQuery, Backbone.js, ExtJS

Jesli aplikacja ma byc w miare klasyczna, stronicowa ("klikajac link x uzytkownik przechodzi na strone y z lista ...") to spokojnie Javoviec sobie poradzi. Sugeruje podejscie Unobtrusive JS, gdzie zawsze wychodzimy od strony/widoku z czystym HTML/CSSem i dopiero majac funkcjonalnosc zrobiona dodajemy efekty za pomoca jQuery (najlepiej w osobnym pliku bez modifykacji HTMLa). Wcale nie chodzi tutaj o to ze nasza strona bedzie dzialala bez JS wlaczonego w przegladarce u klienta, ale robiac w ten sposob powstania aplikacja dosc czysta i latwa w utrzymaniu. Fajnie tez to podejscie dziala przy wspolpracy z grafikami, ale to troche dluzszy temat.

Jesli natomiast ta aplikacja ma byc w stylu okienkowym ("w okienku x uzytkownik wybiera opcje y i wyswietla sie okienko z") to choc wiele takich frameworkow istnieje (ExtJS) to jednak sugeruje JSowca w teamie.

Warto też rozważyć Vaadina - z jednej strony programuje się szybko (i w Javie/Clojure/Groovym/Scali - server side), z drugiej nie ma takiego muru wysokiego do przeskoczenia jak w JSF - można zrobić optymalny widget po prostu w GWT (czyli z dostępem do API JavaScript). Co jest fajne jeszcze, to wsparcie dla IE6/7 i przy odrobinie doświadczenia - bezbolesna obsługa tych przeglądarek; tylko jak się wrzuci za dużo elementów na ekran - to wiadomo, IE nie wyrabia - ale to problem każdego frameworku, który nie zwraca czystego HTML. A jednocześnie jest to zazwyczaj lepiej zoptymalizowane niż kod wykonywany przez studentów ;-)

Jeśli aplikacja ma być "pod igłę" i co do pixela - da się zrobić w Vaadinie, ale pewnie nakład pracy będzie podobny co w w jakimś HTML5/jQuery/Spring. Na vaadin.com jest lista aplikacji w nim zrobionych.

t