Blogging Roller

Groovy support back in Netbeans

2007-11-28T09:05:28+00:00

After going missing in NB 5.5, Groovy support is back in Netbeans. Basic Groovy support with syntax coloring and support for running scripts from the IDE is available in plugin form (download page) for Netbeans 6.0 (starting with RC2), read about it on Geertjan's blog.

Here's what's coming after Netbeans 6.0, Groovy project support:</>

After Netbeans 6.0, the story gets better. Geertjan writes that a brand new Groovy plugin will be available in the post-6.0 builds that adds support for three types of Groovy projects: applications, class libraries and Grails webapps.

Zero

2007-07-02T09:28:53+00:00

IBM's project Zero has de-cloaked.

Project Zero introduces a simple environment for creating, assembling and executing applications based on popular Web technologies. The Project Zero environment includes a scripting runtime for Groovy and PHP with application programming interfaces optimized for producing REST-style services, integration mash-ups and rich Web interfaces.

Smells a lot like Phobos (see also Phobos Meets Atom, REST), but Phobos is focusing on server-side JavaScript first. Oh, and Phobos is open source. Project Zero is not.

"This community is an experiment in a new way to build commercial software, an approach we are currently calling Community-Driven Commercial Development. Community-Driven means that we want feedback, insight, suggestions, criticism, and dialogue with you, the users of Project Zero. This interaction will yield a better solution that is more targeted at the problems you have and a technology that truly delivers on its objectives. Commercial means that this is not an open source project."

Community-driven? Sounds like the community is a back-seat driver with freedom to complain but no access to the steering wheel, gas pedal or breaks.

Basic Groovy, for Netbeans 6.0

2007-05-21T16:24:23+00:00

Speaking of open source projects that need help, there's Coyote, which promised to bring scripting support to Netbeans and did so for Netbeans 5.0. Since then, the project has been pretty stagnant. JRuby's getting all the attention these days.

Geertjan is doing his best to jump-start Groovy support in Netbeans, but it's not really his job. He's gone beyond the call of duty and it looks like he's got something pretty functional going, which is very nice. I've been doing some Groovy scripting lately, so I'll try it out. It would be cool if the Groovy project itself had time to help out, or even take over, but they're probably pretty busy too.

Pluggable renderers and scripting languages in Roller

2007-03-11T23:45:03+00:00

My next ApacheCon talk is about Roller and blogs as a web development platform. One of the things I plan to discuss is using scripting languages within Roller, something that's possible now because Roller versions 3.0 and later allows pluggable renderers. It's undocumented and a little hacky right now, but by plugging in your own custom renderers you can add support for new template and scripting languages as alternatives to Roller's built-in Velocity. Here are some notes on the whys and hows.

Why would you want to plugin a new scripting or template language?

I can think of two reasons you might want to plug-in a new renderer to Roller. If you're not happy with Velocity and want to plugin an alternative template language like Freemarker you can do it with a custom renderer. Or, if you're developing sophisticated Roller templates and you need a more sophisticated programming language like Groovy, JRuby or Javascript then custom renderers are your best bet.

What can you do in an alternative scripting or template language?

In an alternative template or scripting language you can access the normal Roller model objects (see the Roller Template Guide for a reference) and you can generate just about any type of content you want. However, you cannot access the Roller macros because they're written in and require Velocity.

It's also worth noting that you can get in quite a bit of trouble with an alternative language. Roller's built-in Velocity renderer allows users to access only a very limited set of objects, but other scripting and template languages might not be so safe. That's why you might not want to make all plugin renderers available to all of your users.

How do you implement scripting in a plugin renderer?

I plan on documenting the process at some point, but basically you implement two simple interfaces: RendererFactory and Renderer. So far, I've developed three plugin renderers: BSFRenderer, GroovletRenderer and GSPRenderer. Let's discuss each so you can see how they work.

A BSFRenderer example

The Bean Scripting Framework (BSF) makes it easy to call a wide variety of scripting languages from Java and because it works with Java SE 5, it's a better choice for Roller than the Java SE 6 scripting extensions. I developed a BSF renderer (BSFRendererFactory and BSFRenderer) and with it, it's theoretically possible to support the use of just about any BSF scripting language in a Roller template. I've tried Groovy and JavaScript and they both work fine, but JRuby has some conflicts with the version of Hibernate that we're using in Roller so I'll have to revisit JRuby later.

Unfortunately, with the BSFRenderer you're stuck writing Servlet-like code like this Groovy example:

    out.println("<html><body>")
    out.println("Hello World, my blog is ${model.weblog.name}");
    out.println("</body></html>");

Ugh. Nothing to write home about, that's for sure. Fortunately, there's something better.

A GroovletRenderer example

I also developed a GroovletRenderer and a Groovy Server Pages (GSP) GSPRenderer, which look more promising. These renderers call Groovy directly and behave like the Groovlet and Groovy Template Servlets that come with Groovy.

With my new GroovletRenderer (GroovletRendererFactory and GroovletRenderer), you can use the GroovyMarkup builder to build HTML. Here's an example that displays a blog title, description and most recent entries:

    html.html { // html is implicitly bound to new MarkupBuilder(out)
        head {
            title(model.weblog.name)
        }
        body {
            h1(model.weblog.name)
            i(model.weblog.description)
            map = model.getWeblogEntriesPager().getEntries();
            map.keySet().each() {
               map.get(it).each() {
                  h2(it.title)
                  p(it.text)
                  br()
               }
            }
        }
    }

Starting to look more interesting, no?

A GSPRenderer example

I also developed a GSPRenderer (GSPRendererFactory and GSPRenderer), which allows you to use a JSP like syntax with <% %> and <%= %>. Here's the above example, but rewritten as a Roller GSP page:

    <html>
       <head>
          <title>${model.weblog.name}</title>
       </head>
       <body>
   <h1>${model.weblog.name}</h1>
       <i>${model.weblog.description}</i>
       <% map = model.getWeblogEntriesPager().getEntries();
          map.keySet().each() { %>
              <% map.get(it).each() { %>
                <h2>${it.title}</h2>
                <p>${it.text}</p><br />
              <% }
          }%>
       </body>
    </html>

That's all I have time for tonight. Next I hope tackle JRuby and hopefully I'll find some way to support some form of JRuby templating too. Where is all this going? I don't know. I'm not sure these plugins will make it into the Roller 4.0 release, but I do hope to make it easier to drop them and renderer plugins like them into Roller 4.0.