Working through Dierk Königs Groovy In Action, I'm finally to the Closure Currying. This concept was so foreign to me, but so incredibly powerful! In his example, he uses closure currying to implement a logger. I scoffed. Pah, you have log4j, why bother. But the example was so interesting, building up a logger from a configuration; consisting of a format, filter and the line to be logged; and an appender, consisting of the configuration, appender and the line.
Watching them curried together was something like watching Gordon Ramsay put together a juicy steak with rosemary, garlic, olive oil heat and artichokes. I actually felt my mouth water!
But why, I've been looking to implement authorization down to the granularity of a per entity basis. I.e. not just to block users of particular roles from doing an action to something, but to block users from that thing itself. Even a few weeks ago, I had an idea, but I needed one additional piece to complete it.
My Idea (written on a pocket notepad near by bedside table): For security on domain objects, consider binding grails actions to security rules that can incorporate groovy objects in scope. E.g. user, role domain objects their values, etc.... - the rules could be predefined rules or written in Groovy Script.
In essence, the rules could be closures that get the application context passed to them!
Tuesday, August 26, 2008
Monday, August 25, 2008
Grails vs. Ruby On Rails
I've been working on a project over the last several months. I started the project on Ruby on Rails because it showed so much promise as the fast framework that I wanted, so that I could get things done quickly.
Then, the other day, I was chatting with a developer friend of mine named Brandon Franklin. As we were chatting, I mentioned this new project I was doing on RoR. He challenged my technology choice (to the tune of a $5 paypall credit), asserting that I should have gone with Grails instead. I finally won the challenge ($5 is $5 after all) but ended up changing my project base to Grails. I've been pretty happy, overall, but I find myself getting stuck in some rather odd areas, like with plugins and such, just because of the immaturity of the platform.
Here is our discussion highlights...
Brent Fisher
July 24 at 11:09pm
So, I think you do owe me $5, or a corona and a moment with the storm rolling in. ORM is much easier in RoR. Either with an existing db, or a green.Active Record keeps things dry. The 'domain' classes don't have to even mention the columns in the tables, it determines them dynamically at runtime. Active Record reflects on the schema inside the database to configure the classes that wrap tables. In other words, its DRY. In Grails, I've got to go through and name all of the attributes in the DB, and then in the Domain class as well. Grails should just 'assume' attributes named the same as the column names.
Brandon Franklin
July 24 at 11:14pm
Alright, for building on an existing DB, Grails might be inferior to RoR.That said, I still think Grails is a better choice for the vast, vast majority of startups and new applications, which VERY RARELY have existing databases. The many, many advantages of using a JVM-based runtime easily outweigh some minor DB management inconveniences for most applications.I remain unconvinced that ORM is easier with a fresh DB, but I guess we'll have to agree to disagree on that one. You did find "one thing" as I challenged you to, so I'll get you your $5!But you'd be wisest to invest it in a Grails book rather than a Corona. ;)
Brandon Franklin
July 24 at 11:26pm
Wait a minute though, this one thing you said kinda confuses me:In Grails, I've got to go through and name all of the attributes in the DB, and then in the Domain class as well. Grails should just 'assume' attributes named the same as the column names.What are you talking about? You don't have to do that. You just create your domain objects and that's it. You save your object with the .save() command and it creates the columns it needs.Do I need my money back?
Brandon Franklin
July 24 at 11:29pm
For the record, I have never even opened a database configuration AT ANY POINT during my work with Grails, so I definitely don't see where you're coming from with this. To me the underlying persistence should be completely hidden away from me, and that's exactly what Grails does.
Brent Fisher
July 25 at 9:05am
I guess I mispoke there. In a greenfield application, you are right. I only have to define the domain attributes in the domain class and it creates them in the database. In a project like mine with an existing db, I already have them defined in the db, so here is the trouble, and the one point where RoR really excels over Grails. In order for Grails to use my db, I have to define the attributes in the domain classes & I have to define the mapping with hibernate mapping files. That is a ton of work. It isn't DRY. See: http://jasonrudolph.com/blog/2006/06/20/hoisting-grails-to-your-legacy-db/RoR lets me work in my environment with my existing db. I have to define the domain classes, but I don't have to define the attributes in them. Instead, as I said, ActiveRecord determines them from the metadata in the db at run time.I think in this case, I still met the $5 corona challenge, although, I would agree with your assertion that overall, Grails will win out for my next greenfield application. By the way, I did pick up a book at barnes & noble last night, the definitive guide to Grails. I have to admit, I was somewhat disappointed with it. I found just as much or more from the website user guide.But, if you can tell me a rapid way to get over my hump, I would gladly go double or nothing plus a six pack of Corona.
Brandon Franklin
July 25 at 10:44am
Honestly, I think the fastest way to get over the hump is just to play with it. I don't get the sense that Grails is a "learn from a book" type of tech. It's just one of those things that you kinda have to grok, ya know?Now, that said, I think that a mastery of GROOVY will help substantially, so you might check out "Groovy in Action" which is widely accepted as the best Groovy book. (I myself have not read it, I'm only repeating the words of those I trust.)I think you earned your $5 fair and square, and honestly for me, the knowledge is worth the money. After all, I don't want to just be a zealot about a tech: Part of my job is understanding the strengths of the various technologies so I can bring them to bear on a problem. It sounds like RoR is the better choice for exposing existing databases (at least if you want to get there quickly and don't have a lot of additional plans for growth of the application and/or scaling concerns--because I think Grails is still a better bet there) and that's good to know.
Brent Fisher
August 13 at 8:37am
So, I've been playing with it. Guess what it is missing? Server side scripting. RoR has server side scripting to make ajax easy. Grails has it on the roadmap as post 1.0, but doesn't have it in there. Because of this, I'm finding it difficult to introduce the RIA elements into my application that I wished to do.
See this pdf chapter for the richness of the Server Side Scripting that exists in RoR.http://media.pragprog.com/titles/rails2/DepotAjax.pdfI'm wanting server side scripting to have interactive pages. For example, on my admin pages, I like to lock down security, so I have pulled in the JSecurity plugin. It's nice. But I would like a page that makes it easy to manage security by allowing the user to add rights to roles in ajax style. I.e. type into the field, press submit, and watch the permissions list for the role get populated without a page refresh.But all is not lost. According to the Grails roadmap, Server Side Scripting is on the Grails 1.0 roadmap:http://grails.org/RoadmapAdd server-side scripting of client Javascript (javascript DSL) Also, there is a fellow working on a server side plugin:http://blog.peelmeagrape.net/2007/10/9/dynamic-javascript-plugin-for-grails?disqus_reply=1211085#comment-1211085
Brandon Franklin
August 13 at 2:24pm
Hm. But hang on. What about this:http://grails.org/Dynamic%20Javascript%20PluginThat ALSO isn't what you need?
Grails - Dynamic Javascript Plugin
Source: grails.org
Generate javascript from controllers in response to AJAX requests, similar to Rails RJS Templates.Blog entry: http://blog.peelmeagrape.net/2007/10/9/dynamic-javascript-plugin-for-grailsThe plugin: grails-dynamic-javascript-0.1.zipSimple Demo App: dynamic_javascript_demo_0.1.zip
Share
Brandon Franklin
August 13 at 2:25pm
Oh sorry, I think that's the same thing the guy is working on that you linked to!
Brandon Franklin
August 13 at 2:27pm
Brent Fisher
August 13 at 3:13pm
It is getting close, but missing a bit of the spark and maturity that RoR has for it, but I'm gonna experiment more with it tonight and see if I can recreate all the cool ajax server-side java scripts that I had put in to the RoR version of my App.I'll let you know how it goes.
Then, the other day, I was chatting with a developer friend of mine named Brandon Franklin. As we were chatting, I mentioned this new project I was doing on RoR. He challenged my technology choice (to the tune of a $5 paypall credit), asserting that I should have gone with Grails instead. I finally won the challenge ($5 is $5 after all) but ended up changing my project base to Grails. I've been pretty happy, overall, but I find myself getting stuck in some rather odd areas, like with plugins and such, just because of the immaturity of the platform.
Here is our discussion highlights...
Brent Fisher
July 24 at 11:09pm
So, I think you do owe me $5, or a corona and a moment with the storm rolling in. ORM is much easier in RoR. Either with an existing db, or a green.Active Record keeps things dry. The 'domain' classes don't have to even mention the columns in the tables, it determines them dynamically at runtime. Active Record reflects on the schema inside the database to configure the classes that wrap tables. In other words, its DRY. In Grails, I've got to go through and name all of the attributes in the DB, and then in the Domain class as well. Grails should just 'assume' attributes named the same as the column names.
Brandon Franklin
July 24 at 11:14pm
Alright, for building on an existing DB, Grails might be inferior to RoR.That said, I still think Grails is a better choice for the vast, vast majority of startups and new applications, which VERY RARELY have existing databases. The many, many advantages of using a JVM-based runtime easily outweigh some minor DB management inconveniences for most applications.I remain unconvinced that ORM is easier with a fresh DB, but I guess we'll have to agree to disagree on that one. You did find "one thing" as I challenged you to, so I'll get you your $5!But you'd be wisest to invest it in a Grails book rather than a Corona. ;)
Brandon Franklin
July 24 at 11:26pm
Wait a minute though, this one thing you said kinda confuses me:In Grails, I've got to go through and name all of the attributes in the DB, and then in the Domain class as well. Grails should just 'assume' attributes named the same as the column names.What are you talking about? You don't have to do that. You just create your domain objects and that's it. You save your object with the .save() command and it creates the columns it needs.Do I need my money back?
Brandon Franklin
July 24 at 11:29pm
For the record, I have never even opened a database configuration AT ANY POINT during my work with Grails, so I definitely don't see where you're coming from with this. To me the underlying persistence should be completely hidden away from me, and that's exactly what Grails does.
Brent Fisher
July 25 at 9:05am
I guess I mispoke there. In a greenfield application, you are right. I only have to define the domain attributes in the domain class and it creates them in the database. In a project like mine with an existing db, I already have them defined in the db, so here is the trouble, and the one point where RoR really excels over Grails. In order for Grails to use my db, I have to define the attributes in the domain classes & I have to define the mapping with hibernate mapping files. That is a ton of work. It isn't DRY. See: http://jasonrudolph.com/blog/2006/06/20/hoisting-grails-to-your-legacy-db/RoR lets me work in my environment with my existing db. I have to define the domain classes, but I don't have to define the attributes in them. Instead, as I said, ActiveRecord determines them from the metadata in the db at run time.I think in this case, I still met the $5 corona challenge, although, I would agree with your assertion that overall, Grails will win out for my next greenfield application. By the way, I did pick up a book at barnes & noble last night, the definitive guide to Grails. I have to admit, I was somewhat disappointed with it. I found just as much or more from the website user guide.But, if you can tell me a rapid way to get over my hump, I would gladly go double or nothing plus a six pack of Corona.
Brandon Franklin
July 25 at 10:44am
Honestly, I think the fastest way to get over the hump is just to play with it. I don't get the sense that Grails is a "learn from a book" type of tech. It's just one of those things that you kinda have to grok, ya know?Now, that said, I think that a mastery of GROOVY will help substantially, so you might check out "Groovy in Action" which is widely accepted as the best Groovy book. (I myself have not read it, I'm only repeating the words of those I trust.)I think you earned your $5 fair and square, and honestly for me, the knowledge is worth the money. After all, I don't want to just be a zealot about a tech: Part of my job is understanding the strengths of the various technologies so I can bring them to bear on a problem. It sounds like RoR is the better choice for exposing existing databases (at least if you want to get there quickly and don't have a lot of additional plans for growth of the application and/or scaling concerns--because I think Grails is still a better bet there) and that's good to know.
Brent Fisher
August 13 at 8:37am
So, I've been playing with it. Guess what it is missing? Server side scripting. RoR has server side scripting to make ajax easy. Grails has it on the roadmap as post 1.0, but doesn't have it in there. Because of this, I'm finding it difficult to introduce the RIA elements into my application that I wished to do.
See this pdf chapter for the richness of the Server Side Scripting that exists in RoR.http://media.pragprog.com/titles/rails2/DepotAjax.pdfI'm wanting server side scripting to have interactive pages. For example, on my admin pages, I like to lock down security, so I have pulled in the JSecurity plugin. It's nice. But I would like a page that makes it easy to manage security by allowing the user to add rights to roles in ajax style. I.e. type into the field, press submit, and watch the permissions list for the role get populated without a page refresh.But all is not lost. According to the Grails roadmap, Server Side Scripting is on the Grails 1.0 roadmap:http://grails.org/RoadmapAdd server-side scripting of client Javascript (javascript DSL) Also, there is a fellow working on a server side plugin:http://blog.peelmeagrape.net/2007/10/9/dynamic-javascript-plugin-for-grails?disqus_reply=1211085#comment-1211085
Brandon Franklin
August 13 at 2:24pm
Hm. But hang on. What about this:http://grails.org/Dynamic%20Javascript%20PluginThat ALSO isn't what you need?
Grails - Dynamic Javascript Plugin
Source: grails.org
Generate javascript from controllers in response to AJAX requests, similar to Rails RJS Templates.Blog entry: http://blog.peelmeagrape.net/2007/10/9/dynamic-javascript-plugin-for-grailsThe plugin: grails-dynamic-javascript-0.1.zipSimple Demo App: dynamic_javascript_demo_0.1.zip
Share
Brandon Franklin
August 13 at 2:25pm
Oh sorry, I think that's the same thing the guy is working on that you linked to!
Brandon Franklin
August 13 at 2:27pm
Brent Fisher
August 13 at 3:13pm
It is getting close, but missing a bit of the spark and maturity that RoR has for it, but I'm gonna experiment more with it tonight and see if I can recreate all the cool ajax server-side java scripts that I had put in to the RoR version of my App.I'll let you know how it goes.
Subscribe to:
Posts (Atom)
