cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: GroovyMarkup syntax works!
Date Thu, 15 Apr 2004 19:40:13 GMT
Bertrand Delacretaz dijo:
> I've just commited a GroovyMarkup [1] generator sample in the BSF
> block, allowing the ScriptGenerator to use syntax like this:
> {
>      content() {
>          section() {
>              title("GroovyMarkup test")
>              p("Look ma, no angle brackets!")
> 	ul() {
>                  for(i in 1..5) {
>                      li("This is item " + i)
>                  }
>              }
>         }
>      }
> }

Great, job!
I expended the most of the time trying to make it work, but without the
fix it was impossible. :-(

> Thanks to James Strachan who very quickly fixed a problem in Groovy's
> SAXBuilder. I've committed a snapshot of the Groovy jar with the fix,
> this will have to be replaced with the next release when it's
> available.

James is really a nice guy, I chatted with him on groovy channel last time
(thanks to Brian). James showed interest in see working Groovy on Cocoon
and of course as a Flow Engine language with continuation support. I will
work again on that this weekend. Hope this time I will success.

> Next step would be to allow the (way cool) Groovy Sql syntax [2] to be
> used for database queries. It should be easy to implement, by making a
> ConnectionProvider available to the scripts so that a groovy.sql.Sql
> object can be created to use Connections from the Cocoon pool (I'm
> thinking of having the ScriptGenerator release them to keep scripts
> simple).

This is something that was on my head for a while and not sure if this is
good or not. I am still thinking about that. The plus are not needed to
said, my reluntace is, because:

Aparently no O/R mapping suppport.
No researched enough Groovy to said that, but I will not go back to plain
JDBC and SQL. I think is not a plus to start designing in this way. But
people can welcome this approach if they use too few tables. This is
diferent and maybe for total no DB-oriented cases this is a great plus.

What I try to said is: SQL support in Groovy is welcomed and it is OK, but
I will not try to encourage people about his usage for DB oriented webapp
in Cocoon. I think we can see a better way in O/R mapping tools.

But maybe there is a way using O/R mapping in Groovy. And this will be great!

Best Regards,

Antonio Gallardo

View raw message