Jeśli chodzi o mnie, chciałbym zobaczyć proste przykłady:
- krótki wstęp (co to jest, jakie daje możliwości, itp.)
- jak to skonfigurować,
- jak z tego korzystać (prosty przykład CRUD),
- a jak wystarczy czasu to wtedy jakieś bardziej zaawansowane tematy.
Generalnie fajnie by było, żeby ludzie, którzy nie korzystają z AMF (a
powinni), wiedzieli jak zacząć i ew. gdzie dalej szukać informacji.
kamiseq: jeżeli nie wyrobisz się w jednej prezentacji, możemy to
podzielić na więcej wystąpień (podczas kolejnych spotkań grupy).
pozdrawiam,
On 25 Kwi, 12:21, kamiseq <kami...@gmail.com> wrote:
Ja bym sie skłaniał na te bardziej zaawansowane tematy :)
Przede wszystkim kwestia jaką technologię chcesz opisywac, amfphp,
weborba czy jeszcze cos inszego, moze jakies krótkie porownanie ?
-> przykład mapowania klas bo z tego co widze to mało ludzi z tego
korzysta a to połowa radochy z amfa.
-> autoryzacja, role, na 1.2 lub beta 1.9 ale w 1.9 to troche insza
bajka, bo tam wchodza w gre filtry
-> moze roznice amf0-amf3 ? To raczej podpada pod protokół, ale czy są
jakieś istotne dla usera ( chociaz chyba nie ma ;) )
-> przykład na remoteobject we flexie pod 1.9 lub jesli sie da ( a nie
probowałem ) 1.2 i amf0
On 25 Kwi, 13:25, Krzysztof Satola <krzysz...@satola.net> wrote:
> Jeśli chodzi o mnie, chciałbym zobaczyć proste przykłady:
> - krótki wstęp (co to jest, jakie daje możliwości, itp.)
> - jak to skonfigurować,
> - jak z tego korzystać (prosty przykład CRUD),
> - a jak wystarczy czasu to wtedy jakieś bardziej zaawansowane tematy.
> Generalnie fajnie by było, żeby ludzie, którzy nie korzystają z AMF (a
> powinni), wiedzieli jak zacząć i ew. gdzie dalej szukać informacji.
> kamiseq: jeżeli nie wyrobisz się w jednej prezentacji, możemy to
> podzielić na więcej wystąpień (podczas kolejnych spotkań grupy).
> pozdrawiam,
> On 25 Kwi, 12:21, kamiseq <kami...@gmail.com> wrote:
> > idac w slady Rafała chcialbym sie dowiedizec czego oczekujecie po
> > prezentacji opisujacej protokol AMF.
> Ja bym sie skłaniał na te bardziej zaawansowane tematy :) > Przede wszystkim kwestia jaką technologię chcesz opisywac, amfphp, > weborba czy jeszcze cos inszego, moze jakies krótkie porownanie ?
> -> przykład mapowania klas bo z tego co widze to mało ludzi z tego > korzysta a to połowa radochy z amfa. > -> autoryzacja, role, na 1.2 lub beta 1.9 ale w 1.9 to troche insza > bajka, bo tam wchodza w gre filtry > -> moze roznice amf0-amf3 ? To raczej podpada pod protokół, ale czy są > jakieś istotne dla usera ( chociaz chyba nie ma ;) ) > -> przykład na remoteobject we flexie pod 1.9 lub jesli sie da ( a nie > probowałem ) 1.2 i amf0
> On 25 Kwi, 13:25, Krzysztof Satola <krzysz...@satola.net> wrote: > > Jeśli chodzi o mnie, chciałbym zobaczyć proste przykłady: > > - krótki wstęp (co to jest, jakie daje możliwości, itp.) > > - jak to skonfigurować, > > - jak z tego korzystać (prosty przykład CRUD), > > - a jak wystarczy czasu to wtedy jakieś bardziej zaawansowane tematy.
> > Generalnie fajnie by było, żeby ludzie, którzy nie korzystają z AMF (a > > powinni), wiedzieli jak zacząć i ew. gdzie dalej szukać informacji.
> > kamiseq: jeżeli nie wyrobisz się w jednej prezentacji, możemy to > > podzielić na więcej wystąpień (podczas kolejnych spotkań grupy).
> > pozdrawiam,
> > On 25 Kwi, 12:21, kamiseq <kami...@gmail.com> wrote:
> > > idac w slady Rafała chcialbym sie dowiedizec czego oczekujecie po > > > prezentacji opisujacej protokol AMF.
Można odpowiedzieć na pytanie "Dlaczego AMF?" np. w porównianiu z Web
Services.
Dlaczego bawić się w jakiś dziwny protokół a nie skorzystać ze
standardu, który mamy często zaimplementowany na serwerze za darmo -
stworzenie endpointa Web Services dla komponentu EJB to zwykle ze 3
kliknięcia i nie wymaga instalowania czegokolwiek.
Tutaj proponuję pokazać jakieś wyniki konkretnie. Ostanio tworzyłem
takie porównanie i np. dla 20 000 rekordów wykonanie metody przez WS
trwało 38s (!!) a koperta miała ponad 11 mega, a dla AMF wywołanie
trwało 1,7s i wiadomość miała 7 mega. Dodam, że wykonanie WS z soapUI
bez deserializacji trwało 5,7s . Myślę, że tego typu dane są w stanie
przekonać każdego.
> -> przykład mapowania klas bo z tego co widze to mało ludzi z tego
> korzysta a to połowa radochy z amfa.
I w ogóle powód i zasadność stosowania mapowania klas.
> -> autoryzacja, role, na 1.2 lub beta 1.9 ale w 1.9 to troche insza
> bajka, bo tam wchodza w gre filtry
> -> moze roznice amf0-amf3 ? To raczej podpada pod protokół, ale czy są
> jakieś istotne dla usera ( chociaz chyba nie ma ;) )
Są, głównie w wydajności. Amf3 ma lepsze metody optymalizacji rozmiaru
wiadomości. Głównie odwołania przez referencje i variable length
encoding dla liczb.
> -> przykład na remoteobject we flexie pod 1.9 lub jesli sie da ( a nie
> probowałem ) 1.2 i amf0
peper, jesli chcesz porownac wydajnosc, to nie wiem czy widziałes ->
http://www.jamesward.org/census/ Zreszta ogole moze warto byłoby to pokazac, choc teraz to moze troche
za pozno ... :) uups
>> I w ogóle powód i zasadność stosowania mapowania klas.
> > -> przykład mapowania klas bo z tego co widze to mało ludzi z tego
> > korzysta a to połowa radochy z amfa.
> I w ogóle powód i zasadność stosowania mapowania klas.
> > -> autoryzacja, role, na 1.2 lub beta 1.9 ale w 1.9 to troche insza
> > bajka, bo tam wchodza w gre filtry
> > -> moze roznice amf0-amf3 ? To raczej podpada pod protokół, ale czy są
> > jakieś istotne dla usera ( chociaz chyba nie ma ;) )
> Są, głównie w wydajności. Amf3 ma lepsze metody optymalizacji rozmiaru
> wiadomości. Głównie odwołania przez referencje i variable length
> encoding dla liczb.
> > -> przykład na remoteobject we flexie pod 1.9 lub jesli sie da ( a nie
> > probowałem ) 1.2 i amf0
> peper, jesli chcesz porownac wydajnosc, to nie wiem czy widziałes -> > http://www.jamesward.org/census/ > Zreszta ogole moze warto byłoby to pokazac, choc teraz to moze troche > za pozno ... :) uups
> >> I w ogóle powód i zasadność stosowania mapowania klas.
> Hmm, znaczy jestes na nie, czy na tak ? :)
> >>Da się na amf0 ale to się mija z celem.
> Dlaczego ? Zmienia się coś poza protokołem ?
> Ł
> On 1 Maj, 15:15, peper <pep...@gmail.com> wrote: > > > -> przykład mapowania klas bo z tego co widze to mało ludzi z tego > > > korzysta a to połowa radochy z amfa.
> > I w ogóle powód i zasadność stosowania mapowania klas.
> > > -> autoryzacja, role, na 1.2 lub beta 1.9 ale w 1.9 to troche insza > > > bajka, bo tam wchodza w gre filtry > > > -> moze roznice amf0-amf3 ? To raczej podpada pod protokół, ale czy są > > > jakieś istotne dla usera ( chociaz chyba nie ma ;) )
> > Są, głównie w wydajności. Amf3 ma lepsze metody optymalizacji rozmiaru > > wiadomości. Głównie odwołania przez referencje i variable length > > encoding dla liczb.
> > > -> przykład na remoteobject we flexie pod 1.9 lub jesli sie da ( a nie > > > probowałem ) 1.2 i amf0
On 10 Maj, 13:01, Łukasz Błachowicz <moo...@gmail.com> wrote:
> peper, jesli chcesz porownac wydajnosc, to nie wiem czy widziałes ->http://www.jamesward.org/census/ > Zreszta ogole moze warto byłoby to pokazac, choc teraz to moze troche
> za pozno ... :) uups
Tak, znam to.
> >> I w ogóle powód i zasadność stosowania mapowania klas.
> Hmm, znaczy jestes na nie, czy na tak ? :)
No nie zawsze ma to w ogóle sens. Kiedy używam gdzieś pomiędzy 150 a
170 różnych obiektów danych (z grubsza tyle ma baza) to najwygodniej
jest jak we Flexie maksymalnie dużo jest geneorwane "w locie".
Mapowanie klas @Entity na Flexowe jest fajne, bo można robić coś w
stylu
public void saveUser(User usr) {
entityManager.merge(usr);
}
natomiast łamie to zasady bezpieczeństwa i dobrego projektowania -
powinno się przesyłać proste obiekty (Value Objects) tworzenie
duplikatów klas i "przepisywanie" do nowych obiektów jest takie sobie.
Już szybciej zmapować to tablicy asocjacyjnej.
Istnieją też sytuacje, kiedy użytkownik w zależności od uprawnień
widzi lub nie pewne parametry obiektu. Czasem jest to ustalone dla
ról, wtedy wystarczy przepisać każdą klasę dla każdej roli. 5 ról i 40
klas to tak koło 200 klas - nie jest źle. Czasem natomiast trzeba mieć
możliwość ustalania, które pola są widoczne dla którego poziomu
uprawnień z możliwością dodawania nowych ról i uprawnień a wtedy w
ogóle nie widzę miejsca na mapowanie klas.
Pomijam już tak oczywisty problem, że w gridzie wystarczą 4 pola
obiektu, który możę ich mieć kilkanaście. Po co przesyłać całość?
Użytkownik może sobie chcieć zaznaczyć, które pola chce oglądać w
gridzie.
Oczywiście rozwiązaniem powyższych problemów jest przesyłanie zawsze
takiego samego obiektu, w którym 3/4 pól ma wartosć null. Jaki to
jednak daje wymierny zysk?
> >>Da się na amf0 ale to się mija z celem.
> Dlaczego ? Zmienia się coś poza protokołem ?
Z tego co pamiętam nie da się użyć zwykłego RemoteObject, tylko trzeba
to robić "niskopoziomowo". Ale mogę się mylić.
Z tego co pamiętam nie da się użyć zwykłego RemoteObject, tylko trzeba
to robić "niskopoziomowo". Ale mogę się mylić.
Niskopoziomowo owszem, bo sam korzystałem, netconnection i call, nic
ciekawego, ale wlasnie kwestia tego czy mozna skorzystac z
remoteobject majac po serwerze amf0
Z mapowaniem fakt faktem masz rację, są miejsca i momenty kiedy mija
się to z celem, ale sama idea zła nie jest ;)
Ł
On 12 Maj, 09:10, peper <pep...@gmail.com> wrote:
> On 10 Maj, 13:01, Łukasz Błachowicz <moo...@gmail.com> wrote:
> > peper, jesli chcesz porownac wydajnosc, to nie wiem czy widziałes ->http://www.jamesward.org/census/ > > Zreszta ogole moze warto byłoby to pokazac, choc teraz to moze troche
> > za pozno ... :) uups
> Tak, znam to.
> > >> I w ogóle powód i zasadność stosowania mapowania klas.
> > Hmm, znaczy jestes na nie, czy na tak ? :)
> No nie zawsze ma to w ogóle sens. Kiedy używam gdzieś pomiędzy 150 a
> 170 różnych obiektów danych (z grubsza tyle ma baza) to najwygodniej
> jest jak we Flexie maksymalnie dużo jest geneorwane "w locie".
> Mapowanie klas @Entity na Flexowe jest fajne, bo można robić coś w
> stylu
> public void saveUser(User usr) {
> entityManager.merge(usr);
> }
> natomiast łamie to zasady bezpieczeństwa i dobrego projektowania -
> powinno się przesyłać proste obiekty (Value Objects) tworzenie
> duplikatów klas i "przepisywanie" do nowych obiektów jest takie sobie.
> Już szybciej zmapować to tablicy asocjacyjnej.
> Istnieją też sytuacje, kiedy użytkownik w zależności od uprawnień
> widzi lub nie pewne parametry obiektu. Czasem jest to ustalone dla
> ról, wtedy wystarczy przepisać każdą klasę dla każdej roli. 5 ról i 40
> klas to tak koło 200 klas - nie jest źle. Czasem natomiast trzeba mieć
> możliwość ustalania, które pola są widoczne dla którego poziomu
> uprawnień z możliwością dodawania nowych ról i uprawnień a wtedy w
> ogóle nie widzę miejsca na mapowanie klas.
> Pomijam już tak oczywisty problem, że w gridzie wystarczą 4 pola
> obiektu, który możę ich mieć kilkanaście. Po co przesyłać całość?
> Użytkownik może sobie chcieć zaznaczyć, które pola chce oglądać w
> gridzie.
> Oczywiście rozwiązaniem powyższych problemów jest przesyłanie zawsze
> takiego samego obiektu, w którym 3/4 pól ma wartosć null. Jaki to
> jednak daje wymierny zysk?
> > >>Da się na amf0 ale to się mija z celem.
> > Dlaczego ? Zmienia się coś poza protokołem ?
> Z tego co pamiętam nie da się użyć zwykłego RemoteObject, tylko trzeba
> to robić "niskopoziomowo". Ale mogę się mylić.
