Griffon has Flown the Coop! (Danno Ferrin)

, , September 29th, 2008

Original Source

Danno Ferrin just announced that Griffon now has its own project space at the Codehaus.

Griffon durring it’s intial development was hosted as a module under the Groovy project. Well, with a public release the time has now come for Griffon to leave the nest and find a new home to roost in.

In addition to it’s own hompage the project has moved the user mailing list and added announcement, development, and code commit mailing lists. Code commits come off of our own subversion depot. The bug tracker has already had a couple of JIRAs posted and closed. And just this weekend continuious integration builds have been wired to run on the remote servers at codehaus (Xvfb FTW).

So what does that mean for you? Same deliverables, just coming from a different address.

Related to this news, some of the builders maintained by the Griffon team will be moving into the Griffon umbrella, these are SwingXBuilder, JideBuilder and GraphicsBuilder. The builders will still be released on their own timeline though and will not require you to link any Griffon runtime library in order to use them, same way as it has been before.

[Editor: mispellings are intentional, they are Danno’s signature].

Tags: , ,

Roundup of Griffon links

, September 23rd, 2008

The following list is a compendium (in chronological order) of Griffon related links. You may notice that half of them are written by Geertjan Wielenga, zone leader at Javalobby and known blogger on such topics as NetBeans, Swing and Groovy. In Geertjan’s own words

It’s not like I’m constantly looking for useful scenarios for Griffon and then blogging about it. It’s more like I keep tripping over them accidentally, all the time. I just can’t help it!

Announcements

First Impressions and how-tos

Tags: ,

Announcing Griffon 0.0 (Danno Ferrin)

, , , September 11th, 2008

Original Source

Swing developers rejoice, the productivity gains and ease of use of a framework like Grails has arrived. The Groovy Swing team is proud to announce the initial release of Griffon, a Grails-like framework for Swing application development. In words of Danno Ferrin, the most prolific contributor to the project:

After over a year of poking and prodding at the various parts of desktop Java the Groovy swing developers are proud to announce the first release of Griffon, a Grails-like tool for Swing development. While not yet industrial strength we felt it was important to put out a release so people can get a feel for what Griffon is and where it will be going. And since all good computer scientists start counting from zero, 0.0 seemed to be the perfect release number.

Griffon Kittens

What are some of the highlights of Griffon?

  • A Grails like build system for desktop apps, including targets to run the application.
  • A directory structure that rewards MVC separation of code.
  • Use of Groovy programming language features to reinforce MVC separation (builders, @Bindable annotation, metaclass method injection, scripts, etc).
  • A view layer based on Groovy’s SwingBuilder, allowing for a declarative layout of GUI code.
  • An infrastructure to allow seamless injection of other widget libraries. JIDE and SwingX are supported out of the box.
  • Automatic packaging and signing for WebStart, Applet, and traditional application deployment.

Why call it Grails-like instead of rails-like? The structure of the directories and some of the design idioms do have a heritage back to Ruby on Rails, but Griffon is more inspired by Grails than it was by Rails. And by “inspired” I mean “taking large chunks of Grails code to bootstrap the codebase” (thanks to the ASL 2.0 this is permissible). Not all Grails features have been brought over yet. Plugins and GORM are two notable standouts that we would like to add in future releases.

To download the current release please visit the wiki page at http://groovy.codehaus.org/Download+Griffon and follow the links. There is also an installation guide and a quick start tutorial on the wiki as well.

Those who attended the ScriptBowl session at JavaOne 2008 got a sneak peek of Griffon in action when Guillaume Laforge presented Greet, a Twitter client, on stage. Later Danno Ferrin did the same on another session. Griffon relies heavily on the conventions set out by Grails, which means any Grails developer will be able to pick up the framework and create Swing applications easily.

Being the initial release expect some rough edges here and there, and as Danno notes, some of the more appealing features of Grails like GORM and the plugin system are not implemented yet. The Griffon project has a mailing list for those interested to participate in the discussion.

Tags: , , ,

Grails Podcast Episode 65: Interview with James Ervin, current Groovy Eclipse Plugin Project Lead (Sven Haiges)

, , , September 10th, 2008

Original Source

In this Grails Podcast Interview with James Ervin we talk about all things Groovy Eclipse Plugin. James is Twittering about the Groovy Eclipse Plugin @GroovyEclipse and also be sure to check out his Blog at http://iacobus.blogspot.com.

If you want to join the Groovy Eclipse Team or would like to provide some kind of sponsorship for this project as a company, mail the Grails Podcast at grailspodcast@gmail.com and we’ll be happy to connect you.

Tags: , , ,

Groovy Awards Launched (Glen Smith & Sven Haiges)

, , September 2nd, 2008

The dynamic podcasting duo, Glen & Sven, have launched a new Grails powered site: groovyawards.org

The whole point is to recognize those members of the Groovy and Grails communities that have gone the extra mile and helped in fostering those communities. The winners will be announced during a (probably live) podcast session later this year during the 2GX San Jose. Speaking of which, those of you living on the Bay Area stay tuned, the final dates of 2GX will be announced shortly, and for those that do not live in Bay Area, don’t worry you are also invited to come!

Tags: , ,

NLGUG Announced (Marcel Overdijk)

, , , August 8th, 2008

Marcel Overdijk has announced the creation of NLGUG (Netherland’s Groovy User Group) group site hosted at Google groups. The intention of this effort to start building up a network of Groovy & Grails developers in The Netherlands. If the group grows and people are interested in meeting up the better. Please consider joining the group if you are local to The Netherlands and you find Groovy & Grails to be among your favorite topics.

Tags: , , ,

Official Groovy/Grails Support in NetBeans 6.5 (Vladimir Vivien)

, , July 2nd, 2008

Original Source

Vladimir Vivien confirms what we previously announced: NetBeans 6.5 comes with official support for Groovy and Grails. He found a link to NetBeans 6.5m1’s notes that explain with small detail what is to be expected on that release in terms of Groovy/Grails support.

Judging from the list of features that will be included in NetBeans 6.5, Groovy and Grails will be officially supported by the NB team. From the wiki text, Groovy and Grails will be first-class citizen in NB65 with features that will include:
- Editor support (code completion, color highlights, etc)
- Two-way Java / Groovy class integration
- Seamless Grail project support (support for all Grails artifacts and commands)
- Jetty integration for development-time deployment/testing.

It remains to be seen if NB65 Groovy support will be as comprehensive as IntelliJ which currently has the most extensive support for Groovy / Grails development.

Considering the 3 major IDEs, other popular editors as TextMate (and clones), jEdit, Vi(m), Emacs; comand line tools like Ant, Gant, Maven, and even CI servers like Bamboo and Hudson, there are plenty of options to get you started with Groovy and Grails.

Tags: , ,

Custom Implicit Variables in GSPs (Kevin Burke)

, , June 1st, 2008

Kevin Burke writes:

I really should start every post with “groovy is a really swell language”. You can do some pretty cool things with it.

Anyway, I had a desire to have an variable implicitly available in all of my GSP’s so that I didn’t have to wrap certain blocks in a tag that made the variable available. There were a couple of reasons for this. The first is that if an exception was thrown in the block of code, the stack trace would indicate that it was coming from my custom tag. More importantly however it was a real pain in the tuckus to have to litter my GSP’s with a tag that simply introduced a variable into the scope. After several attempts to hijack the page scope before the page was rendered I settled on the following:

  1. GroovyPage.metaClass .getCurrentUser = { -> ctx.authenzedManager .currentUser ( ) }

As it turns out every page extends GroovyPage which is just a groovy script. So you can add methods using it’s metaClass to add all kinds of functionality. This might be a good way for plugins to add sort of helper methods, since, unlike tags, it will actually return a value and not write it to out. Anyway, by adding getCurrenUser I can now call ${currentUser.whatever} from my GSP. It makes me happy.

Rock over London. Rock on Chicago.

5 Responses to “Custom implicit variables in GSP’s”

  1. Graeme Rocher Says:
    Nice. Just one note, tags actually return their value when they’re called as a method such as createLink(action:’foo’)
  2. Shawn Hartsock Says:
    Nice trick, that MOP stuff is really powerful.
  3. Kevin Burke Says:
    Graeme: That’s very true. Sorry for spreading misinformation. Oh well, still fun stuff anyway.

    Shawn: I don’t know what I’d do without it.

  4. esbium Says:
    Where do you put this code in a Grails app? In the config.groovy? maybe bootstrap.groovy?
  5. Kevin Burke Says:
    esbium: BootStrap would be a good place to put it. I happen to be using a plugin in this example.

Tags: , ,

Nothing Makes You Want Groovy More Than XML (Ken Kousen)

, March 12th, 2008

I’m in Delaware this week teaching a course in Java Web Services using RAD7. The materials include a chapter on basic XML parsing using Java. An exercise at the end of the chapter presented the students with a trivial XML file, similar to:


<library>
  <book isbn="1932394842">
    <title>Groovy in Action</title>
    <author>Dierk Koenig</author>
  </book>
  <book isbn="1590597583">
    <title>Definitive Guide to Grails</title>
    <author>Graeme Rocher</author>
  </book>
  <book isbn="0978739299">
    <title>Groovy Recipes</title>
    <author>Scott Davis</author>
  </book>
</library>

(with different books, of course) and asked the students to find a book with a particular isbn number and print it’s title and author values.

I sighed and went to work, producing a solution roughly like this:


import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;

import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;

public class ParseLibrary {
    public static void main(String[] args) {
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        Document doc = null;
        try {
            DocumentBuilder builder = factory.newDocumentBuilder();
            doc = builder.parse("books.xml");
        } catch (Exception e) {
            e.printStackTrace();
            return;
        }
        NodeList books = doc.getElementsByTagName("book");
        for (int i = 0; i < books.getLength(); i++) {
            Element book = (Element) books.item(i);
            if (book.getAttribute("isbn").equals("1932394842")) {
                NodeList children = book.getChildNodes();
                for (int j = 0; j < children.getLength(); j++) {
                    Node child = children.item(j);
                    if (child.getNodeType() == Node.ELEMENT_NODE) {
                        if (child.getNodeName().equals("title")) {
                            System.out.println("Title: "
                                + child.getFirstChild().getNodeValue());
                        } else if (child.getNodeName().equals("author")) {
                            System.out.println("Author: "
                                + child.getFirstChild().getNodeValue());
                        }
                    }
                }
            }
        }
    }
}

The materials didn’t supply a DTD, so I didn’t have any ID attributes to make it easier to get to the book I wanted. That meant I was reduced to continually using getElementsByTagName(String). I certainly didn’t want to traverse the tree, what with all those whitespace nodes containing the carriage-return/line-feed characters. So I found the book nodes, cast them to Element (because only Elements have attributes), found the book I wanted, got all of its children, found the title and author child elements, then grabbed their text values, remembering to go to the element’s first child before doing so.

What an unsightly mess. The only way to simplify it significantly would be to use a 3rd partly library, which the students didn’t have, and it would still be pretty ugly.

One of the students said, “I kept waiting for you to say, ‘this is the hard way, now for the easy way,’ but you never did.”

I couldn’t resist replying, “well, if I had Groovy available, the whole program reduces to:


def library = new XmlSlurper().parse('books.xml')
def book = library.books.find { it.@isbn == '1932394842' }
println "Title: ${book.title}\nAuthor: ${book.author}"

“and I could probably shorted that if I thought about it. How’s that for easy?”

On the bright side, as a result I may have sold another Groovy course. :) For all of Groovy’s advantages over raw Java (and I keep finding more all the time), nothing sells it to Java developers like dealing with XML.

 

Ken Kousen

Tags: ,

Mastering Grails: Changing the view with Groovy Server Pages (Scott Davis)

, , March 11th, 2008

Groovy Server Pages (GSP) puts the Web in the Grails Web framework. In the third installment of his Mastering Grails series, Scott Davis shows you the ins and outs of working with GSP. See how easy it is to use Grails TagLibs, mix together partial fragments of GSPs, and customize the default templates for the automatically generated (scaffolded) views.

The first two articles in this series introduced you to the basic building blocks of the Grails Web framework. I’ve told you — repeatedly — that Grails is based on the Model-View-Controller (MVC) architectural pattern (see Resources), and that Grails favors convention over configuration for binding the framework’s parts together. Grails uses intuitively named files and directories to replace the older, more error-prone method of manually cataloguing these linkages in an external configuration file. For example, in the first article you saw that controllers have a Controller suffix and are stored in the grails-app/controller directory. In the second article, you learned that domain models can be found in the grails-app/domain directory.

This month, I’ll round out the MVC triptych with a discussion of Grails views. Views (as you might guess) are stored in the grails-app/views directory. But there’s much more to the view story than the intuitively obvious directory name. I’ll talk about Groovy Server Pages (GSP) and give you pointers to many alternative view options. You’ll learn about the standard Grails tag libraries (TagLibs) and find out how easy it is to create your own TagLib. You’ll see how to fight the ongoing battle for DRYness (see Resources) by factoring common fragments of GSP code into their own partial templates. Finally, you’ll learn how to tweak the default templates for scaffolded views, thereby balancing the convenience of automatically created views with the desire to move beyond a Grails application’s default look-and-feel.

– See Original @ DeveloperWorks (Scott Davis)

Tags: , ,