Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!

Matthew Taylor

Rancher
+ Follow
since Jun 13, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matthew Taylor

I'm a Senior Frontend Engineer at Yahoo! working entirely in JavaScript, but I have a background in Java on the backend. I'm looking for some fun part-time JavaScript work. Please contact me at rhyolight@gmail.com if you are interested.

Resume is here.

Thanks!
10 years ago
This book is perfect for beginners.
10 years ago
Hooray for Dave Klein! (I know that guy!!)
10 years ago
It might help you to take a look at this presentation I gave at a local Groovy Users Group. There is a slide deck and some working sample applications.
11 years ago
Disclaimer: I am the lead programmer for GrailsUI.

I'll give you 3 ways that GrailsUI is superior to RichUI.

1. Managed resources

With GrailsUI, you must specify to the plugin what components you are using within a page, but it will only include the JavaScript and CSS that is required to use the component. If you are using many components, GrailsUI will know only to include your resources one time, and in the correct order. RichUI will include duplicate resources if your components require the same inclusions.

2. Component accessibility

Every YUI component that is created by GrailsUI tags are accessible through their ids elsewhere on the page within the GRAILSUI JavaScript namespace. This means that you can create a data table, and then add a row selection listener to it in your own JavaScript on the page. You have much more control and flexibility because of this.

3. YUI config pass-through

YUI components can be created with many configuration options, so as a GrailsUI user, you can specify these options to the GrailsUI tag and they will be passed through into the underlying YUI component that is created. This allows you great configuration of your components without GrailsUI interfering.


This being said, RichUI is much easier to use, because it provides ways to do the most common things you'll want to do with your widgets. You can do the same things with GrailsUI, but you should know a little more about JavaScript and YUI to take advantage of the most powerful tactics. In general, I think the rule applies that you should learn the language you are programming.

RichUI also provides more components outside the YUI realm that are useful. I have used both of these UI plugins simultaneously in my projects in the past successfully.
11 years ago
You can see all the Ajax Grails plugins here.
11 years ago
The January and February issues of GroovyMag have articles on the "Legacy database from Hell". There is also a lot of information about this in Grails in Action. I've been very successful doing this type of thing in the past using static mappings.
11 years ago
Well I would start by installing the webtest plugin for Grails. Even if you are not using Grails, but just Groovy in your webapp, you can take a look at this open source project and see how they are managing testing.
11 years ago
Can you narrow down your inquiry a bit? That is a pretty broad subject? Where would you like to start?
11 years ago

Gregg Bolinger wrote:So the interesting thing here is that you end up with packages that don't really offer anything. How is putting everything under

com.company.project

any different than just not using packages at all?



Because you might have conflicting class names. If you get a reasonably large Grails app, you might have a ChartTagLib that conflicts with the ChartTagLib in a plugin, or something.
11 years ago

Gregg Bolinger wrote:

Matthew Taylor wrote:Package names should describe and separate code functionality, not code type.



This is an interesting concept since this isn't what has been preached over the years.



It is my opinion, and it works specifically well in Grails projects. I've fought this battle in my Java shops in the past, with mixed results.
11 years ago
Gregg, I've got a blog post about this here
11 years ago
The second declaration without the "def" will only work when groovy is being executed as a script, which is the case within the groovy shell command line tool and the groovy console. Within your groovy classes, you must define a variable with "def".
11 years ago
I have not read the book. But from experience, I can say that Agile processes and patterns are extremely useful in the J2EE world. The only issue is that you must attempt to adopt them as a team. It is really hard to start using agile or XP processes alone. You've really got to get buy-in from your whole team to it work really smoothly. But once you have that, development is faster, more fun, and more rewarding.