Hi Danilo!
Answers inline: -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Danilo Ghirardelli Gesendet: Freitag, 15. Juli 2011 10:00 An: Magnolia User-List Betreff: Re: AW: [magnolia-user] Joint edit of split content. > Basically, we extended all the controls we wanted to use, and added > logic to use an additional configuration property "paragraph" on saving. But this "paragraph" is a uuid link to any content or simply the paragraph type that is expected under the current content/page? Just to understand your system. And just out of curiosity, how "big" is your customization? You extended all the classes, but are they now thousands lines or is just a bunch of lines each? For us, the paragraph is a path (String) relative to the current page. It could have been implemented as a UUID, in theory, but this would probably make trouble with "new" dialogs (ie when creating new content). The extension is minimal, it is essentially this: @Override public void init(HttpServletRequest request, HttpServletResponse response, Content storageNode, Content configNode) throws RepositoryException { super.init(request, response, cmsEditorService.getControlStorageNode(storageNode, configNode), configNode); } As you can see, we simply provide another storage node on init... I think the method getControlStorageNode() also creates the node if necessary. (I didn't write this code myself). > We also added a control to edit the page-name in the dialog. We > configure the integrated dialog separately from the standard dialogs, > enabling us to present the fields in different order and reorder tabs. This means that the dialog should be always doubled... I did the same but keeping the original tabs, simply adding a "reference" property to link them, so if the original is changed the linked edit is automatically updated. Did you extend also the base class for the dialog ("configurableDialog" or some other in the hyerarchy)? Or were you able to do everything with only the configuration and the customized controls? Yes, we could also simply "reference" the orginial dialog-tabs to include them in the integrated dialog. But we found it is more flexible to recreate them, since then we can change the order, leave some fields out, etc, etc... Basically, we could use the reference if we want, but we don't want. > To implement this, we extended the DialogTab, DialogEdit, > DialogCkEdit, DialogUUIDLink, etc, etc, etc, controls, and override > the init() method to set a different storage node. Is this enough? No other modification is required except a storage node? In my approach I used the same idea, but the right storage node is passed to the init method by the custom dialog class in its init, while loading "subs". I'm still trying to understand if it's enough :-) And if the storage node is not yet available? Do you build it exactly as expected before passing it to the controls? Yes, we create the storage node in advance. As mentioned we also have a Dialog class which we use in the integrated dialog. The dialog class has its own save-handler. The save-handler is essentially like the standard SaveHandlerImpl, but overrides the save() method to inject the correct storage node when calling the controls save-handlers. It's not difficult, but it is a bit of a hack ;-) > Where we currently have stopped is with "collections" - when you can > add more than one paragraph, e.g. for multiple images with a > page-text, or to add multiple links to a page. There are no controls > currently implemented which could handle this logic, we would need to > dynamically add and remove fields from the dialog to allow the user to > add "multiple" elements of a certain type, and this seemed more > difficult, both from an implementation and GUI point of view. This seems to validate my hypothesis of you editing a single content relative to the page. My case is similar but the content is in a different repo, so I'll link it with uuid (another hidden property to save in the page). Maybe with JackRabbit 2 there will be some easier way to link content directly, as it was just a subnode of the page, that will be really nice in a lot of use cases. JackRabbit2 offers content-links, and can maintain associations between nodes in different workspaces. However, these features require support from magnolia's GUIs before they can be used by users. Unfortunately, the semantics of this kind of thing are VERY complicated. If you have linked nodes, what happens when the original is deleted? How do you deal with permissions? How do you make the GUI for maintaining links, in a way that normal editors can understand what's going on? etc... Regards from Vienna, Richard Regards, Danilo. ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]<mailto:[email protected]>> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
