Saturday, September 08, 2007

Grapestry progress and wishlist

I've been making some progress in making the Grapestry Grails plugin more integrated into Grails. Overall, it hasn't been quite a walk in the park, mostly due to the way Tapestry works. Here are a couple of things that would really be nice-to-have before Grapestry can really be usable as a Grails plugin:


  1. Tapestry templates (pages and components) should show up directly under the grails-app/views directory. Overall, the idea is that that's where Grails GSPs typically show up, and it would be most natural for Grapestry to do the same

  2. Tapestry page and component classes should live directly under grails-app/controllers. Overall, in Grails, the controllers are what process the requests. Since the page and component classes have the corresponding duty in Tapestry, so it would make sense to keep them there

  3. Since Grails emphasizes convention over configuration, creating pages should default to no page specification files. Everything that a page spec does should be accomplished using annotations (totally acceptable in regular Tapestry)

  4. Add groovy scripts and templates that would set up a default page template and page classes, e.g. something like 'grails create-grapestry-page' and 'grails create-grapestry-component'

  5. Add scaffolding similar to the one that exists in Grails controllers. It seems totally possible that there could be default methods like 'list', 'edit', etc on a grapestry page that would do the equivalent job of the Grails controllers with dynamic or static scaffolding

  6. Have some NetBeans support (hopefully coming in NetBeans 6.0) for Grails and Tapestry to make editing the Tapestry components in Groovy at least on par with doing them in Java



I did make some progress in accomplishing the first couple of bullets above. I kinda thought I had that down; however, it turns out that the "Development" grails configuration doesn't quite obey the same rules (it uses some resouce loaders that load resources directly from the ${app_dir}/grails-app/view and controllers directory), so I'm working on some workarounds for that.

Just yesterday, I got the Grails plugin account, but I still need to take a look at a standard grails plugin structure before I put anything out there.

2 comments:

  1. Hi Alex,

    (1) seems fine, but I would consider evicting the controllers plugin and creating a custom artefact for your pages, possibly in a 'pages' sub-directory. The JSecurity and Quartz plugins have examples of custom artefacts (Realm in JSecurity, and Job in Quartz).

    As for the scripts, the GWT plugin has some 'create*' scripts that you can use for inspiration.

    Keep up the good work.

    ReplyDelete
  2. Peter,
    thanks for the tip, I do evict the controllers plugin; however, I think it was one of the other scripts that optionally copies the "views" directory into WEB-APP in prod config, and adding the filter and not copying in the dev config. I thought that the Tapestry templates should be in views (and code should be in controllers) as that's where typical gsp-s/controllers sit, just to keep it as close to Grails as possible (considering that the gsp-s and the Tapestry templates have very similar functions, whereas quartz jobs and jsecurity realms are quite different)

    I'll definitely take a look at these other plugins for inspiration, I can definitely use some best-practices working examples.

    Thanks for checking in !

    ReplyDelete