[TYPO3-dev] Moving pages in workspaces - brainstorm

[Kasper Skårhøj]

Hi Everyone.

Soon you will learn how powerful workspaces in TYPO3 version 4.0 is.  
Unfortunately you might be distracted by the fact that you cannot  
move a page or any other element in a workspace. Please do not obsess  
on this "problem" because it is really a tough one to solve. And  
therefore I would like to a) explain why I didn't even try to  
implement it and b) ask for any suggestions as to how it can be solved.

a) Why can't pages be moved in a workspace.
First: Editing, deleting, copying and creating are all possible in a  
workspace because they merely create a new version of the element in  
is _current_ position.
Moving is radically different because you want to change the location  
of an element.
You could of course use a technique similar to that of deleting  
elements in a workspace where we set a flag that tells the core to  
really delete the element at the time the element is published.
However, that is the smallest part of the problem. The REAL problem  
is to preview that flag in both frontend and backend!
Everytime you make a simple query like "SELECT * FROM pages WHERE  
pid=123 ORDER BY sorting" that selects all subpages of page 123 you  
would have to post-process the result and for each selected page ask:  
a) is this page moved to another location? and b) is some yet unknown  
page somewhere moved to this location? The problem grows even deeper  
when generating the rootline. And I have a gut feeling that we will  
discover even more complex problems during implementation than we can  
foresee now. Not to mention that such an implementation puts even  
more pressure on adapting extensions because they would have to  
implement this post-processing as well.
Deleting and creating new records are far simpler because they do not  
depend on such post-processing, only a WHERE clause like " "AND  
t3ver_state!=2" is needed to filter out a delete element. And that is  
supplied from the system APIs already. Further, missing to correct  
for deleted/created records is a non-critical bug contrary to a moved  
element which can affect rootline based TSconfig settings, page  
permissions (!!) etc.

b) Solving the problem.
I suggest that workspaces 1.0 will be used by everyone to consider  
what the most typically requested features of a workspace will be. No  
doubt moving will be one of them. The question is if a full-fledge  
transparent moving is necessary, one that includes previews and all.  
Or if we can manage it with a more specific implementation solving  
the 90% of problems.

One solution which has been put forth was, that moving could be  
implemented simply as a delete/create action: That is a) copy it to  
the new location and b) delete the element in the original location.  
Further moving will even be OK because newly created elements can (in  
fact!) be moved since they are new and therefore can move freely in  
the live workspace without affecting live content.
I could imagine such a compromise would work. We could even implement  
some sort of relation between the deleted original and created copy  
which makes sure that IDs are maintained during the publishing  
process. However, there will be some serious limitations to moving  
pages/branches still!

This is my abstract, let me know of any suggestions. You are welcome  
to take it easy and gain some experience using workspaces before you  
enter the debate.



- kasper

"A contribution a day keeps the fork away"
-------------------------------
kasper2006 at typo3.com | +45 20 999 115 | skype: kasperskaarhoej |  
gizmo: kasper_typo3