This project is mirrored from Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 15 Mar, 2021 1 commit
  2. 11 Mar, 2021 1 commit
  3. 10 Mar, 2021 2 commits
  4. 09 Mar, 2021 1 commit
  5. 08 Mar, 2021 1 commit
  6. 01 Mar, 2021 1 commit
  7. 10 Feb, 2021 1 commit
  8. 09 Feb, 2021 1 commit
  9. 08 Feb, 2021 1 commit
    • Benni Mack's avatar
      [TASK] Clean up Drag&Drop Handling in PageTree · 85c7264b
      Benni Mack authored and Georg Ringer's avatar Georg Ringer committed
      The PageTree components for the navigation area consists of:
      * PageTreeElement (container for rendering the navigation area w. toolbar + dragdrop + tree)
      * PageTreeToolbar (uses DnD for creating new items)
      * PageTree (JS, subclass of SvgTree)
      * PageTreeDragDrop
      This patch aims to rework the "PageTreeDragDrop" javascript file
      by moving separate logic into separate classes (as much as possible)
      and into a more stable API, being a first part.
      PageTreeDragDrop is a mixed code class currently,
      and is now split up in various separate classes:
      * DragDropHandler (interface)
      * ToolbarDragHandler -> used as the Toolbar Draggable Handler for new pages
      * PageTreeNodeDragHandler => used for moving/copying and deleting existing pages/nodes
      * PageTreeDragDrop now acts as a simple wrapper for d3-drag but still has some shared state
      For Future Reference:
      It is still up to decide on how to further decouple the code.
      Idea 1: Putting the d3-drag initialization into the right
      place and avoiding cross-dependencies. In general "initializeDragForNode"
      would also be handled via events, and all options / settings would be
      moved into the PageTreeDragDrop class.
      Ideally the PageTreeDragDrop contains the status of the
      current drag+drop action (position, node etc), so the PageTree
      would not know of anything itself.
      Idea 2: Another possibility is to use the current "PageTreeDragDrop"
      as a generic "TreeDragDropManager" because it does not
      contain any Page-Tree specific code anymore, but could be carried
      on later-on.
      The current change is already a good step as it moves all code
      to TypeScript and minimizes injection via constructors (except
      for the Tree itself).
      Resolves: #93446
      Releases: master
      Change-Id: Ibd7a067c1e6a821b138a8cc2971ec8133392b600
      Tested-by: default avatarTYPO3com <>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Tested-by: Georg Ringer's avatarGeorg Ringer <>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <>
  10. 04 Feb, 2021 1 commit
  11. 01 Feb, 2021 1 commit
  12. 29 Jan, 2021 1 commit