[TYPO3-dev] Moving pages in workspaces - brainstorm

[Martin Schoenbeck]

Hi Kasper,

Kasper Skårhøj schrieb:

> 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'ld argue against this solution. I think it will at least be difficult if
not impossible to find all references to this page including them hidden in
an obscure extension. And it will render workspaces useless, if you can't
be sure it will go live exactly as it was tested before.

> 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!

The main problem AFAICS is to get all unchanged pages and parts of pages
seen in workspaces without having to copy them in advance. If you make a
complete copy of the whole database, nothing would be difficult but
creating workspaces where getting very expensive on large websites. So why
not implementing sort of 'copy on demand'. To keep performance impacts low,
it has to be easy to tell livespace parts (pages etc.) from those of a
workspace.

As a result we'd need some additional states: livespace, livespace but not
workspace, workspace. 'livespace' of course could be the actual state used
to show pages and elements. Any time an element is changed within a
workspace it is copied having an element with 'livespace but not workspace'
and an element with 'workspace'. This way it's very easy to select all
livespace elements (simply take 'livespace' and 'livespace but not
workspace') and it's easy to select all workspace elements (take
'livespace' and 'workspace). Now the real change can be done to the
workspace element and it can be any change you want, even moving it around.

Of course we do have more than one workspace. My first idea was to create a
copy for each workspace as soon as the first copy is done. But then a
workspace had to live with an old version if the livespace is changed or
changing the livespace had to create new copies. Better to create only the
actual necessary copy and also create an additional table in which for
copied elements for each workspace an entry is made, whether this element
lives in livespace (has status 'livespace but not workspace' which now
better could be named 'livespace but not all workspaces') or in this
workspace (has status 'workspace'). Of course the elements of the latter
type have to contain an id of the workspace.

Because livespace only have to check the status 'livespace' and 'livespace
but not all workspaces', but not the table connecting workspaces to
elements, the performance penalty will be neglectable. Workspaces have to
present element with 'livespace' status, elements with 'livespace but not
all workspaces' status if the connecting table tells, this workspace uses
that status and elements with 'workspace' status and their workspace id, if
the connecting table tells that. Therefore workspace will be a bit slower
but due to the selection being straight forward it will be not much.

The connecting table could even be one table for all element tables,
containing the name of the target table in each entry. Then it could be
easy to adopt this even for tables created by extensions. 

Going live will have to check, whether there exist other 'workspace' copies
of this element. If not the 'livespace but not all workspaces' copy will be
dropped an the new element get the status 'livespace', otherwise it will
take over the 'livespace but not all workspaces' status. The connecting
elements have to be dropped in the first case, that of this workspace has
to be changed in the latter.

> 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.

My knowledge of the inner TYPO3 is not so deep, I fear to miss an important
point, because the solution seems to be so simple. But perhaps it's an idea
to build on.

Regarding Amelia: Congratulations and may God bless you and your family.
There will be joy and fear, proudness and anger (I've three, the youngest
18, I know what I'm talking of ;-) ), but if you don't lose your faith in
Jesus you'll have no real problems.

Martin
-- 
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.