Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 191896

Summary: LayoutEditPolicy should only contribute to requests related to its layout container
Product: [Tools] GEF Reporter: Alexander Nyßen <any>
Component: GEF-Legacy GEF (MVC)Assignee: gef-inbox <gef-inbox>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows NT   
Whiteboard:

Description Alexander Nyßen CLA 2007-06-11 04:06:59 EDT
Build ID: I20070323-1616
Currently, LayoutEditPolicy contributes to all requests from its host edit part, no matter what layout container the edit policy contributes to. 

This does not allow to have different edit policies for different layout containers belonging to a single edit part (as each edit policy will always contribute).

LayoutEditPolicy should indeed only contribute to those requests that affect edit parts whose figures are located inside its layout container (incase of a ChangeBoundsRequest) or where the creation location is inside its layout container (in case of a CreateRequest). 

To fix this, I would propose to change the getCommand method as follows:

@Override
public Command getCommand(Request request) {
  Command command = null;
  Request filteredRequest = filterRequest(request);
  if (filteredRequest != null) {
    command = super.getCommand(request);
  }
  return command;
}

public final Request filterRequest(Request request) {
  if (request instanceof CreateRequest) {
    // only process request, if the creation location is inside our
    // layout container
      if (getHostFigure().findFigureAt(((CreateRequest) request).getLocation()) == getLayoutContainer()) {
        return request;
      }
      return null;
    } else if (request instanceof ChangeBoundsRequest) {
      // filter out the edit parts that are moved/resized inside our
      // layout container
      List editParts = ((ChangeBoundsRequest) request).getEditParts();
      List filteredEditParts = new ArrayList();
      for (int i = 0; i < editParts.size(); i++) {
      if (((GraphicalEditPart) editParts.get(i)).getFigure().getParent() == getLayoutContainer()) {
        filteredEditParts.add(editParts.get(i));
      }
    }
    if (filteredEditParts.size() > 0) {
      // create a copy with the resulting edit parts
      ChangeBoundsRequest copy = new ChangeBoundsRequest();
      copy.setExtendedData(((ChangeBoundsRequest) request).getExtendedData());
      copy.setLocation(((ChangeBoundsRequest) request).getLocation());
      copy.setCenteredResize(((ChangeBoundsRequest) request).isCenteredResize());
      copy.setConstrainedMove(((ChangeBoundsRequest) request).isConstrainedMove());
      copy.setConstrainedResize(((ChangeBoundsRequest) request).isConstrainedResize());
      copy.setMoveDelta(((ChangeBoundsRequest) request).getMoveDelta());
      copy.setResizeDirection(((ChangeBoundsRequest) request).getResizeDirection());
      copy.setSizeDelta(((ChangeBoundsRequest) request).getSizeDelta());
      copy.setEditParts(filteredEditParts);
      return copy;
    }
    return null;
  }
  return null;
}

More information:
Comment 1 Randy Hudson CLA 2007-06-11 09:44:16 EDT
An editpolicy is not a targetable unit. You can create editparts for each layout container, even when there is no corresponding model object. Then your editpolicies would only be targeted when over those non-selectable editparts.

Alternatively, you can just return null when the location is not over that policy's layout container, although I believe layoutContainer is always supposed to be the host editpart's contentPane.

Your proposed change would affect lots of existing code.
Comment 2 Alexander Nyßen CLA 2007-06-11 10:55:38 EDT
Ok, then I will take care of this in my subclasses. 

Just thought it might be desired to have a general behaviour like this.