org.squashtest.tm.service.internal.library
Interface NodeDeletionHandler<NODE extends org.squashtest.tm.domain.library.LibraryNode,FOLDER extends org.squashtest.tm.domain.library.Folder<NODE>>

All Known Subinterfaces:

CampaignNodeDeletionHandler, RequirementNodeDeletionHandler, TestCaseNodeDeletionHandler

All Known Implementing Classes:

AbstractNodeDeletionHandler, CampaignDeletionHandlerImpl, RequirementDeletionHandlerImpl, TestCaseNodeDeletionHandlerImpl

public interface NodeDeletionHandler<NODE extends org.squashtest.tm.domain.library.LibraryNode,FOLDER extends org.squashtest.tm.domain.library.Folder<NODE>>

This interface describes the contract for handlers responsible for deleting domain objects. Deleting an object is not straight forward since one have to deal with the relationships among them, eg a TestCase and a Requirement being bound together. As a consequence the application must perform several checks beforehand in order to decide the actual course of action.

As of Squash TM version 1.0, the specifications are the following :

1. when requesting a remove operation the user must be informed of its consequences,
2. when a user marks a node for deletion its children is included implicitly,
3. depending on which relationships might be broken by removing one or several domain objects the operation might be allowed, allowed with a warning or denied,
4. the batch removal is not atomic, eg when a subset of the operations are allowed while a second subset is denied, then the first subset will be processed anyway.

The details of what is green, orange or red depends on the implementation and will not be discussed here.

For the rest of this documentation let the nodes which can be deleted without consequences be the 'green nodes', those generating warnings the 'orange nodes' and those that cannot be deleted be the 'red nodes'. Let the node expressly selected by the user be the 'input nodes', the input nodes and their children be the 'candidate nodes', and the nodes that can be removed (ie green and orange) the 'okay nodes'.

Author:

bsiri

Method Summary

OperationReport	deleteNodes(List<Long> targetIds) (see above for definitions) That method perform actual node deletion.
List<SuppressionPreviewReport>	simulateDeletion(List<Long> targetIds) (see above for definitions) That method should investigate the consequences of the deletion request, and return a report about what will happen.

Method Detail

simulateDeletion

List<SuppressionPreviewReport> simulateDeletion(List<Long> targetIds)

(see above for definitions) That method should investigate the consequences of the deletion request, and return a report about what will happen. It accepts the list of input node ids and should return a list of SuppressionPreviewReport. A SuppressionPreviewReport hold informations regarding orange and red nodes. As of version 1.0 and until further notice, the green nodes generate no information. In other words if all the selected nodes are green node the returned list will be empty. Note that this method should not actually perform the deletion, and should first calculate then include all the candidate nodes.

Parameters:

targetIds - the ids of the input node.

Returns:

a list of SuppressionPreviewReport.

deleteNodes

OperationReport deleteNodes(List<Long> targetIds)

(see above for definitions) That method perform actual node deletion. It accepts the list of input node ids and returns the okay node ids. For various reasons (security, practical use in stateless apps etc) that method should must again and separate the okay nodes from the red nodes, and then remove the okay node only. Note that if should first calculate then include all the candidate nodes before filtering them.

Parameters:

targetIds - the list of node ids selected by the user.

Returns:

an OperationReport saying what happened.