Thursday, May 28, 2009

Welcome to AK Layout Tests


Welcome to the site. The content of the last post will appear on the home page. Add a picture, a few intro words, do whatever to tell about yourself. Below is a picture that will make prospective users warm and cozy.



1stcommunionJulia25



Now, tell the people that they'll need to check out your other blog sections, subscribe, whatever sles.

Wednesday, May 27, 2009

A dream come true

Koi Fish 48 36"/48"



Since I was very little I had a dream of painting with oil paint. My parents didn't allow me because we lived in a very small apartment and there wasn't enough space even for an easel and my mom was terrified of the smell. When I was applying for the art high school back in Bulgaria, you had to have a health clearance from a health practitioner that you don't have any allergies, otherwise you just can't get in. There was no way I could go around that but we tried and the principle agreed that, they would accept my application but on one condition - I am not doing any oil paint. It was devastating. That's all I wanted to do! I couldn't find a place to do it- not at home, not at school... Well it so turned out that they've moved the art high school and I couldn't travel, so I finished my first year there and I had to move in another school. It was unbelievable experience and I was really sad when I had to leave. But why am I telling you this? Remember the " 30 things to do before going 30" that I told you about around my last birthday? Well,I made my list and painting an oil painting almost as high as me ( 5'2") is one of my 30 things. My husband gave me the surprise of a lifetime, when he bought me a beautiful, gorgeous easel for Mother's day as well as a 36"/48" canvas piece. I just love Koi fish and I've been meaning to paint some for quite a while. You know, my mom and her Feng shui has definitely rubbed on me :-)



My first oil painting 36"/48"



I am officially addicted! I couldn't stop! Literally! The same day (did I mention I was sick at the time) I started a second painting- beautiful lilacs that I am going to show you later. I so much appreciate what my husband did! This is a real dream come true!!! Thank you so much, honey!!! I love you!!!

Carina's Birthday


A quick green card for Carina. I just love the combination of green and pink.





Carina's B'day card





Since I made a woodburned box for Carina's sister- Julia( for her 1st Communion) , I thought that it would be great if I make one for Carina as well





Carina's box





Carina's pendant was a glass swirl that we all liked.


Carina's box&present





She really liked it and I was so glad I had the time to make her one. Here is the present for Julia, a Jonas Brothers poster ;-)


Julia's poster





And little Briannah's present with a cute little card :-)


Briannah's present

Julia's 1st Communion gifts


You probably saw my 1st communion cake by now, so here is the addition- the gifts for the girls. This was a personal gift from Kalin, who really likes Julia :-)





1stcommunionJulia8





Julia's 1st communion present from Kalin





He chose the heart pendant that is in the box. Julia's favorite color is purple. Julia's 1st communion present from Kalin





This is the bouquet for Julia's mom





1stcommunionJulia34





I wasn't sure I want to use this kind of paper for the flowers, the white one I mean, but it turned out I couldn't find any other kind in the store at that time.


1stcommunionJulia32





My pictures are a little dark, but this is only because it was 2 am :-)





Julia's 1st communion present from Kalin





This is Julia's card for the present we gave her:


1stcommunionJulia7





1stcommunionJulia2





Carina's card





1stcommunionJulia3





And finally you can see how I wrapped the presents for both girls:


1stcommunionJulia4





I hope I've helped you with some ideas :-)

Twins birthday gifts


More woodburning for you guys! It turned out these little boxes are quite popular! :-) So I decided to make 2 more for 2 of Kalin's classmates.





Grace's box





And the second one:





Kate's Box





Top view





Kate's Box





The presents were escorted by 2 birthday cards made by me :-)





Kate &Grace's cards





I hope the girls liked them! :-)

Friday, May 22, 2009

Raztegatelnost

Raztegatelnost



I have been so busy this month and I have a ton of stuff to post here,
but time...time is my problem :-)
I am almost finished with the new website/blog design and soon you will
see how things are going to change, but I don't want to spoil the surprise,
so I am not going to say more.



1stcommunionJulia25



So, what else is new you would ask?
Well, I made a 1st communion cake as a gift this week. It was for Julia,
the daughter of a very good friend of mine . You probably remember that I
made one 1st communion cake last year as well. It was for Julia's older sister-
Carina.
I had a hard time deciding what should I do for Julia's cake.
At first I had an idea about lace gloves, but then I started thinking about
handkerchief..and I asked my friend if she has one as a keepsake from her mom
( Julia's grandmother). It turns out she had one!It was just perfect!!!
Then I started thinking about the flowers, my friend's name is Rose, so I
figured roses would be appropriate, and the girl's favorite color is
light-purple-violetish, so it was decided.



1stcommunionJulia19



But, there was one small problem-I have never made gum paste or gum paste
flowers in my life, so I had to prepare at least a week in advance to make
sure everything will go smooth.
And I started with the gum paste recipe of Scott Clark Woolley.
Then I remembered I had seen a very beautiful cake that Louise from Cakejournal.com
made and she shared some tips on how to make gum paste roses.
She had posted a link to the tutorial on how to make gum paste roses
of a very talented cake designer Fran McGregor. The link is in the 23rd
post after the picture and you'll have to download it.

The Cake


As I mentioned in the previous post, I have made a 1st communion
cake for a friend of mine's daughter.
The cake was with 5 chocolate layers and caramel-coconut cream.
I've brushed the layers with caramel-brandy sauce and I have to tell
you the taste was unbelievable! The cake was so moist and creamy and
the candied walnuts gave it a little bit of crunch. Very interesting combination, I'll definitely make it again.



1stcommunionJulia198


Only the candle is real, everything else is edible.
The flowers are completely edible ( except the flower wire) too,
the handkerchief is a replica of one that the girl's grandmother left for her.
If you want to read more about it, check out my previous post.

Wednesday, May 13, 2009

RAD w/ Tapestry 5, NetBeans 6.7, Maven, and Jetty : Really !!!

One of the major upsides of using Tapestry 5 is the much touted live class and template reloading. Up until recently, if you followed my previous post on working with Tapestry 5 and NetBeans, you probably ended w/ a workable solution, but still not ideal , as the live template and class reloading wasn't exactly working as expected. As a result, whenever you wanted to see the changes that you made in the live app (after running mvn jetty:run) you had to do the following:


mvn compile resources:resources
.........
-----------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 18 seconds
[INFO] Finished at: Wed May 13 03:16:32 EDT 2009
[INFO] Final Memory: 16M/71M





The issue here was that NetBeans (in 6.1 and prior) did not support CopyOnSave or CompileOnSave properly in Maven projects (it did for NetBeans native projects, so if you had set up a NetBeans native project w/ explicit jar dependencies, etc it would work fine). The effect of running the above command was to compile your changes, and copy the compiled classes and modified resources into your <outputDirectory> (typically target/classes) . So, the 18 seconds above are not exactly something to lose sleep over, but it's still not the same like having the immediate Grails(or Rails)-like immediate feedback loop (that is, "Ctrl-S->Alt-Tab to browser->F5", which is "Save->Switch to Browser->Refresh").

In any case, help is on the way.




In the most recent version of NetBeans (in the 6.7 daily builds ), the issues w/ CopyOnSave support has been fixed (well, almost fixed, see the NetBeans IssuZilla issue), and now it transparently copies your modified resource files to target/[app-name]/WEB-INF/classes. Thus, with just a minor tweak, you can accomplish a Tapestry 5 Nirvana.



  1. First, set up a new Maven project by File->New Project->Select Maven project type. Follow my previous instructions on creating the actual project. Just a side note, for some reason the latest production T5 version (5.1) doesn't show up on the list of available archetypes in NetBeans.


  2. Running the app is easy, the default project comes w/ the Jetty plugin set up, so you can just run "mvn jetty:run" on the console.


  3. Alternatively, map a custom Maven goal in NetBeans by right clicking on the project, going to Custom-Goals and mapping jetty:run . See the screenshots for some extra help







  4. The default project setup comes with an Index page living in the web app context. Now that you ran Jetty, you should be able to just make changes to the template, and see them immediately. The secret here is that Jetty runs by default out of src/main/webapp, so T5 picks up the changes out of the box, no additional support by the IDE is needed.

    The problem here is that if you tried making changes to your page class (e.g. Index.java), they're not being picked up. Jetty runs from the classes in target/classes. The idea here is that we want to IDE to autocompile the changes, drop them into target/classes and have T5 pick up the new page classes. As mentioned at the beginning of the post, if you just ran the maven build again (e.g. mvn compiler:compile), but we need something better.

    OK, so, go to the project properties, go to the Build-Compile section. In the panel, select from the "Compile on Save" (COS) dropdown the "for both application and test execution".




    The trick to remember here is that this only works for "supported servers" (e.g. I know that at least Tomcat and Glassfish are in that list) where the IDE would compile the new classes, and re-deploy them on the server. Jetty is not one of these supported servers, and in order for the Compile-on-save goodness to work, the IDE needs to know you ran the app so that it can activate COS. Now, although you probably don't want to run the app in Tomcat , go ahead and run the app, select to run it in Tomcat. Now that you ran the app in Tomcat, NetBeans activated COS for this app, and now if you make new changes to your Index.java, NetBeans copies out the compiled classes to target/classes, and Jetty picks up the changes. After you run the app, you can just stop Tomcat (and the COS feature will continue working).



  5. This is pretty close to perfect. Trouble is, if you have any page templates under src/main/resources, you're still out of luck, as the resources don't get copied out into target/classes after you do the initial jetty:run. But don't despair, there is just one more step that will get us there.



  6. Add the following to your pom.xml


    <outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF/classes</outputDirectory>








Now, this is a bit of a hack. Basically, we're telling maven to use the target/[app-name]/WEB-INF/classes to do the initial and any subsequent builds, which is where both the classes from src/main (and whereever else) and src/main/resources end up. The trick here is that this is the same directory that "mvn package" uses, and it is also the same directory that NetBeans uses for the Compile-on-save functionality. Basically, when you make changes to your page template sin src/main/resources (and after you've run your app in Tomcat once), NetBeans continues to compile the classes and copy the modified resources from src/main/resources and drop them into the target/[app-name]/WEB-INF/classes.




Considering that this is indeed a a hack, I filed a patch for NetBeans to properly support this T5 setup in Maven project. However, what got into 6.7 is only the fix to properly copy resources into target/[app-name]/WEB-INF/classes (and not in target/classes). The develoeper on the issue has some other ideas on how this should go, hopefully the full fix will go into the NetBeans version after 6.7. In the meantime, either use this little hack, or I'll probably try to repackage my fix as a standalone plugin to support this out of the box.

Tuesday, May 5, 2009

Converting legacy Rails apps to Grails : The Views

Alrighty, we're getting close to the finish line here. So far, we've covered General Project Setup, Migrating the Domain, Migrating the Controllers, and now we'll talk about migrating the views. After that, if I have a little bit of life left in me, I'll briefly speak about replacing the existing plugins in the Rails app w/ equivalent Grails plugin, and that should be the end of this series.

Now, on to the content.

  1. General Setup

  2. Layouts

  3. Page-by-page migration

  4. Tags

  5. Conclusion






1. General Setup





As you're probably used to it by now, the Grails and the Rails app have very similar approaches to storing views and templates. As you can see on the screenshots, the Rails views are in the "Views" project node, whereas in the Grails project, they're located in the "View and Layouts" project node. Inside of this folder, the views are partitioned by controller, e.g. the views and templates for controller "FooController" in the Grails app, sit inside of the view/foo subfolder.



2. Layouts

Another interesting folder in both Rails and Grails is the Layouts folder (in Grails, Views and Layouts - layouts project folder). There, the projects store the differet project layouts. The general idea here is mostly the same: different parts of the app will have different layout needs. Migrating the layouts from Rails to Grails involves mostly tag-for-tag conversion of the rhtml to gsp. A couple of useful facts about that process.

1. As mentioned in the previous post, both frameworks have a reasonable set of defaults for the layout selection. I can't quite remember all the details about how Rails chooses its defaults, but the converted application mostly specified on a per-controller basis by specifying the element, e.g. :


class FooController
layout "internal"
end

This Rails snippet will use the views/layouts/internal.rhtml layout.

There is no direct equivalent for specifying the desired layout inside of a controller in Grails. Instead, a user can add a layout with the same name as the controller (e.g. layouts/foo.gsp for FooController). Although I don't recall this being used in the Rails app, Grails also provides the ability to specify a template to use for rendering a view by specifying a <meta name="layout" content="landing"></meta>. Rendering a view that specifies the layout in this way will use the view/layouts/internal.gsp layout.

2. Converting the Rails layouts
The Rails layouts that I worked with used the following statements in the <head> element:



<head>
<%= stylesheet_link_merged :base %>
<%= stylesheet_link_merged :print, 'media' => 'print' %>

<%= javascript_include_merged :base %>
<%= javascript_include_merged :application %>
</head>


I can't quite say I know what all of the above statements do. I inspected the output the actual HTML output and replaced it with the following in my Grails template:


<head>
<link rel="shortcut icon" href="${createLinkTo(dir:'images',file:'favicon.ico')}" type="image/x-icon" />
<link rel="stylesheet" href="${createLinkTo(dir:'stylesheets/active_scaffold',file:'stylesheet.css')}" media="screen" type="text/css" />
<link href="${createLinkTo(dir:'stylesheets',file:'styles.css')}" media="screen" rel="Stylesheet" type="text/css" />
<link href="${createLinkTo(dir:'stylesheets',file:'print.css')}" media="print" rel="Stylesheet" type="text/css" />
<link href="${createLinkTo(dir:'stylesheets/active_scaffold/default',file:'stylesheet.css')}" media="screen" rel="Stylesheet" type="text/css" />
<!--[if IE]>
<link href="${createLinkTo(dir:'stylesheets/active_scaffold/default',file:'stylesheet-ie.css')}" media="screen" rel="Stylesheet" type="text/css" />
<![endif]-->
<g:layoutHead />
<g:javascript library="application" />
<g:javascript library="prototype" />
<g:javascript library="scriptaculous" />
</head>


A couple of things to note here :
* Using the ${createLinkTo()} tag inside of the stylesheet links : it is very convenient and makes the generation of the links pretty foolproof.
* Using the <g:layoutHead /> statement : allows the inclusion of any elements from the <head> element of the "client" page (the page that is using the layout).

Inside of the body of the template, the Rails template use the <%= yield%> statement to include the body of the client page. The equivalent statement in the Grails layout is the <g:layoutBody>

Finally, Rails allows client views to contribute "additional" content into the final output. In other words, the template can define an "area" where the client template can contribute markup, in a way that the said markup shows up in the parts of the layout that are generally rendered by the template. For example, if the client pages need to contribute markup to the content of the "sidebar", then, the layout would use something like the following:

<% if !@content_for_sidebar.nil? %>
<div id="right_sidebar_content_main">
<%= yield(:sidebar) %>
</div>
<% end %>


The client template, contributes to the layout as follows:

<% content_for :sidebar do%>
<div> This content will show up under the 'right_sidear_content_main' section in the final output </div>
<% end %>


In Grails, in order to implement the same feature, we have to resort to a less used and somewhat obscure feature of the underlying templating system that Grails users : Sitemesh. Here's the equivalent in the Grails project:

<g:if test="${pageProperty(name:'page.sidebar')!=null && pageProperty(name:'page.sidebar')!=''}">
<div id="right_sidebar_content_main">
<g:pageProperty name="page.sidebar" />
</div>
</g:if>


Now, in the "client" page, add content to the sidebar as follows:

<content tag="sidebar">
<g:render template="course_notes_side_bar" />
</content>

There is some additional info on using this feature in the Grails docs' for pageProperty tag, but more so in the Sitemesh user docs and just random blogs


3. Page-by-page migration
There is in most cases a 1-1 relationship between the views in both frameworks. Converting from the Rails views to the Grails views was mostly mechanical : see the Rails tag, find the equivalent Grails tag, and then figure out how to map the Rails tag attributes to the Grails tag attributes. In most cases, the two are similar enough and the conversion is fairly easy. At other times, Rails did provide some more features not present in Grails and migrating the pages did require some level of thought and effort. Even in that case, even for the tags that don't have a Grails equivalent, after the first couple of tags the conversion is always the same. Here's an example of an easy conversion:

In Rails:

<%= link_to_remote "Upload File",
{:url => { :controller => 'activity_items', :action => 'show_upload_form', :activity_id => @act_id},
:before => "Element.show('show_upload_form')" ,
:success => "Element.hide('show_upload_form');",
:update => { :success => "upload_form", :failure => "upload_form_errors" }},
{:class => "action", :title =>"Add a new file."} %>


In Grails:

<g:remoteLink controller='activityItems' action='show_upload_form'
params="[act_id:act_id]"
before="Element.show('show_upload_form')"
onSuccess="Element.hide('show_upload_form')"
update="[success:'upload_form', failure:'upload_form_errors']"
class="action" title="Add a new file"> Upload File </g:remoteLink>



Here's another one.

Rails:

<%= form_remote_tag :url => {:action => 'update',:controller => "activities", :id => @activity.id},
:before => "Element.show('form-indicator-activities')" ,
:success => "Element.hide('form-indicator-activities')" %>


Grails:

<g:formRemote url="[action:'update', controller:'activities', id:activity.id]" name="editActivityForm"
before="Element.show('form-indicator-activities')"
onSuccess="Element.hide('form-indicator-activities')">



I found that because the Rails app assumed to be deployed at the root of the context (e.g. http://localhost:3000/), whereas the Grails app always assumes that it will be deployed to a non-root context path (e.g. /foo), in many cases I found myself replacing static image references with links created with ${createLinkTo()}

FROM:
<img src="/images/indicator.gif" id='addurl' style='display:none;' />


TO:
<img src="${createLinkTo(dir:"images",file:"indicator.gif")}" id='addurl' style='display:none;' />




Here's an example of a Rails tag that didn't have a direct equivalent in Grails.

Rails:

<%= text_field_with_auto_complete(:course, :title, {:class=>"SearchTextBox", :value => " type here, then hit enter", :onclick=>"this.value=(this.value == ' type here, then hit enter')?'':this.value;", :onblur => "this.value=(this.value == '')?' type here, then hit enter':this.value;"}, completion_options = {}) %>


In Grails, I created a template that contained the same html + javascript that the Rails tag produced:

<%-- The content below was migrated from the Rails app, could be improved if using a plugin providing a cleaner autocompletion setup --%>
Search

<style type="text/css">
div.auto_complete {
width: 350px;
background: #fff;
}
div.auto_complete ul {
border:1px solid #888;
margin:0;
padding:0;
width:100%;
list-style-type:none;
}
div.auto_complete ul li {
margin:0;
padding:3px;
}
div.auto_complete ul li.selected {
background-color: #ffb;
}
div.auto_complete ul strong.highlight {
color: #800;
margin:0;
padding:0;
}
</style>
<input autocomplete="off" class="SearchTextBox" id="course_title" name="course.title" onblur="this.value=(this.value == '')?' type here, then hit enter':this.value;" onclick="this.value=(this.value == ' type here, then hit enter')?'':this.value;" size="30" value=" type here, then hit enter" type="text">

<div style="position: absolute; left: 1275px; top: 161px; width: 230px; display: none;" class="auto_complete" id="course_title_auto_complete">
</div>


<script type="text/javascript">
//<![CDATA[
var course_title_auto_completer = new Ajax.Autocompleter('course_title', 'course_title_auto_complete', "${createLink(controller:'courses', action:'auto_complete_for_course_title')}", {})
//]]>
</script>


Finally, Rails definitely has some more advanced scaffolding features that Grails didn't support out of the box or did not have a direct equivalent. Similarly to the example above, I just used the html that the scaffold generated, stuffed that into a separate template and used that.

Rails:

<%= render :active_scaffold => "notes", :constraints => {:user_id => current_user.id, :course_id => @course.id} %>


In Grails, this became a standalone template (_notes_scaffold.gsp), which initially contained the static HTML generated by Rails, which I then rigged to support dynamically generate the needed markup (e.g. loop, etc). In the end, the call to the scaffold code above, becomes the following:

<g:render template="/notes/notes_scaffold" model="[notes:UserNote.findAllByUserAndCourse(user?:current_user(),course)]" />


4. Helpers and Tags
In a couple of instances, the Rails app depended on the "helpers" - seemingly a collection o methods that are available to be executed either from the view or contoller. I ended up encapsulating some of these common operations into taglibs, so that the usage of the said tags in grails is as follows:

Rails (a sample Helper located in the Helpers project node):




require 'bluecloth'
module ApplicationHelper
include TagsHelper
def link_to_button(label)
"<table cellpadding=0 cellspacing=0 class=button_action_link><tr><td align=right style=\"background: url('/images/left_button_curve.gif') no-repeat; width: 8px; height: 23px;\"></td><td nowarp=\"nowrap\" style=\"background: url('/images/center_button_bg.gif') repeat;\"> #{label} </td><td style=\"background: url('/images/right_button_curve.gif') no-repeat; width: 29px; height: 23px;\"></td></tr></table>"
end
end





In Grails, it becomes the following:
class CosTagLib {

def linkToButton = { attrs ->
out << "<table cellpadding=0 cellspacing=0 class=button_action_link><tr><td align=right style=\"background: url('${createLinkTo(dir:"images",file:"left_button_curve.gif")}') no-repeat; width: 8px; height: 23px;\"></td><td nowarp=\"nowrap\" style=\"background: url('${createLinkTo(dir:"images",file:"center_button_bg.gif")}') repeat;\"> ${attrs.label} </td><td style=\"background: url('${createLinkTo(dir:"images",file:"right_button_curve.gif")}') no-repeat; width: 29px; height: 23px;\"></td></tr></table>"
}
}


An alternative to adding common helper functionality in tag libraries is to add the same methods as public methods on the superclass. For example, the parent controller contains the following closure:

def current_user = {
if (this.currentUser==null && session.user) {
this.currentUser = User.get(session.user.id)
}
println "Returning currentUser ${currentUser} "
return currentUser;
}


Then, in GSPs, one can use the closure as follows:




5. Conclusion

It's interesting that the migration of views/templates is probably the least complicated part of migrating a Rails app to Grails. Yet, at the same time, together w/ migrating the controllers it was possibly the most time consuming task. Understandably, these artifacts represent ARE the web application. While there probably isn't a good way to automatically convert the controller code, the view code is much more amenable to such an automated conversion, tag-for-tag.

For a lot of these repetitive tasks of converting the app UI tag by tag ( I didn't spend the time to create an auto-converter), I ended up creating a couple of NetBeans live templates that give me parameter and code completion of attributes, jumping between different params, etc.

Converting legacy Rails apps to Grails : The Controllers

So, you've already looked at the previous blog posts on Setting up the Project and Migrating the Domain Objects. The whole world must be wondering "What happened to this blog post series, did people just stop migrating from Rails to Grails?". Well, I've been in Tapestry land for the last 6-7 months and haven't had much free time to finish my blogging endeavor to finish my series of articles. But, what do you know : all of a sudden the topic of migrating legacy Rails apps to Grails came back to the fore for me (work related, don't ask, it's top secret), and here I am. In a valiant effort, I will try to finish off the topic in one fell swoop (hopefully today) and bang out a couple of different articles that document in details the ups and downs of such a migration.

Because this article is on the long side, here is the Table of Contents:

  1. Overview of Controllers

  2. General language related issues.

  3. Input Processing

  4. Input Validation and Error Reporting

  5. Rendering Responses

  6. Advanced Ajaxiness : Dynamic Javascript

  7. Conclusion




1. Overview of controllers






Now, back to the meat and potatoes of this article : migrating the Rails controllers to Grails. It's no secret that Grails heavily borrowed ideas from Rails (and NO, Grails is not Groovy on Rails, there's no mass transit involved at all, it's the good ole cup that everyone wants) and as can be seen from the screenshot of the project setup, both framework keep the controllers in the Controllers NetBeans project folder. Creating Grails controllers is easy: just right click on the Controllers project folder and select "New Controller". NetBeans walks you through naming the Controller properly and creates the needed file and run the regular Grails "create-controller" task, which in creates a default view for the controller.






The structure of the controllers themselves is very similar as well : in both cases, there is a one-to-one relationship between the Rails and Grails controllers. Inside the controller, in both cases, there is a class containing a bunch of closures , methods, and private member variables. In both cases, the closures in the controller become a part of the "public api" exposed by the controller, as all closures can be called from the URL (e.g. http://localhost:8080/app/controllerName/closure -> http://localhost:8080/app/account/login). Private methods are not accessible to be invoked from the URL. For "old school" Java developers who might not be intimately familiar w/ Rails or Grails, it is interesting to note that the controllers are thread safe : that is, they can contain instance variables that will not be clobbered if two concurrent requests are sent to the same controller. A new controller instance is created for each Http request.

OK, let's see what's inside the controller. Here's an example Rails controller:


class ActivityItemsController < ApplicationController
def create
@activity_item = ActivityItem.new(params[:activity_item])
if @activity_item.save
// do whatever
else
// do whatever else
end
end
end


Converting this same controller to Grails would look like this:

class ActivityItemsController extends ApplicationController {
def activity_item;

def create = {
this.activity_item = new ActivityItem(params.activity_item)
if (activity.save()) {
// do whatever
} else {
// do whatever else
}
}
}



2. General language related issues.

A lot of things to talk about here. First of all, just looking at the code it looks almost the same. The first superficial difference is the naming convention for the classes : in Rails user underscore_separated_file_names, whereas Groovy uses CamelCase. One notable difference is that in Grails, you do need to declare the class members, whereas in Rails (due to Ruby heritage), the properties can directly be assigned to when needed (e.g. @activity_item = ....). While the Ruby approach does save one line of code to declare the property, while migrating the code I found it very helpful to see the declarations at the top of the Groovy class. When you don't declare the class members upfront, it seems that it's quite easy to create a whole bunch of properties in the Ruby class w/o realizing how many you've created, which generally can lead to muddying the interface (mind you, the said properties are publicly accessible - e.g. from views, other closures, methods, etc).

3. Input processing
The second thing to note is the existence of the "params" map in both cases. In both cases, one can both read from and write to the params map using the accepted syntax : map[:key] in Ruby and map.key or map[key] in Groovy. So, nothing particularly interesting here. A bunch of other default objects are available in the Grails controller (probably quite familiar to Java Devs) such as servletContext, session, request, params, flash. Dealing with all is mostly the same in both frameworks and should be familiar to anyone done anything on the web.

When processing input, in a number of places, Rails uses the following shortcut/idiom to bulk update the values of many attributes of an object from request parameters at once:

class Foo

def bar
@activity.update_attributes(params[:activity])
end
end

To cut the long story short, this take in the value of request parameters and binds them to values in the object (note, this has severe security implications but that's a different topic to discuss). Grails offers an equivalent statement with:

class Foo {
def activity

def bar = {
bindData(activity,params.activity)
}

}

If using the straight out bindData method from Grails it accomplishes the same thing, with the same security implications. Whenever I actually bumped into examples like this, I tried to address some of the security issues by using the "more advanced" bindData method in Grails, which allows specifying parameters to exclude and a prefix of a property to use for binding, e.g. if I only wanted to bind the customer.name and customer.phone attributes from the request and I definitely wanted to prevent the customer.id attribute being affected, I'd use something like this:

bindData(myCustomerObject,params,["id"], "customer")



4. Input Validation and Error Reporting
In both framework, a large part of validating the input that is written to the domain model is done by specifying constraints in the domain model itself (e.g. see the article about the Rails->Grails domain migration). Thus, in both frameworks, code like this is pretty common:

if @activity.save
// do whatever on success
else
flash[:error]= @activity.errors.full_messages.join("
")
end


In Grails, the code looks very similar:

if (activity.save()) {
// do whatever on success
} else {
flash.error = activity.errors
}


One minor difference here is that (at least in this app), the Rails just concatenated the error messages as text and placed them in the "error" property in flash scope. In contrast, Grails assigns the actual "errors" object to the same flash property, then allowing the view to render these error objects as it wishes (e.g. using the g:renderErrors tag), which would allow rendering an error for a particular property, etc.

In both frameworks, validation of can happen in the controller itself, and errors can be added to the relevant error property (in the appropriate scope).

One more advanced feature of Grails that I found very useful later on in the conversion are the Grails are the form beans that you can use to populate values from the request (thus shielding from the security issues referred to further up), validating the input in a domain-class style approach, and generating errors in a nice and easy manner. So, here's the form object:


public class ChangePasswordForm {
String oldPassword;
String password;
String passwordConfirmation;

static constraints = {
oldPassword(nullable:false,blank:false)
password(nullable:false, blank:false, size:4..40)
passwordConfirmation(nullable:false, blank:false, size:4..40,
validator: { oldPw, chgPwdCmd ->
if (oldPw!=chgPwdCmd.password) {
return "notsame.message"
}
}
)
}
}


You'll note the declarative syntax familiar from domain object validation, it's a beauty !!!

<g:formRemote url="[action:'change_password']" name="ChangePasswordForm"
before="Element.show('form-indicator-pwd')"
onSuccess="Element.hide('form-indicator-pwd')">

</g:formRemote>


Add the following to your grails-app/i18n/messages.properties for custom error messages:

#Custom messages
forms.ChangePasswordForm.passwordConfirmation.notsame.message=Password confirmation not the same as password
wrong.password.message.forms.ChangePasswordForm.password=Old password is wrong, please enter again
forms.ChangePasswordForm.password.blank.message={0} cannot be blank


Finally, using the form in the controller when submitted:

def change_password = { ChangePasswordForm changePasswordForm ->
if (!changePasswordForm.hasErrors()) {
// accessing the values from the form
def pwdValue = changePasswordForm.password
// adding a custom error to the form for an error not enforced in constraints
if (whateverRandomReasonYouWantToRejectAField) {
changePasswordForm.errors.rejectValue("password","wrong.password.message")
}
// do whatever
} else {
// do whatever else
}
}
}




Finally, it seemed like a pretty common idiom in the Rails app to use dynamic javascript (I will talk about that plugin later ) to render errors back to the client:

if (@activity.save)
// do whatever on success
else
flash[:error] = "#{@activity.errors.full_messages.join('
')}"
render :update do |page|
page.replace_html "errors_div", :partial => "common/errors_flash",:layout=>false
// do whatever else to the page
end
end


In essense, this takes the validation errors, renders them using the "errors_flash" template, and replaces the content of the "errors_div" in the page with the rendering result. This approach caused me a lot of grief initially, but after a little bit of work it turned into the following in my Grails app:

if (activity_item.save()) {
// do whatever on success
} else {
js_error(activity_item.errors)
}


Where the js_error method in the controller superclass, looks something like this (using the dynamic javascript plugin that will be discussed later):

def js_error = { errors ->
flash.error = errors
log.debug "Sending errors back to client: ${errors}"
renderJavascript {
update 'errors_div', [text:g.render(template:"/common/errors_flash")]
callFunction "Element.show" , 'errors_div'
}
}


5. Rendering Responses
Converting the response rendering from Rails to Grails was pretty straightforward, here's the Rails example:

def new
render :partial => "new", :layout => false
end


In Grails, this becomes:

def _new = {
render(template:"new")
}


One tricky thing to note here is that because "new" is a Groovy keyword, I could not use the same closure name, NBD. The render controller method is pretty much the best thing since sliced bread and can render a whole bunch of things like regular pages, templates, XML, or JSON. Grails uses a convention that partial pages (templates) are named starting w/ an underscore. Thus, when you do:

render(template:"fooTemplate")

Grails finds the _footemplate.gsp file and renders it (equivalent to the Rails render :partial => "footemplate" which renders _footemplate.rhtml).


One other common idiom in the Rails app was to issue redirects from the controller:

redirect_to :action => 'show', :controller => 'activities', :id=> params[:act_id]


Grails supports this idiom pretty nicely with the redicect controller method with pretty much the same parameters:

redirect(controller:'activities', action:'show', id:params.act_id)



This particular project was using both script-centered and content-centered AJAX, and not much data-centered AJAX, so I didn't get to use JSON or XML rendering much; however, I always found the automatic marshalling to JSON or XML pretty cool:

// Automatic marshalling of XML and JSON
import grails.converters.*

render Book.list(params) as JSON
render Book.get(params.id) as XML




Finally, one cool feature of Rails that I initially missed was the ability to specify the default layout per controller :

class ActivitiesController < ApplicationController
layout "internal"
end

The statement above sets the default layout for this controller in the controller itself. Grails supports specifying the layout either by convention (e.g. grails-app/views/layouts/CONTROLLER.gsp or grails-app/views/layouts/CONTROLLER/ACTION.gsp , effectively equivalent to specifying layout="internal" in the controller) or explicitly in the template by specifying a meta tag (<meta name="layout" content="internal"></meta<) in the template.

6. Advanced Ajaxiness : Dynamic Javascript
I was planning to discuss Rails plugins in a separate article; however, there is one particular Grails plugin that was extremely useful to cover a portion of Rails that Grails doesn't cover out of the box. More specifically, I'm talking about the Rails script centered AJAX w/ dynamic javascript, e.g. :

render :update do |page|
page.replace_html "errors_div", :partial => "common/errors_flash",:layout=>false
page.replace_html "show_activities", :partial=>"show", :layout=>false
end


As explained before, this replaces the content of the "errors_div" in the page w/ the rendered "errors_flash" template (which basically renders the flash errors in a list or something like that), and then replaces the content of the "show_activities" div w/ the content of the partial template.

My initial approach was to change the actual pages to process the response and update the right div w/ the returned content, but it was a big PITA, considering how much the Rails app used this. Finally, after some searching on the net, I found the Dynamic Javascript plugin. It had most of the features I needed to implement this Rails idiom with something like this:


renderJavascript {
update 'errors_div', [text:g.render(template:"/common/errors_flash")]
callFunction "Element.show" , 'errors_div'
update 'show_activities', [text:g.render(template:"show_activities")]
}


Now, in places where I needed to update multiple elements on the page, I ended up using this style of code in the controller itself. However, the majority of the uses were the following:
* Render an error div
* Replace a content div w/ the content of a template
* A combination of the two.

As a result, I moved the following code into the parent class of my controllers:

def js_error = { errors ->
flash.error = errors
log.debug "Sending errors back to client: ${errors}"
renderJavascript {
update 'errors_div', [text:g.render(template:"/common/errors_flash")]
callFunction "Element.show" , 'errors_div'
}
}

def js_render = { replaceDiv,replaceContent ->
renderJavascript {
replace replaceDiv, [text:replaceContent]
}
}

def js_error_and_replace = { errors, replaceDiv,replaceContent ->
flash.error = errors
println "Found errors ${errors}"
renderJavascript {
update 'errors_div', [text:g.render(template:"/common/errors_flash")]
callFunction "Element.show" , 'errors_div'
replace replaceDiv, replaceContent
}
}



Which significantly simplified the code in the actual controllers, e.g. :

if (this.user.authenticate(user.login, changePasswordForm.password)) {
if (this.user.save()) {
flash.notice = "Password Changed"
js_render("change_password", g.render(template:"change_password_form"))
} else {
flash.notice = "Password could not be changed"
js_error(user.errors)
}
} else {
println "Didn't authenticate w/ password"
js_error_and_replace(changePasswordForm.errors,"change_password",[text:g.render(template:"change_password_form")])
}


As mentioned above (and as expected), Grails support redirects pretty nicely. However, Javascript redirects , though not necessarily tricky, still required an extra piece of code to the parent controller:

def js_redirect = { redirectUrl ->
def jsRedirect = "document.location = \'$redirectUrl\'"
renderJavascript {
appendJavascript jsRedirect;
}
}

At which point, the code in the controller is really straightforward:

js_redirect(createLink(controller:'activities', action:'show',id:params.id))


However, one of the use cases involved a form executing in a frame (an upload form that did some status updates in a frame), which depending on the content returned in the frame, needed to redirect the whole browser window whenever the upload was done. In Rails it was handled as such:

responds_to_parent do
render :update do |page|
flash[:notice] = "File Uploaded Sucessfully"
page.redirect_to :action =>'show', :controller=>'activities', :id=>params[:activity_id]
end
end



The code in the parent controller to support this idiom is as follows:

def parent_redirect = { redirectUrl ->
render (text : "<html><body>"+
"<script type='text/javascript' charset='utf-8'>"+
"var loc = document.location;"+
"with(window.parent) {"+
" setTimeout(function() { "+
"window.eval(document.location = \'$redirectUrl\'); loc.replace('about:blank'); "+
"}, 1)"+
"}"+
"</script></body></html>")
}


One final note on the Dynamic Javascript plugin : the plugin that is uploaded on the Grails wiki is version 0.1 . The plugin appears to not be maintained actively; however, the linked author's blog (http://blog.peelmeagrape.net/2007/10/9/dynamic-javascript-plugin-for-grails) has version 0.2 of the plugin. Still, when I was heavily using this plugin, I ran into some issues with it and had to patch it as follows (in plugins/dynamic-javascript-0.2/src/groovy/JavascriptBuilder.groovy , commented out code is the broken part):

private String renderTemplate(Map options)
{
// StringWriter s = new StringWriter()
// GrailsWebRequest webRequest = (GrailsWebRequest)RequestContextHolder.currentRequestAttributes();
// HttpServletResponse response = webRequest.getCurrentResponse();
// def writer = (RoutablePrintWriter)webRequest.getOut()
return controller.g.render(options);
// writer.destination.out.toString();
}


I posted on the author's blog w/ the proposed change, and later on received a notification that he liked the change and that he would incorporate it into the plugin. However, it appears that the plugin on his page is still at version 0.2 and my comment has disappeared from the blog. Oh, well...


Conclusion
It was quite a journey so far. None of the problems in migrating controllers are particularly difficult or mind bending; however, there are just a lot of different issues to deal with if you're starting from scratch. So, now that you have all this good info, START MIGRATING THAT RAILS APP THAT YOU'VE BEEN EYEING, WOULD YA !!???!!!

Popular Posts

Related Posts with Thumbnails