[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Extending Builders with custom code
From:       daniel.fuchs () oracle ! com (Daniel Fuchs)
Date:       2012-06-28 9:03:08
Message-ID: 4FEC1DCC.7030207 () oracle ! com
[Download RAW message or body]

Hi Michael,

As you noted making Builders immutable would break
backward compatibility.

Another interesting alternative could be to generate an
applyTo() method that takes another builder as parameter.

I am wondering whether the following would be doable:

For instance - today TextBuilder has a method:
   public void applyTo(Text x)

If it add an additional
   public (or even protected)  void applyTo(TextBuilder otherBuilder)

then we could possibly also generate a:

   public static TextBuilder create(TextBuilder initialConfiguration) {
	final TextBuilder newBuilder = create();
         initialConfiguration.applyTo(newBuilder);
         return newBuilder;
   }


Your example would then become:

final Text text1 = TextBuilder.create(builder).text("Hello 
World!").y(50).build();
final Text text2 = TextBuilder.create(builder).text("Goodbye 
World!").y(100).fill(Color.GREEN).build();
final Text text3 = TextBuilder.create(builder).text("JavaFX is 
fun!").y(150).build();

I believe it would address your requirement without introducing any
backward compatibility issue.

Just thinking out loud...

-- daniel


On 6/28/12 9:43 AM, openjfx-dev-request at openjdk.java.net wrote:
> From: Michael Heinrichs<michael.heinrichs at oracle.com>
> Subject: Re: Extending Builders with custom code
> 
> Hi Evo,
> 
> there was an interesting comment after one of my blog posts about reusing builders. \
> Basically the commentator pointed out that making builders immutable would make \
> them much better suited for reuse. The obvious solution, changing our builders, \
> would break backward compatibility. But maybe you (or somebody on this alias) has a \
> good idea how this can be achieved without breaking backward compatibility. Below \
> is the full comment. 
> Cheers,
> Michael
> 
> 
> 
> Thanks for the post. I can clearly see the benefits of using builders and we have \
> been using them in some areas in our code. Your post made me realize that reusing \
> builders can be really powerful. Our application has a number of TableViews and \
> each view has a number of columns. The builders are a perfect fit for the scenario \
> where you want to create a number of columns that have many properties in common. \
> You can use a TableColumnBuilder to create partial specification for the column and \
> then stamp out the columns by setting the unique properties for each column and \
> build() them (Similar to your text1, text2, text3 example above). The only problem \
> is builders are not immutable. Every time you set a property on the builder it \
> affects all future build events. In you example above, if you only want text2 to be \
> green it would be nice if you were able to call it as follows: 
> final Text text1 = builder.text(?Hello World!?).y(50).build();
> final Text text2 = builder.text(?Goodbye World!?).y(100).fill(Color.GREEN).build();
> final Text text3 = builder.text(?JavaFX is fun!?).y(150).build();
> 
> But this results in both text2 and text3 turning green.
> 
> I think making builders immutable will significantly improve the ability to reuse \
> them. Consider the following example: 
> TableColumnBuilder standardColumnBuilder = TableColumnBuilder.create()
> .prefWidth(50.0)
> .sortable(false)
> .editable(false);
> TableColumnBuilder narrowColumnBuilder = standardColumnBuilder
> .prefWidth(40.0)
> .resizable(false);
> TableColumnBuilder narrowColumnBuilder = narrowColumnBuilder
> .prefWidth(80.0);
> 
> If builders were immutable I would now have three templates that I could reuse to \
> build all the table columns but because they are not immutable I now have a \
> ?standardColumnBuilder? that is not resizable and has a width of 80. 
> Cheers,
> Ab
> 
> 
> 
> On 27.06.2012, at 17:50, Eva Krejcirova wrote:
> 
> > > Hi All,
> > > 
> > > I am currently working on a system for extending our automatically generated \
> > > Builder classes with custom code and I would like to ask for your help. Are you \
> > > missing some convenience methods in existing builders? I would be happy to hear \
> > > it! (preferably in a form of Jira issue ;-)) 
> > > Currently we have these Jira issues:
> > > * RT-19266 which talks about PathBuilder (adding moveTo(), lineTo() methods to \
> > >                 PathBuilder)
> > > * RT-16569 mentions the need for convenience methods in builders of layout \
> > > classes (but doesn't specify it more) 
> > > Thanks,
> > > Eva


[prev in list] [next in list] [prev in thread] [next in thread]