Hello Gavin, hello Jan, Since we were mentioned, a quick note on this from our point of view:
Our customer works with a very large number of editors, many of whom do not have strong computer skills. Even tasks that seem basic to us developers, like finding content in the trees based on the node-names, is a challenging task for some editors. We found magnolia's GUI problematic in this respect for 2 reasons: 1. When using "upload" images, assets for a page would be published along with the page. This is easy for editors, but the assets belonging to a page cannot be found again later, except in JCR Browser (which our editors of course don't get to see) or via the dialogs they were uploaded in. Also, working with upload images makes reuse of image-content more or less impossible. 2. When using "dms" images, assets are nicely separated and organized in the DMS tree, content-reuse is possible, but the activation is problematic: now editors have to remember which images they put in dms to go with their web-pages, and activate them separately. First we looked at "automatic activation" of dependent content - but I rapidly discarded this idea as too complicated. How to report back to the user in case of error? How to handle complex cases like timed activation? Instead, we settled on the following: We use DMS for all assets. For all "referenced content", like images and downloads, we added little status indicators (red/yellow/green) in the page-editing view. So now when you add an image to a webpage, you can immediately see the activation status of that image. In addition, clicking on the status indicator opens a dialog showing the content-dependencies (see below). Next to status indicator is a little drop-down menu, allowing the editor to activate/deactivate the image or download directly from within the webpage. So using this, our editors can see the status right away, and if they need to, can activate or deactivate right away. In addition, we extended the content dependencies to cover a wider array of use cases. Basically, when activating content, you would like to ensure that all referenced content is also activated. This is done by checking the referenced content on the author instance. When deactivating or deleting content, you would like to ensure that no other content references the content you are deactivating - but this check needs to be done on the public instance. So we extended the content dependencies to cover these different cases - checking my references, checking references to me, both on author and on public instances. In addition our implementation supports AJAX (since this checking dependencies can take a few seconds) and supports forwarding the public instance checks via the author instance, since the editor workstations can't talk directly to the public instances. If you have any questions about all this, I would be pleased to answer them. Regards from Vienna, Richard -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Jan Haderka (via Magnolia Forums) Gesendet: Donnerstag, 26. Juli 2012 09:58 An: Magnolia Dev List Betreff: [magnolia-dev] Re: Java-based link checker implementation What I found even better was what was shown by LFRZ (?) guys during Prague MUG - when in edit mode, they show bar at the bottom of the page that lists all resources used by the page and allow you to select which of them (if not all) should be activated together with the page. What we show in the inbox by using Content Dependencies module is going in that direction that you can see what is or is not activated and is used by the page, but is nowhere near. BTW that code was actually previously donated by Aperto. I'm not sure if they have anything on top of that. -- Context is everything: http://forum.magnolia-cms.com/forum/thread.html?threadId=8490f4c0-709c-4efa-a1de-dc3a46c576bb ---------------------------------------------------------------- For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
