fluent setters in generated code and comment on JavaGenerator

135 views
Skip to first unread message

Darren S

unread,
Jan 6, 2014, 1:19:40 PM1/6/14
to jooq...@googlegroups.com
As the jOOQ docs clearly state, fluent setters violate the Java Beans spec.  It would be a nice feature to have the generator generate fluent setters with a different style.  So, for example, setName(...) still returns void, but with fluentSetterStyle="with" it would generate withName(...) also.  I've generally seen two styles of fluent setters 1) prefix with "with", or 2) just name the method the same as the variable, like name().

I'd like to extend the JavaGenerator to add this behavior but there is a where I have a general complaint with the JavaGenerator implementation.  The extends points in JavaGenerator are often at too much of a macro level.  For example, you can override generatePojo().  Internally though generatePojo will generate the class definition, fields, and methods.  So if I just want to do something like add a fluent setter, if would be nice if generatePojo() was more like

void generatePojo() {
  generatePojoClass(...)
  for ( .. fields .. ) {
    generatePojoField(...)
  }
  for ( .. methods ... ) {
    generatePojoMethod(...)
  }
}

That way I could just override a small portion of the generatePojo logic without having to fully override the method.

Darren

Lukas Eder

unread,
Jan 6, 2014, 1:25:06 PM1/6/14
to jooq...@googlegroups.com
Hi Darren,

I agree, fluent setters may be useful. I've thought about this before, but stumbled upon the following caveats:

- Generating additional setters (using "with" or no prefix) will lead to a variety of changes also to the GeneratorStrategy, where "fluent" setters would have to be handled in addition to "regular" setters.
- The GeneratorStrategy itself cannot be used. While it can be used to rename the prefix from "set" to "with", the method still returns void

But you do have a simpler option, if you're fine with having setters *and* fluent setters. You can override the JavaGenerator's generatePojoClassFooter() method. This is documented here:

That might be good enough as a solution for this specific requirement?

Cheers
Lukas


2014/1/6 Darren S <darren.s...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Darren S

unread,
Jan 6, 2014, 1:52:29 PM1/6/14
to jooq...@googlegroups.com
I didn't see the generatePojoClassFooter(), so yes I think that will work.  It would still be nice if the feature was built in.  But I understand your thoughts here.  I noticed basically the same thing.  It seems to me that if you wanted to implement it, then fluent setters should be more of a first class citizen and not a modification upon setters.  Meaning that you'd have a GeneratorStrategy.getJavaFluentSetterName().

Do you have any inclination of how used that feature is?  I really don't find it particularly useful to violate the java bean spec.  Is there you any chance you could deprecate the current approach of modifying the existing setter and then add the feature to generate fluent setters in addition to standard setters.  I'd like to encourage people to use the method chaining style as I think it leads to more readable code, but I couldn't recommend it on the basis that the current approach will not long be a valid java bean.

So I know I can override and do this myself, but I'd like to see something more generally useful.  I'd be willing to make this modification myself is there is some general approach you'd like to see.

Darren

Lukas Eder

unread,
Jan 7, 2014, 5:40:13 AM1/7/14
to jooq...@googlegroups.com
Hi Darren,

There is a large jOOQ 4.0 task to generally move away from JavaBeans without violating it:

Most of the jOOQ API uses this scheme here:
// Property
Type prop;

// Setter name
{void | Self} prop(Type prop);

// Getter name
Type prop();
This corresponds to your prefix-less setter, returning "this".

Nonetheless, it might still make sense to support these things in the code generator already in jOOQ 3.x, something along the line of what you wrote: GeneratorStrategy.getJavaFluentSetterName(). When activating this flag, the jOOQ generator would generate
// Property
Type prop;

// Setter names
void setProp(Type prop);
{Self} withProp(Type prop);

// Getter name
Type getProp();
I have registered #2934 for this:
Reply all
Reply to author
Forward
0 new messages