Am Freitag, 8. September 2006 20:24 schrieb Philipp Bracher:
> On Sep 8, 2006, at 5:14 PM, Chris Miner wrote:
> > I had some troubles implementing a dialog save handler combo that
> > worked to
> > extract values from a work item during dialog presentation and back
> > them back
> > in the workflowitem afterward during the save process.
>
> Perhaps I can deliver you some hints (not sure if there are obstacles
> we have to remove first)
Well, to get started, I simply dealt with the single comment field. I
imagined extending this solution to discover what fields are required by the
dialog, and copy those as needed into the DialogControlImpl tree. Something
like:
public void renderHtml(String view) throws IOException {
if (view == VIEW_SHOW_DIALOG) {
InFlowWorkItem workItem = WorkflowUtil.getWorkItem(path);
Dialog dialog = getDialog();
Iterator iter = dialog.getControls();
while (iter.hasNext()) {
DialogControlImpl control = (DialogControlImpl)
iter.next();
control.setValue(workItem.getAttributes().sget(control.getName()));
}
}
super.renderHtml(view);
}
I used DialocControlImpl instead of the interface DialogControl because the
interface doesn't expose much in the way of api. It has init and renderHtml.
However it probably should include some other methods common to GUI controls.
Anyway that is a side issue.
the getControls() method would then do something via getSubs to assemble the
list of controls. Perhaps it would be better to access Dialog values via
keys in a Bean like fashion?
On the save side of things, I'd do something similar.
>
> > Since the workflow item is actually stored as a node under something
> > like: /flow/1.x/63/1157640296863/participant/0.0.1 I wonder if it
> > wouldn't
> > make sense to simply add another attribute like participant, value,
> > and ID to
>
> No this would then not be a part of the workitem! This additional
> attributes are used by magnolia but not by the OpenWFE Engine. The
> information would never reach the engine. This is exactly why it
> would be nice if we store the workitem using jcr instead of
> persisting the workitem serialized to an xml in a single property.
Ah I see. I did realize the values would not be part of the workflow item,
and seemed to only be there to assist in the inbox query, but I didn't think
about it from the perspective of workflow logic. Yeah, that wouldn't be as
useful as I had imagined.
>
> > this node and use that to store data associated with the workflow
> > item as it
> > courses its way through the system? Say content attribute which
> > would hold a
> > mgnl:content node.
> >
> > Then I could use the existing dialog machinery as is. But would
> > have to copy
> > this important collection of data as the flowitem was saved.
> > Otherwise this
> > seems like a logical and simple extension to the existing
> > solution. Just
> > adds the concept of a workflow item having a content node.
>
> Ok, I see your intention, but I think this is just a workaround. It
> will be difficult (not unpossible) to use this information in the
> workflow definition. Therefore I suggest to use the woritem as it is
> foreseen.
Right, I see. My solution isn't really practical.
>
> Perhaps we should really wait until John was able to make the
> solution A) working.
>
It is looking that way.
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
