Monday evening thoughts

[Dierk König]

Hiall,

this is a long mail - I warned you!

Having worked with Grails for quite some days now,
I need to voice that it is absolutely fantastic
and has even more potential than I originally
envisioned.

This is a piece of software that will rock the world!

What I found particularly useful:
- all J2EE, simple to deploy and integrate
- scaffolding in all its aspects
- conventions: simple and evident
- all application code looks so obvious
- configuring datasources is easy
- schema evolution is easy
- everything contained (server, db)
- boostrapping data via Groovy code: awesome !!!
- error view with line numbers and code snippet
- the docs are already reasonably complete
- all the 'dynamics'

In addition to what is already in my JIRA 'whishlist'
I'd like to place some ideas for discussion (and add
them later to JIRA if sensible).

- Since we are Groovy (as opposed to Ruby) we can rely
on having Swing available. This would allow to provide
a graphical grailsConsole (analogous to groovyConsole).

- grailsConsole could provide interactive means for
controlling the scaffolding process, e.g. selections
for available domain classes, different options
for scaffolding, warn for override, etc.

- It could provide visual representations of
domain classes and their dependencies as well as
visualizations of the pageflow, controller chains, etc.

- It could provide table views to the database.

- It could provide an administation shell that allows
executing Groovy code against the database, querying
objects like you would do from a Controller.

- That said, deploying
http://ulc-community.canoo.com/snipsnap/space/Contributions/Utilities/Admin+
Console
with your grails app should provide you now already
with means to CRUD your domain objects via usual
Groovy code. That is tweaking your live server objects!
Maybe some minor tweaks are needed
to connect to the according context, vlc.

- grailsConsole could integrate with log4j chainsaw
to display the logs more conveniently (and faster).

- It could run the unit and functional tests.

- A Default View or Controller should be bound if
the webapp is called plainly (localhost:8080/myapp).
Something like 'index' or 'splash'.

- Grails taglibs are groovy but additionally having
an equivalent to RoR renderPartial would be cool.
Called from the view, not from the controller.
(it may be there and I overlooked it)

- Automatic reload after file changes works fine but
all domain objects are lost even if only a View
changed. Maybe loading them in a parent class loader
would solve that (?)

- Muuuuuuch later we need to tell about advanced
configuration options: authentication, authorization,
JNDI, hibernate mappings, working from existing DBs,...

cheers
Mittie

[graemer]

On 06/03/06, Dierk Koenig <[hidden email]> wrote:

> Hiall,
>
> this is a long mail - I warned you!
>
> Having worked with Grails for quite some days now,
> I need to voice that it is absolutely fantastic
> and has even more potential than I originally
> envisioned.
>
> This is a piece of software that will rock the world!

Lets hope so :-)

>
> What I found particularly useful:
> - all J2EE, simple to deploy and integrate
> - scaffolding in all its aspects
> - conventions: simple and evident
> - all application code looks so obvious
> - configuring datasources is easy
> - schema evolution is easy
> - everything contained (server, db)
> - boostrapping data via Groovy code: awesome !!!
> - error view with line numbers and code snippet
> - the docs are already reasonably complete
> - all the 'dynamics'
>
> In addition to what is already in my JIRA 'whishlist'
> I'd like to place some ideas for discussion (and add
> them later to JIRA if sensible).
>
> - Since we are Groovy (as opposed to Ruby) we can rely
> on having Swing available. This would allow to provide
> a graphical grailsConsole (analogous to groovyConsole).

There is already a JIRA issue about this:
http://jira.codehaus.org/browse/GRAILS-33
Though it is not nearly as complete as your wishlist! You may want to
post your ideas there :-)

>
> - grailsConsole could provide interactive means for
> controlling the scaffolding process, e.g. selections
> for available domain classes, different options
> for scaffolding, warn for override, etc.
>
> - It could provide visual representations of
> domain classes and their dependencies as well as
> visualizations of the pageflow, controller chains, etc.
>
> - It could provide table views to the database.
>
> - It could provide an administation shell that allows
> executing Groovy code against the database, querying
> objects like you would do from a Controller.
>
> - That said, deploying
> http://ulc-community.canoo.com/snipsnap/space/Contributions/Utilities/Admin+
> Console
> with your grails app should provide you now already
> with means to CRUD your domain objects via usual
> Groovy code. That is tweaking your live server objects!
> Maybe some minor tweaks are needed
> to connect to the according context, vlc.
>
> - grailsConsole could integrate with log4j chainsaw
> to display the logs more conveniently (and faster).
>
> - It could run the unit and functional tests.
>
> - A Default View or Controller should be bound if
> the webapp is called plainly (localhost:8080/myapp).
> Something like 'index' or 'splash'.

Yes this is on my todo list, should probably raise a JIRA issue i guess

>
> - Grails taglibs are groovy but additionally having
> an equivalent to RoR renderPartial would be cool.
> Called from the view, not from the controller.
> (it may be there and I overlooked it)

Yeh its already there in views though we call them templates not
partials, see http://grails.codehaus.org/Tag+-+render

>
> - Automatic reload after file changes works fine but
> all domain objects are lost even if only a View
> changed. Maybe loading them in a parent class loader
> would solve that (?)
Lost? What do you mean? If you mean data, this only happen when you
reload a domain class, and wouldn't actually happen if you were using
a real db not the in-memory HSQLDB.

There are other issues reloading domain classes, in general I think we
should have a warning printed to the console when a domain class is
reloaded saying that it is recommended the server is restarted if its
a live environment as it can produce some oddities.

>
> - Muuuuuuch later we need to tell about advanced
> configuration options: authentication, authorization,
> JNDI, hibernate mappings, working from existing DBs,...
Agreed. There are some docs about hibernate mapping, but the rest
definitely needs to be covered

Thanks for the feedback!
Graeme

>
> cheers
> Mittie
>
>

[Dierk König]

> > This is a piece of software that will rock the world!
> Lets hope so :-)

Honestly, I'm dead sure it will.

> > - the docs are already reasonably complete

Especially the generated PDF is cool!

> There is already a JIRA issue about this:
> http://jira.codehaus.org/browse/GRAILS-33
> Though it is not nearly as complete as your wishlist! You may want to
> post your ideas there :-)

Yes, will do!

..
> - Grails taglibs are groovy but additionally having
> an equivalent to RoR renderPartial would be cool.
> Called from the view, not from the controller.
> (it may be there and I overlooked it)

> Yeh its already there in views though we call them templates not
> partials, see http://grails.codehaus.org/Tag+-+render

Ah, cool. When I read the word 'template' is supposed the
inclusion mechanism to work the other way around.
(having the template including me, not me including the
template)
My fault of not reading until the end...

> - Automatic reload after file changes works fine but
> all domain objects are lost even if only a View
> changed. Maybe loading them in a parent class loader
> would solve that (?)

> Lost? What do you mean? If you mean data, this only happen when you
> reload a domain class, and wouldn't actually happen if you were using
> a real db not the in-memory HSQLDB.

Yes, I was running with in-memory HSQLDB which probably was
the problem. - and it was so late in the evening that I
wouldn't trust my own eyes.

My conception was that I created some new objects, changed a
Controller and the objects were gone ( because of boostrapping
using 'create-drop' ?). Anyway, I'll investigate better the
next time I hit the behaviour.

> - Muuuuuuch later we need to tell about advanced
> configuration options: authentication, authorization,
> JNDI, hibernate mappings, working from existing DBs,...

> Agreed. There are some docs about hibernate mapping, but the rest
> definitely needs to be covered

Thanks for the great work
Mittie

[Dierk König]

> > Lost? What do you mean? If you mean data, this only happen when you
> > reload a domain class, and wouldn't actually happen if you were using
> > a real db not the in-memory HSQLDB.

Sorry, I was wrong. It all works perfectly.

Server restart is only required when changes are made to:
- domain classes
- taglibs (that would be cool to have without restart)
- web.xml
- non-grails resources like index.html :-)

Maybe more? I don't know. We should complete the list
and add it to the docs...

Anyway, programming with Grails was again a ton of joy today.
I came across something I would like to share although it is possibly
known to everybody but me... (Life is much more suprising if you don't RTFM)

I thought my 'tutorial' example would need some 'previous/next' facility.
So I introduced a '@Property TutorialEntry predecessor' to TutorialEntry.
Kind of logical, he?

But now the cool thing: I added previous and next action to the
controller:

    @Property previous = {
        def entry = TutorialEntry.get( params.id )
        if (entry.predecessor) {
            entry = entry.predecessor
        }  else {
            flash.message = "Top of tutorials reached."
        }
        redirect(action: show, id: entry.id)
    }

is really slick, albeit not very surprising.
But here it comes: it also works backwards!

    @Property next = {
        def entry = TutorialEntry.get( params.id )
        def nextEntry = TutorialEntry.findByPredecessor(entry) // <- cool !
        if (nextEntry) {
            entry = nextEntry
        } else {
            flash.message = "End of tutorials reached."
        }
        redirect(action: show, id: entry.id)
    }

That is really neat!

Thanks for bringing back the joy of programming
Mittie

[graemer]

On 07/03/06, Dierk Koenig <[hidden email]> wrote:
> > > Lost? What do you mean? If you mean data, this only happen when you
> > > reload a domain class, and wouldn't actually happen if you were using
> > > a real db not the in-memory HSQLDB.
>
> Sorry, I was wrong. It all works perfectly.
Excellent!

>
> Server restart is only required when changes are made to:
> - domain classes
Occasionally yes.

> - taglibs (that would be cool to have without restart)
This will be fixed when I upgrade our Groovy jar with the latest build
of Groovy. Its due to a bug that Jochen fixed related to reloading not
working when one class extends another.

> - web.xml
This only works under tomcat, but we could get it to work with jetty
if we used their API directly inside the while loop that waits forever
in the build to check if the web.xml has changed.

> - non-grails resources like index.html :-)
Woops forget about these, will change this so this works..

With these changes it will only be the occasional restart due to domain classes
>
> Maybe more? I don't know. We should complete the list
> and add it to the docs...
>
> Anyway, programming with Grails was again a ton of joy today.
Excellent! :)

> I came across something I would like to share although it is possibly
> known to everybody but me... (Life is much more suprising if you don't RTFM)

>
> I thought my 'tutorial' example would need some 'previous/next' facility.
> So I introduced a '@Property TutorialEntry predecessor' to TutorialEntry.
> Kind of logical, he?
>
> But now the cool thing: I added previous and next action to the
> controller:
>
>     @Property previous = {
>         def entry = TutorialEntry.get( params.id )
>         if (entry.predecessor) {
>             entry = entry.predecessor
>         }  else {
>             flash.message = "Top of tutorials reached."
>         }
>         redirect(action: show, id: entry.id)
>     }
>
> is really slick, albeit not very surprising.
> But here it comes: it also works backwards!
>
>     @Property next = {
>         def entry = TutorialEntry.get( params.id )
>         def nextEntry = TutorialEntry.findByPredecessor(entry) // <- cool !
>         if (nextEntry) {
>             entry = nextEntry
>         } else {
>             flash.message = "End of tutorials reached."
>         }
>         redirect(action: show, id: entry.id)
>     }
>
> That is really neat!

Wow, thats pretty cool :-)

>
> Thanks for bringing back the joy of programming
Rails did it first, we're just making it better ;-)

> Mittie
>
>