Tuesday, September 22, 2009 3:02 PM
I look forward to the meeting tonight. There are still a few spots available, so please consider coming if you have a bit of time. Also, feel free to come a bit earlier if your schedule works better that way - I'll be there from 5 pm on. You'll have to sign in downstairs.
We are conveniently located downtown in financial district, close to pretty much all subway lines.
I was hoping to release my pluigin that I am planning to show tonight, but am having trouble releasing it to the plugin repository, so let me give a little description to give you a taste of what I'll be talking about:
When trying to iteratively develop applications, it is typical that your domain model changes a lot during early parts of development. Scaffolding is a great crutch to develop CRUD pages, and in fact the scaffolding process can be extended to add additional pages beyond the regular CRUD provided out of the box. Furthermore, Grails' capability to do dynamic scaffolding is a great way to test your domain model, and frequently can serve as basis for future work on GSP pages.
However, the default scaffolding templates are limiting in that they don't allow customizations of scaffolded pages. For example, if I want to NOT display a particular property on the show page, I am not able to do so - I have to generate the scaffolded GSP pages, and then manually edit them. This means that if I need to add another property in the future, I have to either start manually edit the GSP pages, or regenerated scaffolded pages, and remove the unwanted property. This seems to violate DRY.
Additionally, some plugins require modifying the GSP pages. For example, the drill-down plugin requires to add <drilldown:resources/> tag to the header element, as well as other elements into the list table. Our plugin had to provide ability to insert some of those customization so that we can insert plugin integration code into our scaffolded pages.
I wanted solutions to the problems above, and wanted to see how far I can push the dynamic scaffolding process in that my UI layer is absolutely minimal. There will definitely be time for custom UI development, but I wanted to generate as much of the UI as possible.
Let's step back for a second. Using dynamically scaffolded pages is a two step process. The first part of the process generates the pages, and the second part executes them agains the application domain model. Our goal is to provide hooks in the first phase of the process, so that the generated (and executed) pages are modified appropriately.
If you examine the scaffolding process, you will see that there are typically two types of insertion points. The first insertion point is fairly static, for example the header of a page. If we have an ability to inject some code into a header, then we can modify the page. Another type of insertion point is when the scaffolding pages iterate over properties of a domain object. This allows us to customize a particular row in the table that displays properties. If we want to not display a particular property, or to modify how it gets rendered,
The goal of the design was to provide a very flexible way to define scaffolding extensions definitions. Because the users may prefer to define their extension definitions differently, we want to enable that flexibility.
As a result, there are many different ways to do it, including one that can be easily put along the constraints definitions during domain object creation, which allows a convenient way to view the definitions without creating unnecessary coupling.