task component interface comments

[tom.baeyens]

Hi Alejandro,

1) i'ld like to make the user provided taskId optional. so i think it would be good to have an extra method

TaskService.newTask()

that creates a new task without id. upon saving such a task, the command will detect this and automatically assign an id based on the DB primary key that has been generated by the DB after saving it. That way you don't force users to think of how they are going to obtain a unique id if they just want to add a task.

2) all the setters in the task could return the task itself. also a save method could be added to the task that delegates to the saveTask of the service it came from. then you could get shorter, more readable task creations like this:

taskService.newTask()
 .setName("Do laundry")
 .setDueDate(tomorrow)
 .setAssignee("johndoe")
 .save();

WDYT ?

[jbarrez]

1) Definitely agreed!

2) You really like fluent interfaces ;-)
I like the idea, but I shouldn't (mis)use the getters for this purpose (ie not following the JavaBean spec).

[tom.baeyens]

"jbarrez" wrote:
2) You really like fluent interfaces ;-)
I like the idea, but I shouldn't (mis)use the getters for this purpose (ie not following the JavaBean spec).

i didn't think of violating javabean spec. but is that actually a problem ?

[jbarrez]

I don't think it is a real 'problem', but my for my feeling it seems wrong.

Isn't this 'more clean':

taskService.newTask()
.withName("TestTask")
.withDueDate(someDay)
.withActor("Joram");

This way you can have the fluent interface (which I agree is nice to have) and the setters. Downside is that that withXXX() methods are almost the same as the setters.

Ofc, this is just my opinion, perhaps I'm completely wrong on this one.

[tom.baeyens]

good idea, but i still like the setters more. as the setters can also be used in the normal way:

Task task = taskService.newTask();
task.setName();
task.setDueDate(someDay);
task.setAssignee("johndoe");
task.save();

that would be harder with the 'withXxx' methods

[aguizar]

Creating tasks without a user-provided ID is a must for usability. The generated ID will be the database ID converted to string.

As for task creation, I concur with Joram that (ab-)using the setters for a fluent interface goes against the JavaBeans design principles. Introducing a set of methods called withXXX to the Task interface is also a no-go because they mostly duplicate the setXXX methods.

I propose introducing a TaskBuilder buildTask() method to the TaskService, and move the withXXX methods to TaskBuilder. Actually I'd prefer to drop the "with" prefix, as follows.

Task task = taskService.buildTask()
 .name("test")
 .dueDate(today)
 .asignee(me)
 .done();

TaskBuilder does not even have to be an interface, because it simply delegates to methods in the Task interface.

[camunda]

Why so complicated? The setter with a return value doesn't break anything if you don't use the return value!

Why stick to conventions without benefit and introducing additonal components to come around with it?

I would vote for the setXXX with returning the object approach proposed by Tom...

[kukeltje]

The setter with a return value doesn't break anything if you don't use the return value!

Is that still the case with all these reflection-using frameworks? If so I'm in favour as well

[camunda]

I think the return value is not part of the method signature, or is it?

[tom.baeyens]

TaskBuilder is definitely not good.

Task with setter is the way to go.

If we would not like the Task return value on the setters, then we should make them void and disable the fluent interface.

But that brings me to the point that I didn't see a good argument against return Task from the setters. the JavaBean spec and reflection frameworks arguments don't make sense in my opinion.

But it is not a big deal. Alejandro, you take your pick of the return values for the setters.

[aguizar]

Beyond the usual conventions, there are two things I dislike about returning Task from the setters:

1. the "set" prefix prevents a true "fluent" method chain. Compare the method chains with and without the TaskBuilder.
2. what if I want to add comments, subtasks, etc? the task interface does not have methods for that, you have to go back to the task service. The task builder can "remember" the task service that created it and invoke it internally.

task = taskService.buildTask()
 .name("report expenses")
 .due(today)
 .subTask()
 .name("gather receipts")
 .due(beforeLunch)
 .subTask()
 .name("capture amounts")
 .due(beforeLeaving)
 .done();

TaskBuilder is definitely not good. Task with setter is the way to go.

I got the TaskBuilder idea from the ProcessFactory that is already in the PVM module. How are they different?

[kukeltje]

I got the TaskBuilder idea from the ProcessFactory that is already in the PVM module. How are they different?

You got a point there...