To Freddy's point, I think method chaining would be nice, especially when dealing with large and complicated forms or tables. I won't argue that it'd be worth the API bloat one way or the other because I don't have to maintain the code.
But still, from a user's standpoint, it would be handy. On Wed, Mar 25, 2009 at 11:28 AM, Bob Schellink <[email protected]> wrote: > > florin.g wrote: >> >> In order to save Bob some breath, > > > Seems this feature was dropped from Java7. > > Going forward we can investigate where chaining would make sense. > > The column example does show where the pain points lie, however to properly > implement this would lead to quite a bit of API bloat. > > kind regards > > bob > > >> >> It's been discussed extensively with the conclusion that jdk 7 will >> address most of it. >> >> >> >> Hi all, >> >> There are some places in the Click API where, IMHO, users would >> benefit from the possibility of using method chaining. Briefly, this >> involves returning "this" from a method so that you can call another >> method on the same object. >> >> Here is an example with the Column class: >> >> Table table = new Table("table"); >> >> table.addColumn(new Column("id")); >> table.addColumn(new Column("name")); >> >> Column age = new Column("age"); >> age.setTextAlign("right"); >> table.addColumn(age); >> >> Notice that for the third column, we want to use a different text >> alignment. We have to break the flow and create a separate Column >> object. We also have to make up a name for the variable, and we end up >> needing 3 lines of code instead of 1. >> >> With a "Column textAlign(String align)" method that calls >> "setTextAlign(align)" and returns "this", we could write: >> >> Table table = new Table("table"); >> >> table.addColumn(new Column("id")); >> table.addColumn(new Column("name")); >> table.addColumn(new Column("age").textAlign("right")); >> >> I find this easier to write and easier to read. No need to break the >> flow. What do you think? >> >> Note that it is important *not* to change the original setter methods. >> These must remain of the form "public void setXyz(value)" to respect >> the JavaBean specification. The convention I've seen most often is to >> name the method-chaining versions of the setter methods simply by >> removing the "set" prefix. >> >> Of course, people who prefer using the setter methods can continue >> doing so. Since the method-chaining versions just call the >> corresponding setter method and return "this", backward-compatibility >> is preserved. >> >> If you like this idea of adding method-chaining versions of setter >> methods, of course there are likely other places in the Click API >> that could benefit. >> >> What do you think? >> >> Thanks, >> Freddy >> >> >> > >
