jastrachan | 17 May 10:19 2004
Picon

Re: [groovy-dev] builder support

Hi Robert

The idea behind the builders is that you can use any builder (push/pull 
event based builders, DOM-ish builders, Ant / bean builders etc). The 
code producing the markup doesn't really care - its just given a 
builder on which to work. So the AntBuilder does indeed invoke Ant 
tasks directly.

I guess for transformation, the user needs to choose what model to use 
to perform the transforms on. e.g. one transformation mechanism could 
be to use XSLT - so you could create a SAXBuilder and wire it into TRaX 
(JAXP). Another could be to create W3C DOM nodes. Or Groovy Node trees 
etc. For Groovy scripting, the easiest model is probably the Groovy 
Node.

Whats missing today is if we create a tree of Nodes, we don't have a 
way to fire the nodes into a real builder. So how about we added a 
helper method to Node to allow it to be output to any builder. Then we 
could do something like...

node = new NodeBuilder().build {
     target(name:"compile") {
	delete(dir:'target')
     }
}

// do some transformation
node = transform(node)

// now lets output it to Ant
ant = new AntBuilder()
node.build(ant)

Then the single build() method we add to Node could output the node 
tree to any builder.

On 17 May 2004, at 00:18, robert kuzelj wrote:
> hi,
>
> i am experimenting with the BuilderSupport and there are
> some issues with the design that seem to be strange imo.
>
> the whole point of the builders is to enable dynamic creation
> of hirarchical datastructures. from a pure construction
> point of view the only thing you need is the NodeBuilder.
>
> but sadly NodeBuilder has one big issue - it can not be
> transformed.
>
> for example if you have the following code
>
> return builder.project(name: "default-impl",
>                        default: "echo",
>                        basedir: "."){
>
>     target (name: "wipe"){
>         delete dir: "${dir.build}";
>         delete dir: "${dir.dist}";
>         delete dir: "${dir.src.generated}";
>         delete dir: "${dir.src}";
>     }
>
>     tstamp{
>         format property: "pack.timestamp",  pattern: "yyyy-MM-dd";
>     }
>
>     target (name: "clean"){
>         delete (failonerror: "false"){
>             fileset dir: "${dir.dist}", includes: "**/*.*";
>         }
>     }
> }
>
> obviously this is some ant script. or is it? well lets asume that
> it will become an ant script during its lifecycle but it must not
> necesserally begin its life a as ant script. i could for example
> be interested in the pure tree structure at first because my build
> process is very complex and i want to transform the tree (script)
> prior to its execution. in such a case a pure tree structure would
> come very handy. lets further asume that the transformation process
> is buggy (it happens to me now and then ;-) ) so i would like to
> see the transforamtion result. of course i want it to be shown in
> groovy syntax. now lets also asume that the bug is realy serious and
> i cant find it. so i want to dump my transformation result into a
> pure ant-xml syntax for better debugging.
>
> now the above scenario is simply not possible at the moment (or i 
> havent
> found any way thru it). as soon as i do builder = new AntBuilder();
> i always will get an execution of that project.
>
> of course i could build some sort of factory mechanism
> def build(_type){ /* return object according to _type */};
> builder = build("ANT");
> return builder.project(name: "default-impl",  ....
>
> this will at least enable to change the target format but it wont help
> on the transformation issues.
>
> i dont see the reason for forcing the user to decide so early what he
> wants. the later the better.
>
> i would propose to create for every concrete builder (AntBuilder, 
> SwingBuilder, etc.) a constructor that recives a NodeBuilder, and
> a method (transform or execute or run or...) that finally renders the
> tree-structure into the final output format.
>
> ciao robertj
>

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

Gmane