jastrachan | 13 May 20:47 2004
Picon

Re: Thicky advise .. builder versus class creation

HI Paul.

On 13 May 2004, at 17:29, Paul Hammant wrote:

> Folks,
>
> Thicky pages are goovy classes (ye all know that right?)..
>
> class MyPage extends SomeBasePage {
>   MyPage(BuilderSupoprt builder) {
>     // create a page using the builder.
>   }
> }
>
> I wonder what it would be like to change to a more interpreted design 
> where GroovyShell was used to intepret a looser page definition.  The 
> 'page' script would be handed a SwingBuilder instance and operate over 
> it as normal, creating panels, buttons, fields etc.  My question 
> concerns how far can GoovyShell go?  I know I could define a script 
> that would compose a page from builder functions, but can I weave in 
> custom extension of graphical components (say MyJButton) as I can with 
> the current implementation.  i.e. can GoovyShell notice inlined class 
> definitions and act on them in some way?  Or is there an inherent 
> limitation for GroovyShell versus the classes created by 
> GroovyClassLoader ?

I don't quite follow exactly what you mean - here's a few answers to 
see if they help :).

The GroovyShell is really just a lightweight wrapper on top of the 
GroovyClassLoader with a few helper methods; there's no technical 
difference. So you can arbitrarily load/compile any classes whenever 
you like.

Maybe you're interested in changing different classes under the covers 
while other stay the same? If so you can arrange your class loader 
hierarchy to reload types you can reload when its safe to do so etc. 
e.g. reload each page script whenever you like but keep the same base 
class in your parent classloader etc.

Or maybe you want to dynamically load new classes from the web server 
as & when they're required? e.g. you Page1.groovy references 
MyRandomComponent.groovy which hasn't been compiled yet? If so we've 
some code to do this (groovy.util.GroovyScriptEngine) which is used for 
Groovlets to allow scripts to reference each other & get auto-compiled 
on the fly (& handle recompiling changes cripts).

Though unfortunately GroovyScriptEngine is not quite wired into the 
GroovyClassLoader yet - so currently this feature is only used in the 
GroovyServlet - but it shouldn't be too hard to add in.

Incidentally I was chatting with Philip Milne the other day, who's been 
working on a special class loader for Groovy that when you refer to a 
class which isn't on the classpath, it will look in the local maven 
repo, or remote maven repo and download the jar & all dependencies 
required for it. This is similar in a sense to Sam's 
GroovyScriptEngine, but for 3rd party jars rather than groovy scripts 
to be compiled. Integrating the two into Groovy would totally rock!

e.g. you'd be able from the command line without specifying a classpath 
to do...

     groovy -e "new com.foo.whatever.SomeComponent().doSomething()"

and the groovy engine + classloader magic would, from your local & 
remove maven repos, figure out all the jars required & do the right 
thing.

(Note we'd need to be able to enable/disable this feature but it would 
be very useful).

James
-------
http://radio.weblogs.com/0112098/

Gmane