On Sep 7, 2006, at 6:01 PM, Chris Miner wrote:
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?
So we go for A). And C) would probably be a waste of time. But we
need to organize the team so that not both are doing the same thing.
The big question is: will solution A) be a part of 3.0 or not.
Perhaps John has some estimations about when he planed to work on this.
The goals are:
- save the workitem using nodes and properties
- do it in a way that the dialogs are useable to change a workitem
(single properties are for free, however the question is how we
handle maps and lists (multivalues).
- on the wokitem we define an attribute which defines the edit dialog
used in the inbox to edit the workitem.
This allows changing the dialog during the workflow process
This will make it very powerful in the end.
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
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
