On Fri, 2009-09-04 at 08:20 +0200, Will Scheidegger wrote: > > On 04.09.2009, at 00:12, Danilo Ghirardelli wrote: > > > - Backpublishing, with the public instance that automatically > > publish its user generated content to the author one, so it can be > > published back correctly when the author edits something. This feels > > really unsafe (public instance must see and have access to the > > author one) and may lead to concurrency problems. > > Why is this unsafe? You do have the same security mechanisms that > apply to Magnolia in general. Simply restrict the rights to this > specific area which is updated by the user anyway. Or deny access > completely and have the superuser activate the content back to author. > > I don't see the great danger of concurrency problems either. There is > only one scenario that I can come up with, where we would actually > have a concurrency problem: > - Editor opens a record dialog in the author instance > - User at the same time edits and saves the same record on the public > instance > - The record is activated from the public instance to the author > instance > - Editor hits the save button in his admin interface dialog and > overwrites the new record > But > a) this would be quite a coincidence, right?
Coincidences happens. I'm willing to bet that should you put that into the real life you would experience it on moderately used app quite soon. > b) it could be fixed by a custom save handler of the dialog which > compares modification dates. Tricky but feasible I would say. I'd say this can be completely avoided by design. How? The user generated content goes into different workspace then the content made by the editor. This is for example the case with the commenting. While the comments appear on the same page visually, they live in separate space physically and their adding/editing/deletion is completely independent from the updates to the article on which comments are made. Similar solutions can be devised also for other scenarios. > > The "Backpublishing" option is the best IMO, if you actually need the > content on the author instance that is. I like this solution because > it is rather easy to set up and it is fully consistent with the > Magnolia setup. But maybe I'm really missing something, so I really > appreciate this discussion. > > -will > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- -- Best regards, Jan Haderka Magnolia International Ltd. Meet us at the Magnolia Conference http:/www.magnolia-cms.com/conference Magnolia® - Simple Open Source Content Management ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
