[Yanel-dev] Storing reviewer comments with workflow transitions

[Nigel Runnels-Moss]

Thanks Michael, that's very helpful. I don't think we require a record of
revision rejection reasons, so setting a property on the revision file would
be fine.

Nigel
-- =


On Wed, Nov 3, 2010 at 9:16 AM, Michael Wechner
<michael.wechner at wyona.com>wrote:

> Hi Rob
>
>
> On 11/2/10 7:06 PM, Rob Adamson wrote:
>
>> Hi,
>>
>> I am implementing a workflow where a reviewer can approve or reject an
>> item, but if rejecting, has to enter the reason why, so that the
>> author can make the necessary changes.
>>
>> I am implementing this using a custom form&  resource type. The form
>> displays the details of the transition, and prompts the user to enter
>> the reason.
>>
>> Q1. I assume that I should call WorkflowHelper.doTransition in
>> response to the submission of my custom form, in order to actually
>> apply the transition. Is this correct?
>>
>
> Not quite, because the WorkflowHelper is just an implementation, but
> you should rather call the interface:
>
> WorkflowableV1 workflowable =3D (WorkflowableV1)resource;
> workflowable.doTransition(transition, revision);
>
> Also it depends what the follow-up screen should be.
>
> 1) If you want to use the generic one, then your custom form could call
> something like
>
>
> http://127.0.0.1:8080/yanel/MY_REALM/events/2010/example.html?yanel.resou=
rce.workflow.transition=3Dreviewer_approves&yanel.resource.revision=3D12887=
74938391&yanel.resource.workflow.transition.output=3Dxhtml
>
> which means Yanel will do the Job for you, whereas in particular
>
>
> src/webapp/src/java/org/wyona/yanel/servlet/YanelServlet.java#executeWork=
flowTransition()
>
> 2) If you want to have a custom follow-up screen, then you should impleme=
nt
> a custom method similar
> to the YanelServlet.java#executeWorkflowTransition(), but try to prevent
> calling the implementation directly.
>
>
>  Q2. What are my options for storing the reason text provided by the
>> reviewer?  I need to persist this with the ability to retrieve it for
>> displaying to the author on another screen.
>>
>
> Since each revision of a node can have a workflow instance I would suggest
> to attach
> it to the revision as a property, e.g.
>
> Revision revision =3D
> getRealm().getRepository("/events/2010/example.html").getRevision(REVISIO=
N_NUMBER);
> revision.setProperty("reject-message", REJECT_MESSAGE);
>
>
>
>  Q3. How to I look up the reason text? (depends on the answer to Q2).
>>
>
> Revision revision =3D
> getRealm().getRepository("/events/2010/example.html").getRevision(REVISIO=
N_NUMBER);
> String rejectMessage =3D revision.getProperty("reject-message");
>
> Please note that this does not provide you with a history of reject
> messages, but rather is going to be overwritten, because revisions do not
> have revisions themselves.
>
> If this would be required, then you rather put it into a node by itself by
> using some unique mapping, e.g.
>
> /workflow-history/events/2010/example.html_rREVISION_NUMBER.xml
>
> HTH
>
> Michael
>
>  Regards,
>>
>> Rob
>>
>
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010110=
3/da53154a/attachment.htm