Pojawił się ciekawy problem podczas rozwijania jednej aplikacji.
Otóż: na razie mamy aplikację typu stand-alone. Domena, normalne wejście przez przeglądarkę itp. itd.
Natomiast klient chciałby, aby z aplikacji też można było korzystać także jako z aplikacji na facebookowej (jak np. Mafia Wars ) oraz z aplikacji zagnieżdżonej w społecznościówkach zgodnych z OpenSocial API (jak np. Mafia Wars na MySpace ).
Layouty są gotowe dla obu społecznościowych wersji (niebieskawy dla facebookowej, pomarańczowy dla opensocialowej – mniejsza o to) i logika (dane do layoutów) oraz nawigacja będą praktycznie identyczne z wersją stand-alone.
Zatem: jak ugryźć temat wspólnej aplikacji z różnymi layoutami?
Hej, jak widzę jesteśmy w podobnej sytuacji. Co wyczarowałeś?
Mnie najbardziej przeraża perspektywa testowania tego to to gadżetu OpenSocial z culerity. Na razie staram się coś wymodzić przy pomocy lokalnego Apache Shindig – myślisz że to dobry pomysł?
w routach map.namespace(:opensocial)
i tam wybrane kontrolery. Dzięki temu mamy totalną (i na poziomie filesystemu/katalogów) separację widoków, przestrzeń nazw dla kontrolerów (dzięki czemu standardowo robiąc Opensocial::ItemsController < ItemsController można nadpisywać sobie tylko metody, w których nadpisanie jest faktycznie potrzebne, tudzież po prostu opakować odziedziczone metody w jakieś fajne filtry).
W tym momencie bazowy URL do wszystkich żądań (do którego potem doklejamy gdzie dokładnie chcemy iść) to oczywiście http://aplikacja/opensocial/
Co do testowania, to faktycznie dramat. Lokalny Shindig i Celerity to jest całkiem niezły pomysł, Drogomir będzie coś kombinował z BlueRidge / Screw.Unit. Na razie pokrycie testami frontendu pod opensocial mamy zerowe
BTW, czasami mam wrażenie że 3/4 programistów Ruby w Polsce pracuje w ten lub inny sposób dla pewnego niemieckiego molocha
Co do Screw.Unit, to chyba jednak może być ciężko - strasznie dużo trzeba by mockować, a w javascripcie jest z tym trochę gorzej niż w ruby. Ale jeszcze nie miałem czasu, żeby cokolwiek sprawdzić w praktyce, więc do ciężko stwierdzić co z tego wyjdzie.
W kwestii podpięcia tego pod selenium lub celerity, znalazłem jeszcze coś takiego: http://github.com/yssk22/webjourney/ - to może być łatwiejsze do podpięcia niż “goły” shinding.
Bo chyba tak jest, głębszy kryzys gospodarczy w niemczech może posłać wszystkich pod most - wyobrazacie sobie tych wszystkich programistow z macbookami mieszkajacych pod mostem w kartonowych pudełkach?
A co by za bardzo nie offtopować:
A czemu do tego frontendu nie użyć selenium?
Do samego frontendu w aplikacji można użyć selenium, można użyć webrata, można użyć celerity. Kłopot w tym, że działanie frontendu bez containera, to połowa sukcesu - co z tego, że to będzie super chodzić u Ciebie na kompie jak się pokrzaczy i nie załaduje w containerze. A scenariuszy dublować się chyba nie bardzo opłaca.
Dzisiaj będę próbował tego shindiga postawić, zobaczymy co z tego wyjdzie.
Ja się poddałem - poprawiłem trochę rake tasków, postawiłem niby shindig i couchdb apps, ale cały czas rzuca jakimiś 404 i innymi “internal server error”. Teraz czas na kolejną opcję.
Wygląda na aktywnie rozwijany i jest wyczerpujący tutorial: http://www.chabotc.com/guides/shindig_and_partuza_on_mac/ - co prawda dla maca, ale pod linuxem raczej nie powinno być problemów (a jak wyjdzie w praktyce jeszcze napiszę).
Oo, przynosisz dobrą nowinę ;). Z chęcia jutro się pobawię… Samego Apache Shindig nie udało mi się zmusić do pracy ani w wersji PHPowej ani Javovej – na obu miałem dziwne errory związane niby z moim XMLem gadgetów…
Oo, przynosisz dobrą nowinę ;). Z chęcia jutro się pobawię… Samego Apache Shindig nie udało mi się zmusić do pracy ani w wersji PHPowej ani Javovej – na obu miałem dziwne errory związane niby z moim XMLem gadgetów…[/quote]
Ja testowałem na początku te dostępne w sieci - sudoku i todo app na przykład. Co do shindiga, to ja instalowałem z svn trunka, wersja php.
Podpiąłem to pod cucumbera + selenium, na razie mogę powiedzieć tylko, że działa, nie zdążyłem się tym pobawić więcej niż sprawdzenie czy wczytuje się content gadgetu.
Drogomir nie tylko zmusił do działania Parduza (z Shindigiem oczywiście) i napisał do tego wygodne howto (oraz raketaski), ale jeszcze skonfigurował aplikację “backendową” (ta która trzyma dane, renderuje widoki dla gadżetu itd.) uruchamioną na hoście lokalnym i pokrycie testami cucumber+selenium. Działa jak marzenie. Mistrzostwo!
Dał się namówić na notkę na bloga z kodem i całym howto, to będzie naprawdę “coś”
Pierwsze jest do przeskoczenia, nie ma tu nic co było by jakoś szczególnie skomplikowane… Mi się wydaje że jednak jest to dobry pomysł – szczególnie fajnie działają klasy które emulują Ajaxa. W teorii dało by się napisać jeden zestaw widoków i jeden zestaw Javascriptu który będzie działał i via opensocial i normalnie, podmieniając tylko jquery-opensocial na normalną jquery kiedy trzeba. Co dokładniej miałeś na myśli?
Ciężko mi to sobie wyobrazić Ale jak będziesz miał czas i chęci, to chętnie zobaczę jakiś proof of concept, choćby bardzo prototypowy. Może rzeczywiście coś fajnego z tego wyjdzie.
Tylko ja jestem trochę przeczulony na takie unifikacje. Mam ze sobą ten problem, że z reguły wszystko staram się sprowadzić do jednego prostego przypadku. W programowaniu to bardzo fajna opcja, bo można zrobić fajne i elastyczne rozwiązanie, ale w praktyce często wychodzi na to, że dużo efektywniej jest być odrobinę mniej DRY. W tym wypadku wolę chyba jednak się powtórzyć w kilku miejscach.
) oraz z aplikacji zagnieżdżonej w społecznościówkach zgodnych z OpenSocial API (jak np. Mafia Wars na MySpace 
