Spring i 'p' namespace
Hamster
daje nowy Spring 2.0.
http://blog.interface21.com/main/2006/11/25/xml-syntax-sugar-in-spring-20/
Jak dla mnie to bardzo przydatna rzecz. Dodatkowo ostatnie SpringIDE ma
wsparcie dla tego typu notacji.
http://springide.org/project/wiki/SpringsPNamespace
Pozdr,
spn
Jakis czas temu wlasnie czytalem o 'p' namespace i mam takie mieszane
uczucia. Moze to kwestia przyzwyczajenia. Przed chwila jeszcze raz
popatrzylem i znow jakos sie nie przekonalem;) A sa jeszcze jakies inne
plusy oprocz tego, ze:
- rozwiazanie to redukuje wielkosc pliku xmlowego
- mamy mozliwosc wprowadzenia kolejnego bajeru do naszej kolejnej
aplikacji, co powoduje podziw kolegow;)
Aloha
Hamster
[..]
> plusy oprocz tego, ze:
> - rozwiazanie to redukuje wielkosc pliku xmlowego
$ find . -iname "*.xml" | grep src | grep resources | xargs wc -c
..
23434 41062 1095533 total
> - mamy mozliwosc wprowadzenia kolejnego bajeru do naszej kolejnej
> aplikacji, co powoduje podziw kolegow;)
No a to jest wazna sprawa ;] hie hie
mari...@gmail.com
już takie zdobycze jak adnotacje. Mozna by wtedy zrobic @SpringBean
czy cos takiego i nie musiec zarzadac setkami plikow xml, i
synchronizowac je z klasami javy...
On 24 Sty, 09:11, "Hamster" <hamsterre...@gmail.com> wrote:
> On Jan 23, 7:21 pm, "spn" <sawic...@gmail.com> wrote:
> [..]> plusy oprocz tego, ze:
> > - rozwiazanie to redukuje wielkosc pliku xmlowegoNo to jest spory plus IMHO, mam aplikacje gdzie same xmle to:
> $ find . -iname "*.xml" | grep src | grep resources | xargs wc -c
> ..
> 23434 41062 1095533 total
>
> > - mamy mozliwosc wprowadzenia kolejnego bajeru do naszej kolejnej
> > aplikacji, co powoduje podziw kolegow;)No a to jest wazna sprawa ;] hie hie
mb
> już takie zdobycze jak adnotacje. Mozna by wtedy zrobic @SpringBean
> czy cos takiego i nie musiec zarzadac setkami plikow xml, i
> synchronizowac je z klasami javy...
Springa. Tzn jedną z idei jest jak najmniejsza inwazyjność w pisany
kod biznesowy.
Pisząc beany niezależne od Springa możesz je wykorzystywać w innych
miejscach, bez konieczności jakichkolwiek zmian.
A tak w ogóle to witam! :)
Hamster
> > Generalnie to nie rozumiem, po co tyle kodować w tym xml, skoro mamy
> > już takie zdobycze jak adnotacje. Mozna by wtedy zrobic @SpringBean
> > czy cos takiego i nie musiec zarzadac setkami plikow xml, i
> Springa. Tzn jedną z idei jest jak najmniejsza inwazyjność w pisany
> kod biznesowy.
> Pisząc beany niezależne od Springa możesz je wykorzystywać w innych
> miejscach, bez konieczności jakichkolwiek zmian.
> A tak w ogóle to witam! :)
Adnotacje powoduja to ze mamy problem ze zdefiniowaniem tego samego
beana wielokrotnie.
Da sie to obejsc ale jakos malo eleganckie sie to wowczas wydaje. A o
elegancje w Spring glownie
chodzi (IMHO).
pzdr,
lsaw666
z glowa, ale poki co nie podoba mi sie mieszanie takich tworow z kodem
javowym. Ja rozumiem, ze jest latwiej np. utrzymac spojnosc kodu i
mapowania hibernate, ale z drugiej strony wydaje mi sie to jakos malo
czytelne. Juz nie mowiac o innych tworach powstalych z ich
wykorzystaniem;)...no ale moze ja jakis betonowy jestem;)
Piotr Maj
On 29 Sty, 09:04, "lsaw666" <sawic...@gmail.com> wrote:
> javowym. Ja rozumiem, ze jest latwiej np. utrzymac spojnosc kodu i
> mapowania hibernate, ale z drugiej strony wydaje mi sie to jakos malo
> czytelne. Juz nie mowiac o innych tworach powstalych z ich
> wykorzystaniem;)...no ale moze ja jakis betonowy jestem;)
Miałem podobne podejście w czasach XDocleta, ale wiązało się to z tym,
że Xdoclet nie był interpretowany w locie tylko wymagał wygenerowania
dodatkowego kodu. Adnotacje nie mają już tej wady i są w zasadzie
bezbolesne. Odbiegnę od tematu grupy, ale spróbuj sobie napisać kilka
EJB3 używając adnotacji, a potem zrób to samo używając deskryptorów
XML. Myślę, że zmienisz zdanie. ;)
Co zaś się tyczy niezależności obiektów od kontenera to zapytam
przewrotnie: ile razy zdarzyło Wam się w poważnym komercyjnym
projekcie zmieniać używany szkielet aplikacji? Czasem cena za taką
niezależność jest zbyt wysoka.
--
pozdrawiam
piotr maj
Paweł Rozynek
> przewrotnie: ile razy zdarzyło Wam się w poważnym komercyjnym
> projekcie zmieniać używany szkielet aplikacji? Czasem cena za taką
> niezależność jest zbyt wysoka.
Zmiana szkieletu to jedno spojrzenie na sprawe, mniej wazne. W moim
mniemaniu glowna zaleta jest mozliwosc uzycia tych samych beanow w
innym projekcie skonfigurowanych na nowo, bez koniecznosci ich
powtornego pisania.
PS. Mam wrazenie, ze w tym watku poruszono co najmniej kilka tematow
na raz, kazdy mysli, ze on jest o czym innym i bedzie duzy flame :)
PR
Mariusz Smykula
z definiowaniem molocha w xmlu calkiem duze. Oczywiscie w pewnych
specyficznych zastosowaniach moze to byc bardzo uzyteczne, jednakze w
wiekszosci przypadkow ludzie wybierajacy Springa nie zamierzaja za
chwile przesiadac sie na cos zupelnie innego. Komfort programowania
najwazniejszy, czekam wiec na odpowiedniki @Springowych beanow :)
Mam takie ogolne odczucie, ze to co w springu bylo calkiem niedawno
rewolucja, obecnie juz nia przestaje byc... wystarczy popatrzec na
rozwiazania w JEE, a najlepiej np. na Seama. Czlowiek sie zastanawia
po co komu ten XML ;)
--
Best regards,
Mariusz Smykuła
+48 663 592 307
smerf
On 29 Sty, 10:21, "Paweł Rozynek" <pro...@gmail.com> wrote:
> > Co zaś się tyczy niezależności obiektów od kontenera to zapytam
> > przewrotnie: ile razy zdarzyło Wam się w poważnym komercyjnym
> > projekcie zmieniać używany szkielet aplikacji? Czasem cena za taką
> > niezależność jest zbyt wysoka.Zmiana szkieletu to jedno spojrzenie na sprawe, mniej wazne. W moim
> mniemaniu glowna zaleta jest mozliwosc uzycia tych samych beanow w
> innym projekcie skonfigurowanych na nowo, bez koniecznosci ich
> powtornego pisania.
>
Czy to jest akurad dużą zaleta?? Ja bym się nie zgadzał zabardzo z tym
stwierdzeniem, jeśli bierzemy pod uwagę, ilość takich wykorzystań w
komercyjnych projektach.
Logoka bizesowa jest dość zmienna a zarazem nie zawsze podobne
zachowania występują u innego klienta. No chyba, że dla tego samego
piszemy drugą apikację to wtedy można wykoszystać.
Moim zdanie jest wiele plusów i te małe, które jak już ktoś pisał są
żadkościa w komercyjnych projektach. Ale największym, bynajmniej
kiedys, była letkość springa, łatwość pisania logiki itp.
Marcin Zduniak
projektach wynika tylko z niewlasciwego ich zaprojektowania, a nie z
trudnosci wykorzystywania takich komponentow sama w sobie.
M.
On 29/01/07, smerf <sme...@gmail.com> wrote:
> Czy to jest akurad dużą zaleta?? Ja bym się nie zgadzał zabardzo z tym
> stwierdzeniem, jeśli bierzemy pod uwagę, ilość takich wykorzystań w
> komercyjnych projektach.
> Logoka bizesowa jest dość zmienna a zarazem nie zawsze podobne
> zachowania występują u innego klienta. No chyba, że dla tego samego
> piszemy drugą apikację to wtedy można wykoszystać.
--
Marcin Zduniak mar...@zduniak.com
+ 48 600 27 88 66 http://www.zduniak.com
Paweł Rozynek
> stwierdzeniem, jeśli bierzemy pod uwagę, ilość takich wykorzystań w
> komercyjnych projektach.
> Logoka bizesowa jest dość zmienna a zarazem nie zawsze podobne
> zachowania występują u innego klienta. No chyba, że dla tego samego
> piszemy drugą apikację to wtedy można wykoszystać.
Nie chodzi o logike, a o np pooling, nakladanie aopa, transakcje,
eleganckie klasy do rozszerzania *DaoSupport itp. Kod ktory ZAWSZE
musialby byc napisany na nowo jest elegancko wtlaczany w aplikacje.
Pozatym latwa podmiana implementacji interfejsow tez ma niebagatelne
znaczenie (m.in. testowanie z DummyVeryImportantService, deploy
aplikacji na produkcje w mscu X z WebServiceVeryImportantService, a w
mscu Y z LocalVeryImportantService).
Tak naprawde Springowi przypisuje sie duzo roznych funkcjonalnosci,
ktorych on tak naprawde nie robi. Spring to jest kontener IoC a nie
EJB. A dopoki to jest kontener IoC, to wymaga sie od niego
funkcjonalnosci takiej, jaka taki kontener powinien posiadac. To ze
obrosl w wiele dodatkowych klas, ktore sa wraz znim dostarczana (i sa
uzyteczne), to jest zupelnie inna historia.
Porownywanie Springa do EJB nie ma raczej sensu patrzac na to od tej strony...
Pzdr.
Pawel Rozynek