[groovy-dev] Making GString Buildable

classic Classic list List threaded Threaded
11 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[groovy-dev] Making GString Buildable

tugwilson
We have an interface Writable which allows an object to take control  
of how it is written out.
We have an interface Buildable which allows an object to take control  
of how it is built.

When a Writer sees a Writable object it calls writeTo on the object  
and passes itself as a parameter
When a Streaming Builder sees a Buildable object it calls build on  
the object and passes itself as a parameter

At the moment GString is Writable but not Buildable.
I propose to make GString Buildable

Motivation:

At the moment Streaming Builders support mixed content (<a> hello <b>  
world</b><a> is mixed content - the element <a> contains a mixture of  
text and markup).

Quite often the mixed content consists of some text and the result of  
a GPath expression (the results of GPath expressions are Buildable)

Doing this is a little clumsy:

myTag {
mkp.yield "sometext"
mkp.yield myNode.tag."@attr"
mkp.yield "more text"
}

if GString was Buidable we could write

myTag "sometext ${myNode.tag."@attr"} more text"

Has anybody got any objections/comments on this?


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Making GString Buildable

Guillaume Laforge
Administrator
On 03/11/05, John Wilson <[hidden email]> wrote:

> We have an interface Writable which allows an object to take control
> of how it is written out.
> We have an interface Buildable which allows an object to take control
> of how it is built.
>
> When a Writer sees a Writable object it calls writeTo on the object
> and passes itself as a parameter
> When a Streaming Builder sees a Buildable object it calls build on
> the object and passes itself as a parameter
>
> At the moment GString is Writable but not Buildable.
> I propose to make GString Buildable
>
> Motivation:
>
> At the moment Streaming Builders support mixed content (<a> hello <b>
> world</b><a> is mixed content - the element <a> contains a mixture of
> text and markup).
>
> Quite often the mixed content consists of some text and the result of
> a GPath expression (the results of GPath expressions are Buildable)
>
> Doing this is a little clumsy:
>
> myTag {
> mkp.yield "sometext"
> mkp.yield myNode.tag."@attr"
> mkp.yield "more text"
> }
>
> if GString was Buidable we could write
>
> myTag "sometext ${myNode.tag."@attr"} more text"
>
> Has anybody got any objections/comments on this?


No objection, and moreover, it brings a nice improvement to the
streaming builders.


--
Guillaume Laforge
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Making GString Buildable

tugwilson

On 3 Nov 2005, at 13:30, Guillaume Laforge wrote:

>
> No objection, and moreover, it brings a nice improvement to the
> streaming builders.


Ok - It's in CVS HEAD - if anybody has problems with it please sing out


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Making GString Buildable

Guillaume Laforge
Administrator
On 03/11/05, John Wilson <[hidden email]> wrote:
> On 3 Nov 2005, at 13:30, Guillaume Laforge wrote:
> > No objection, and moreover, it brings a nice improvement to the
> > streaming builders.
>
> Ok - It's in CVS HEAD - if anybody has problems with it please sing out

It's very specific to the streaming builder, isn't it? ("mkp", "yield"...)
Can't the good ol' MarkupBuilder benefit from that as well in some
form or another?

--
Guillaume Laforge
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Making GString Buildable

tugwilson

On 3 Nov 2005, at 16:15, Guillaume Laforge wrote:

> It's very specific to the streaming builder, isn't it? ("mkp",  
> "yield"...)
> Can't the good ol' MarkupBuilder benefit from that as well in some
> form or another?


It's pretty easy to make the old Builder understand Buildable  
objects. All that's needed is an adapter class that understands the  
protocol:

getProperty("mkp") -> the next call is not going to define a tag -  
treat it specially
invokeMethod("yield", new Object[]{value}) -> dump the value into the  
output document (if it's Buildable let it dump itself)


There are only a handful of methods in the mkp namespace (yield,  
yieldUnescaped, comment, pi, declareNamespace, declareAlias,  
getNamespaces) so the implementation is not demanding. As the old  
MarkupBuilder does not implement namespaces PIs, comments, aliases or  
unescaped output thhere is really only one method which needs to do  
anything.



John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Making GString Buildable

Guillaume Laforge
Administrator
On 03/11/05, John Wilson <[hidden email]> wrote:

> It's pretty easy to make the old Builder understand Buildable
> objects. All that's needed is an adapter class that understands the
> protocol:
>
> getProperty("mkp") -> the next call is not going to define a tag -
> treat it specially
> invokeMethod("yield", new Object[]{value}) -> dump the value into the
> output document (if it's Buildable let it dump itself)
>
>
> There are only a handful of methods in the mkp namespace (yield,
> yieldUnescaped, comment, pi, declareNamespace, declareAlias,
> getNamespaces) so the implementation is not demanding. As the old
> MarkupBuilder does not implement namespaces PIs, comments, aliases or
> unescaped output thhere is really only one method which needs to do
> anything.

Okay, I see...
And could those markup methods be put in some constants pool? Like an
interface defining them? "yield", "mkp", etc...

--
Guillaume Laforge
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Making GString Buildable

tugwilson

On 3 Nov 2005, at 16:41, Guillaume Laforge wrote:

> Okay, I see...
> And could those markup methods be put in some constants pool? Like an
> interface defining them? "yield", "mkp", etc...


Sorry I don't understand. You mean putting them as final statics in  
Buildable?

You could do that I suppose but what would it buy you? You can never  
change their spelling without breaking markup closures in the field.  
These are really keywords if you change them you break people's  
programs.


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Making GString Buildable

Guillaume Laforge
Administrator
On 03/11/05, John Wilson <[hidden email]> wrote:
> Sorry I don't understand. You mean putting them as final statics in
> Buildable?

Yes, for instance.

> You could do that I suppose but what would it buy you? You can never
> change their spelling without breaking markup closures in the field.
> These are really keywords if you change them you break people's
> programs.

But if some day you add / change / remove one of these constants in
your streaming builders, the classical builders might break. That's
why I was thinking of factoring them out somewhere.

--
Guillaume Laforge
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Making GString Buildable

tugwilson

On 3 Nov 2005, at 16:54, Guillaume Laforge wrote:

> But if some day you add / change / remove one of these constants in
> your streaming builders, the classical builders might break. That's
> why I was thinking of factoring them out somewhere.


As I explained, it's impossible to change these without breaking user  
code which is outside my control.

  In principle you could change the Groovy 'if' keyword to 'lest'.  
You would not do it because you would break all the Groovy code in  
the world. Likewise you could change "yield" to "insert" but you  
would not do it because you would break all the builder closures in  
the world.

It make perfect sense to put a level of indirection on values that  
can change but it just adds unneeded complication to do it when they  
cannot change.

John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

RE: [groovy-dev] Making GString Buildable

Dierk König
I would also appreciate having all keywords in one place
and be it only for documentation...
Currently they are used in very different place like
groovy.util.slurpersupport.Node
and
groovy.xml.streamingmarkupsupport.BaseMarkupBuilder.
Do they mean the same thing in both places?

BTW: what does 'mkp' mean? 'markup'?

cheers
Mittie

> -----Original Message-----
> From: John Wilson [mailto:[hidden email]]
> Sent: Donnerstag, 3. November 2005 18:01
> To: [hidden email]
> Subject: Re: [groovy-dev] Making GString Buildable
>
>
>
> On 3 Nov 2005, at 16:54, Guillaume Laforge wrote:
>
> > But if some day you add / change / remove one of these constants in
> > your streaming builders, the classical builders might break. That's
> > why I was thinking of factoring them out somewhere.
>
>
> As I explained, it's impossible to change these without breaking user  
> code which is outside my control.
>
>   In principle you could change the Groovy 'if' keyword to 'lest'.  
> You would not do it because you would break all the Groovy code in  
> the world. Likewise you could change "yield" to "insert" but you  
> would not do it because you would break all the builder closures in  
> the world.
>
> It make perfect sense to put a level of indirection on values that  
> can change but it just adds unneeded complication to do it when they  
> cannot change.
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
12