+1
Christian
On 08.02.2013 09:12, Francesco Chicchiriccò wrote:
> On 08/02/2013 09:05, Jan Bernhardt wrote:
>> Hi syncoper,
>>
>> I do not even see methods in RoleService that should be moved into a
>> different ServiceInterface! Workflow controller is used in
>> RoleController but just for CRUD operations, no direct access, so
>> this is mostly transparent to user.
>>
>> But I completely agree with Christian, that direct workflow
>> operations identified by TaskID should be moved out of UserService.
>> They are used in context of users (currently) but can be used also in
>> other contexts. This is why I would move the following method to
>> WorkflowService:
>>
>> @POST
>> @Path("workflow/tasks/{taskId}/claim")
>> WorkflowFormTO claimForm(@PathParam("taskId") String taskId);
>>
>> @POST
>> @Path("workflow/tasks/{taskId}/execute")
>> UserTO executeWorkflow(@PathParam("taskId") String taskId,
>> UserTO userTO);
>>
>> @GET
>> @Path("workflow/form")
>> List<WorkflowFormTO> getForms();
>>
>> @POST
>> @Path("workflow/form")
>> UserTO submitForm(WorkflowFormTO form);
>>
>> Since this next method contains a userId but is related to workflow
>> activity, I'm not sure what to do with it. I guess is should remain
>> in UserService, to not have an dependency from WorkflowService to
>> UserService.
>>
>> @GET
>> @Path("{userId}/workflow/form")
>> WorkflowFormTO getFormForUser(@PathParam("userId") Long userId);
>
> Hi Jan,
> I think I've finally got your point - it took me some time, though..
>
> getFormForUser() is not the only workflow-related method explicitly
> referencing users (userId in that case); there is also
> executeWorkflow() with UserTO for example, but if you take a look at
> method implementation there is even more.
>
> Hence my proposal: let's call it UserWorkflowService and let's move
> all the methods above (including getFormForUser()) to this new service.
>
> WDYT?
>
> Regards.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
