- 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
- 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
- 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)
- 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'
- 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
- 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.
Posts
Hi Alex,
ReplyDelete(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.
Peter,
ReplyDeletethanks 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 !