<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Espeo Software &#187; grails</title>
	<atom:link href="http://www.espeo.pl/tag/grails/feed" rel="self" type="application/rss+xml" />
	<link>http://www.espeo.pl</link>
	<description>Oprogramowanie na zamówienie - aplikacje inter/intranetowe, desktop, mobilne. Wykorzystujemy technologię Java, Java EE, Flex, Grails</description>
	<lastBuildDate>Fri, 11 May 2012 15:11:22 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Firmowe szkolenie z Grails</title>
		<link>http://www.espeo.pl/2012/02/27/firmowe-szkolenie-z-grails</link>
		<comments>http://www.espeo.pl/2012/02/27/firmowe-szkolenie-z-grails#comments</comments>
		<pubDate>Mon, 27 Feb 2012 15:14:49 +0000</pubDate>
		<dc:creator>Krzysztof Konwisarz</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[news]]></category>
		<category><![CDATA[grails]]></category>
		<category><![CDATA[szkolenie]]></category>
		<category><![CDATA[wprowadzenie]]></category>

		<guid isPermaLink="false">http://www.espeo.pl/?p=4529</guid>
		<description><![CDATA[Ostatni wtorek dla części z kolegów z firmy nie był zwykłym wtorkiem. Zamiast, normalnym trybem, uczestniczyć w swoich projektach, wyrwano ich na całodniowe szkolenie z Grails, które miałem przyjemność przeprowadzić. Cel był prosty &#8211; przekazać możliwie dużo wiedzy i doświadczeń z pracy z frameworkiem w czasie ośmiu godzin. Plan: ograniczyć wykład do minimum i przejść do tworzenia kodu jak najszybciej. W końcu to nie studia &#8211; zbyt mała sala, żeby się spokojnie przespać bez wiedzy prowadzącego. Balansowanie pomiędzy tym, o czym powiedzieć na dzień dobry, co zasygnalizować w praniu, a co pozostawić do ewentualnego dopytania z pewnością można poprawić. Ostatecznie chyba i tak zbyt wiele w całości było mojego gadania :) Wystartowaliśmy z Grailsowymi ogólnikami i błyskawicznym wprowadzeniem do Groovy, przeszliśmy przez warstwy frameworka, nie zapominając o większych funkcjonalnościach i udogodnieniach. Trzeba było w końcu pokazać, że tutaj praca z XMLem i JSONem czy technologie takie jak Spring Web Flow są na wyciągnięcie ręki. Wszystko to odbywało się przy tworzeniu małej aplikacji. Napisaliśmy kilka akcji kontrolerów, metod serwisów, tagów, widoków i testów. Na koniec zdążyliśmy jeszcze sprząc ze sobą dwa pluginy, aby otrzymać Quartzowego joba wysyłającego maile (czyli na dobrą sprawę funkcjonalność, którą oferuje osobny plugin). Szkolenie i przygotowanie do niego były też okazją, aby w końcu przetestować nowe Grailsy, obecnie w wersji 2.0.1. Nie był to może pełny sprawdzian bojowy, a jedynie deweloperskie manewry &#8211; tym niemniej, kilka wrażeń jest. Nowe testy wydają się czystsze i nie sprawiały problemów w prostych przykładach. Spockowe drukowanie błędów i znacznie ładniejsze i czytelniejsze raporty także delikatnie plusują. Natomiast nowa konsola i przeładowywanie klas zawodzą w pokładanych w nich nadziejach. W praktyce nie obywa się bez częstych restartów tomcata, a &#8216;rozgrzewanie&#8217; JVM ostatecznie wiele nie daje, gdy i tak trzeba wyjść z konsoli, bo aplikacja działa niestabilnie. Moje wrażenia po szkoleniu były pozytywne, ale nie mnie oceniać ;) Guys?]]></description>
		<wfw:commentRss>http://www.espeo.pl/2012/02/27/firmowe-szkolenie-z-grails/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Open Flash Chart 2 on Grails</title>
		<link>http://www.espeo.pl/2010/09/10/open-flash-chart-2-on-grails</link>
		<comments>http://www.espeo.pl/2010/09/10/open-flash-chart-2-on-grails#comments</comments>
		<pubDate>Fri, 10 Sep 2010 18:40:32 +0000</pubDate>
		<dc:creator>Sylwia Rogowicz</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[english]]></category>
		<category><![CDATA[technologia]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[charts]]></category>
		<category><![CDATA[grails]]></category>
		<category><![CDATA[groovy]]></category>

		<guid isPermaLink="false">http://blog.espeo.pl/?p=343</guid>
		<description><![CDATA[Demand for a new feature for our accounting office management application  appeared recently. Service is made in Grails, so  I started from searching charts plugins for this framework. I could choose between Google Chart plugin, JFreeChart and Open Flash Chart. The last one really took my attention &#8211; you know, nice flash effects possible. I never used Open Flash Charts before and  decided to spend one afternoon and play with it. It was very easy to install and take into use, just by following the short instruction from http://mybytes.wordpress.com/2009/03/09/grails-open-flash-chart-06-is-out It is suggested there to see demo, so I checked out the plugin from svn and watched the samples.  Library gives us many possible charts to present data . I started to prepare 3 test charts using API in Java for Open Flash Chart 2 , same charts I will probably need in my project in the future: Pie chart, Horizontal Bars and more complex one: Bars and Lines presented at one chart. Pie went smoothly  and looked tasty, the most complex chart also, but I was not able to prepare labels for y axis for horizontal bars. It confused me, I found a package with fix called   OFC2Patches-DZ-Ichor.zip on this site http://www.ofc2dz.com/index.html#Examples Hints ( and patches) there are very useful if you have some problems with library. Of course when one problem was solved, the ready made chart &#8211; the more complex one stopped working properly with a new patch for the library. This is code sample for the complex one – 3d bar and line with dots using OFChart library, as you can notice it is easy to use and readable. Everything is fine as long as you are stopped by some more complex feature or bug. Why not to omit this and take advantage of groovy? An swf file gets data that are going to be presented as json data and we have such a groovy2json converter on the board.  Manipulating Lists and Maps we can prepare even the most complicated json file.  I do not need any fixes or patches then. The same example with Lists and Maps below: In both cases chart looks the same of course]]></description>
		<wfw:commentRss>http://www.espeo.pl/2010/09/10/open-flash-chart-2-on-grails/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Groovy/Grails update</title>
		<link>http://www.espeo.pl/2010/08/23/groovy_grails_update</link>
		<comments>http://www.espeo.pl/2010/08/23/groovy_grails_update#comments</comments>
		<pubDate>Mon, 23 Aug 2010 11:39:37 +0000</pubDate>
		<dc:creator>Krzysztof Konwisarz</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[english]]></category>
		<category><![CDATA[news]]></category>
		<category><![CDATA[technologia]]></category>
		<category><![CDATA[grails]]></category>
		<category><![CDATA[groovy]]></category>

		<guid isPermaLink="false">http://blog.espeo.pl/?p=301</guid>
		<description><![CDATA[Groovy and Grails releases in the last months appear so often that it is really easy to miss them. Starting with Groovy: it&#8217;s current version is 1.7.4, and the maintenance updates from this branch bring little more than bugfixes, so the below list contains mainly the changes introduced in 1.7.0: anonymous inner classes – for Java compatibility nested static classes – functionality exists, but it is best to use static nested classes if any added annotations on imports, packages and variable declarations – this allows for instance to declare dependencies with Grape within your code more readable asserts output with Power Asserts AST Viewer and AST Builder to facilitate the use of AST transformations Groovy Truth expanded – every class now can customize the way it is evaluated to boolean by implementing its asBoolean() method batch updates using sql.witchBatch() and sql.withTransaction() numerous improvements in testing, collection methods, GroovyScriptEngine, Groovy console and other More on this, especially the exact behavior and limitation of nested classes in Groovy 1.7.0 Release Notes. &#160; Unlike in Goovy, in each of Grails 1.3.x branch releases new features are implemented. Its current version (1.3.4) uses Spring 3.0.3. With 1.3.0 and the following quite a few changes were made: GORM: dirty checking for domain classes with .isDirty() and .isDirty(&#8216;fieldName&#8217;) methods Hibernate derived properties – domain class property value can be now calculated from a formula; here is a nice post on derived properties themselves. named queries can be combined – nested within another named query, chained one by one or made more specific by supplying additional conditions when invoked .find() and .findAll() query results can now be cached GSPs: default layout – if defined, it will be used by all pages that do not explicitly declare to use one &#60;g:join&#62; tag concatenates strings separating them with a specified delimiter &#60;g:unless&#62; tag is a handier version of negated &#60;g:if&#62; filters the order in which filters are executed can be specified testing: upgraded to JUnit 4 TagLib testing allows to test custom tags that use the pageScope property plugins classes, views and templates provided by plugins can be overridden inline plugins don&#8217;t have to be plugin-packaged before use dependency management: you can specify plugin repositories you want to use in BuildConfig.groovy publishing plugins on Maven compatible repositories declaring plugin dependencies with the IvyDSL every-day use: script name typo detection in command line when creating artifacts suffixes like *Controller, *Service are now added only when user hasn&#8217;t supplied one multiple HTTP proxy configuration grails doc –-pdf exports generated documentation to PDF and –-init generates a documentation template Grails release notes for more details: http://www.grails.org/1.3 Release Notes http://www.grails.org/1.3.1 Release Notes http://www.grails.org/1.3.2 Release Notes http://www.grails.org/1.3.4 Release Notes &#160; As for IDEs – having used Netbeans and Spring Tools Suite lately I must say, that the latter is a long awaited improvement in Groovy/Grails free IDE support. There is still a lot to be done, but at the moment syntax highlighting works quite well, code completions gives some hints without making you wait for ages, and even refactoring works sometimes ;). &#160;]]></description>
		<wfw:commentRss>http://www.espeo.pl/2010/08/23/groovy_grails_update/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Integracja Grails z Flex</title>
		<link>http://www.espeo.pl/2008/10/08/integracja-grails-z-flex</link>
		<comments>http://www.espeo.pl/2008/10/08/integracja-grails-z-flex#comments</comments>
		<pubDate>Wed, 08 Oct 2008 16:18:39 +0000</pubDate>
		<dc:creator>Michal Kalinowski</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[technologia]]></category>
		<category><![CDATA[blazeds]]></category>
		<category><![CDATA[flex]]></category>
		<category><![CDATA[grails]]></category>

		<guid isPermaLink="false">http://espeo.wordpress.com/?p=13</guid>
		<description><![CDATA[Ci, którzy śledzą &#8220;życie&#8221; technologii Grails, prawdopodobnie zauważyli kształtujący się od pewnego czasu trend wykorzystania tandemu Grails oraz Flex do budowy systemów internetowych. Nie jest to póki co trend dominujący w świecie Grails i prawdopodobnie nim nie będzie. Z całą pewnością jednak jest dość ciekawym pomysłem na wytwarzanie RIA (ang. Rich Internet Application). Zasadnicza koncepcja jest prosta: użyć Flex jako front-end, Grails jako back-end i zintegrować jedno z drugim. Brzmi łatwo, ale bardziej doświadczeni developerzy (szczególni Ci, zajmujący się systemami rozproszonymi) zapewne dostali właśnie dreszczy, widząc magiczne słowo: &#8220;zintegrować&#8221;. Mam dobrą wiadomość: w tym przypadku integracja obu technologii jest łatwa, szybka i przyjemna. Wydaje mi się, że jest to jedna z głównych przyczyn rosnącej popularności omawianego rozwiązania. Na początek warto zastanowić się po co właściwie nam Grails + Flex. Można przecież zbudować aplikację internetową w Grails od początku do końca, podobnie zresztą jak we Flex. Użycie kombinacji obu technologii ma sens w przypadku, gdy robimy RIA, ale implementację logiki biznesowej chcielibyśmy pozostawić na serwerze, a także, dodatkowo, chcemy to wszystko wykonać w możliwie dobrych technologiach, które całą sprawę nam ułatwią, a nie utrudnią i zapewnią, przy okazji, realizację kilku wymagań niefunkcjonalnych (jak choćby duża przenośność), na których na pewno nam zależy. Grails + Flex = dokładnie to. Flex jest świetną technologią, która oferuje nam pełną potęgę graficzną Flash&#8217;a, ale w formie przyjaznej programiście (a nie grafikowi). Grails natomiast pozwala wykorzystać w całości moc platformy Java EE (czyli również jej bogactwo bibliotek, framework&#8217;ów oraz innych narzędzi), czyniąc jednak programowanie łatwiejszym i szybszym dzięki takim cechom jak choćby zasady DRY (Don’t Repeat Yourself &#8211; Nie powtarzaj się) i Convention Over Configuration (Konwencja ponad konfigurację), język programowania Groovy czy technologie Spring i Hibernate podane &#8220;na tacy&#8221;, bez żadnego dodatkowego wkładu pracy w konfigurację itp. Więcej na ten temat przeczytać można we wcześniejszym wpisie Pawła. Teraz czas na właściwą integrację. Po stronie Grails nie musimy właściwie nic robić, bo wszystko załatwia jeden plug-in. Wystarczy go zainstalować, wydając z konsoli (w katalogu głównym projektu Grails) polecenie: grails install-plugin flex oraz dodać w klasie usługowej (ang. service), która implementuje logikę biznesową, którą chcemy udostępnić aplikacji Flex, jedno pole statyczne: static expose = ['flex-remoting'] i to wszystko! Usługa będzie od teraz udostępniona. Powiedzmy, że wygląda ona tak: class HelloService { static expose = ['flex-remoting'] def hello() { return "Hello World!" } } W aplikacji Flex wystarczy powołać obiekt RemoteObject: &#60;mx:RemoteObject id="myService" destination="helloService"/&#62; by móc korzystać z naszej usługi. Przykładowa aplikacja może wyglądać tak: &#60;?xml version="1.0" encoding="utf-8"?&#62; &#60;mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"&#62; &#60;mx:RemoteObject id="myService" destination="helloService"/&#62; &#60;mx:Button label="Hello" click="myService.hello()"/&#62; &#60;mx:TextInput text="{myService.hello.lastResult}"/&#62; &#60;/mx:Application&#62; Nic dodać, nic ująć. Zero konfiguracji. To po prostu działa&#8230; i już! Ale właściwie&#8230; jak to działa? Otóż nie ma tu żadnej &#8220;magii&#8221;, wbrew temu co widać na pierwszy rzut oka. &#8220;Pod maską&#8221; siedzi magiczny komponent BlazeDS i odrobina Convention Over Configuration. BlazeDS jest technologią serwerową, która obsługuje styk Grails &#60;=&#62; Flex (a tak naprawdę to Java &#60;=&#62; ActionScript) poprzez implementację mechanizmu RPC, tak jak to pokazano wyżej. Przez &#8220;obsługuje&#8221; rozumiem wszystko, co jest potrzebne do zdalnego wywołania metody logiki biznesowej: udostępnienie usługi w sieci (pod konkretnym URL), ustalenie protokołu komunikacyjnego ponad warstwą HTTP oraz zapewnienie konwersji typów między światem Java, a światem ActionScript. Część &#8220;magii&#8221;, jak sądzę, została już wyjaśniona. Idźmy dalej. Przenieśmy naszą aplikację Flex do osobnego projektu, czyli rozdzielmy całość na projekt Grails i projekt Flex. Okaże się, że nagle wszystko przestało działać, co zresztą nie dziwi, bo niby skąd aplikacja Flex ma mieć pojęcie co zrobić z: &#60;mx:RemoteObject id="myService" destination="helloService"/&#62; skoro nie wie gdzie jest helloService (przypominam, że aplikacja Grails jest już osobnym projektem). Oto rozwiązanie: uruchamiamy naszą aplikację Grails poleceniem: grails run-app i (zakładając, że aplikacja jest dostępna pod adresem http://localhost:8080/hello) modyfikujemy powyższą definicję obiektu RemoteObject: &#60;mx:RemoteObject id="myService" destination="helloService" endpoint="http://localhost:8080/hello/messagebroker/amf"/&#62; Mamy URL, pod którym udostępnione są nasze obiekty usługowe, i mamy &#8220;magika&#8221; łączącego świat typów Java ze światem typów ActionScript, którym są biblioteki BlazeDS. Dodam tylko (żeby nie pozostawić żadnych wątpliwości), że protokołem komunikacyjnym nad warstwą HTTP jest AMF (ang. ActionScript Message Format), którym &#8220;rozmawiają&#8221; aplikacja Flex (wykonująca zdalne wywołanie metody) i BlazeDS (uruchamiający na żądanie metody logiki biznesowej i zwracający ich rezultat).]]></description>
		<wfw:commentRss>http://www.espeo.pl/2008/10/08/integracja-grails-z-flex/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
	</channel>
</rss>

