At 20:13 29/04/2001 Sunday, you wrote:
>Spike,
>
>So, the edit handler for the object you're editing actually invokes the PLP
>that takes care of the editing, correct?
Yes, that's correct.
>Makes sense as an approach.
For what you are doing it may be best to create a 'null' type that doesn't
do anything other than allow you to invoke the handlers for other objects.
If you create a type with a single custom method called invoke you can do
pretty much what you want from within the handler for that method. If you
then use this in your workflow you have the ability to dynamically change
the type that actually gets edited from within the PLP.
Alternatively you could create a method for the 'null' type corresponding
to each method that you want to be able to invoke on your types from within
the PLP.
I'm not sure if there is another easy way to do what you want.
>But, there is a slight twist in the way we're doing this. When you're
>editing the first step of the PLP allows you to choose the Object you want
>to edit. The second step then invokes the edit handler for that object. (The
>third step displays what the object will look like, i.e. runs the Display
>handler.) The PLP is run in a tabbed interface that allows the user to flip
>easily between the steps. This allows the PLP to be generic in that the same
>PLP can be used to manage the edit process for a variety of Types.
>
>when you're creating, the first step of the PLP allows you to choose which
>type of object you want to create, the second step invokes the edit handler
>in the newly created object. (the third step is the same.)
>
>Under the above scenario, it seems to me it would be more difficult to store
>the ObjectID in the workflow -- or to make the object the artifact of the
>workflow as you've suggested.
>
>Given the above additional data, do you have any suggestions? (Of course,
>your suggestion may be to redo the way the PLP behaves! :-))
>
>David
>
>-----Original Message-----
>From: Spike [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, May 01, 2001 12:29 PM
>To: Spectra-Talk
>Subject: Re: workflows and PLPs
>
>
>A fairly standard thing to do would be to create a workflow with 2 tasks.
>Each task invokes a method on the object type.
>
>The first task creates the object using and edit method and the second task
>edit/approves the object using an edit_approve method. Either of these
>method handlers could call a PLP as you suggested. In the action area of
>the edit_approve method you would check if the object had been approved and
>if not use cfa_taskredo to go back to the previous step.
>
>Spike
>
>
>At 19:14 28/04/2001 Saturday, you wrote:
> >This, or some version of it, may have been asked in the past, but I didn't
> >find a thread addressing this exact situation.
> >
> >We're using a PLP to edit content items (CI's) because the CI's require a
> >multi-step process. I need to control the PLP -- or at least would like to
> >do notifications about it -- using a workflow.
> >
> >For example, suppose an Editor finishes editing the CI (using the PLP). I
> >now want a workflow to send notification to the Publisher that she needs to
> >review and okay/not okay publication.
> >
> >The Publisher, when she receives notification that the CI is ready to be
> >reviewed will kick off her task which will invoke the edit CI PLP (because
> >she has access to edit it too). When the Publisher runs the PLP, it will
> >display an additional button, not available to editors, that allows the
> >Publisher to publish the CI.
> >
> >The Publisher may 'not okay' the CI in which case notification should be
> >sent back to the Editor. Given that scenario, it seems that the first step
> >of the above (the Editor editing the CI) should also be driven by a step of
> >a workflow.
> >
> >In that case, that seems to argue for the creation of a workflow when the
> >Editor says he wants to edit a CI. When the workflow starts, the first step
> >would NOT send a notification (since the Editor obvious knows he wants to
> >edit something:-) ) but would invoke the PLP.
> >
> >Then, when the Publisher sends the CI back to the Editor to do more edits,
> >the first step will need to send notification. It will also need to invoke
> >the PLP again when the Editor starts the task.
> >
> >What this seems to require is the ability to kick off a PLP from within a
> >workflow task step. I'm not sure the best way to do this since the only
> >action a task can take is to invoke a method on an object -- and there is
>no
> >obvious object here. We have the object that is being edited, but it seems
> >odd to invoke a method on that object as the only action would be to invoke
> >the PLP. That seems potentially confusing.
> >
> >Another approach might be to use an 'artifactless' workflow and just write
> >specialized code that kicks off the PLP when the individual tasks start.
> >When the PLP ends, then the PLP would need to send a message back to code
> >that would end the task and refresh the workflow.
> >
> >Hopefully, the above makes sense. Anyone have experience with this kind of
> >thing and, if so, any suggestions on best practices?
> >
> >Thanks!
> >
> >David
> >
> >
> >
> >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
