Am Mittwoch, 6. September 2006 17:40 schrieb Chris Miner: > Am Mittwoch, 6. September 2006 11:27 schrieb Philipp Bracher: > > Well .. no nice solution for that yet. The thing is, that we need to > > refactor the dialogs for that reason (they are only handling magnolia > > like content and quite inflexible). > > > > Current solution > > ---------------- > > - write you custom dialog handler where you populate the dialog using > > the info in the workitem > > - use a different save handler to write the values back to the > > workitem instead to a node > > > > Future solutions > > ---------------- > > A) We store the workitems in the magnolia way (same structure as > > paragraphs) this allows to use the dialogs to manipulate them > > (currently they are stored unfortunately as plain xml) > > > > B) We refactore the dialogs so that they read and store from any > > object (discussed here since a long time) > > > > C) Support the solution above (deliver such a dialog and save handler > > implementation) > > > > B is planed for 3.5 and A) would be wise anyway. C) could get done if > > you help to implement it > > Well this would be interesting since I need it anyhow, and it would be > interesting to see how more of this works through experience. Also I'd > probably end up with a better design/implementation. Unfortunately I am > not sure that I am currently in a position to contribute the work back to > the project. So I can't volunteer yet.
I am now sure I can contribute the work back to the project. Assuming there is still an interest in the dialog/save handler approach. I got started on it and didn't find it pretty. It mostly involves rewriting code that assumes access to a Content node. Also the Inbox related javascript (Inbox.js) has to be altered to provide the dialog handler with a key to the workflow item. I used the item id that is already delivered in the page, but one could imagine changing that to be path oriented, then use the path to get the content node that contains the workflow item. That would better match the usage of mgnlOpenDialog used elsewhere. There seems to be a lot of work done in the various process.... methods of SaveHandlerImpl. I think I need to write methods like the process... ones for my save handler, but naturally without the reference to a Content node. And the dialog handler has to step in during the renderHtml process to fill the dialog tree with data. Repetitively doing something like: DialogControlImpl sub = dialog.getSub(Context.ATTRIBUTE_COMMENT); sub.setValue(workItem.getAttributes().sget(Context.ATTRIBUTE_COMMENT)); except using the dialog control names. Something similar has to be done on the other end as well. I suppose it would also make sense to make the dialog and save handler repository aware. Anyway, is this still a good idea? I am thinking maybe it is. If someone can sketch out what I need to implement for a WorkFlowItemDialog and a WorkflowItemSaveHandler, so that it would be useful to others, I am happy to continue in that direction and contribute the work back to the project. Or maybe it would it be better/possible for me to contribute to the effort to Contentify the workflow items? Personally I like that solution better because it would work out of the box with the dialogs already as they are. What do others think? > > > Nicolas & John: what do you think about A) should we enforce that? I > > think there are other use-cases where we would like to have that > > Personally, I like the idea of having A) enforced. Presumably as the > infrastructure around getting node values and to and from the client is > improved, then the features around workitems would also benefit. > > > Philipp Bracher > > > > > > ---------------------------------------------------------------- > > for list details see > > http://www.magnolia.info/en/magnolia/developer.html > > ---------------------------------------------------------------- > > ---------------------------------------------------------------- > for list details see > http://www.magnolia.info/en/magnolia/developer.html > ---------------------------------------------------------------- ---------------------------------------------------------------- for list details see http://www.magnolia.info/en/magnolia/developer.html ----------------------------------------------------------------
