Forum OpenACS Development: Callbacks in Workflow

Carlos,

There are a couple of things that you have to do to get the side effect callback to work.

First you need to register your implementation.

ad_proc -private curriculum_central::install::register_uos_go_live_impl {} {
Registers a service contract implementation for UoSGoLive.
} {
set spec {
name "UoSGoLive"
aliases {
GetObjectType curriculum_central::uos::object_type
GetPrettyName curriculum_central::uos::go_live::pretty_name
DoSideEffect curriculum_central::uos::go_live::do_side_effect
}
}

lappend spec contract_name [workflow::service_contract::action_side_effect]

lappend spec owner [curriculum_central::package_key]

acs_sc::impl::new_from_spec -spec $spec
}

The above proc gets called after a package instantiation from a callback specified in the .info file. It registers an implementation of the workflow::service_contract::action_side_effect service contract.

My implementation UoSGoLive sets content items as live revisions when the "close" workflow action is executed. So the next thing you need to do is assign the side effect implementation to your workflow spec as follows:

close {
pretty_name "<span>#</span>curriculum-central.close#"
pretty_past_tense "<span>#</span>curriculum-central.closed#"
assigned_role { stream_coordinator }
assigned_states { submitted }
new_state closed
privileges { write }
callbacks {
curriculum-central.UoSGoLive
}
}

Take note of the callbacks component of the spec. I make a reference to my implementation of the side_effect contract called curriculum-central.UoSGoLive, where "curriculum-central" is the package key as returned by [curriculum_central::package_key].

Once this is done you can then implement the aliases GetObjectType, GetPrettyName and DoSideEffect.

ad_proc -public curriculum_central::uos::object_type {} {
Get the short name of the workflow for Units of Study.
} {
return "cc_uos"
}

ad_proc -private curriculum_central::uos::go_live::pretty_name {} {
return "[_ curriculum-central.go_live]"
}

ad_proc -private curriculum_central::uos::go_live::do_side_effect {
case_id
object_id
action_id
entry_id
} {
# Make the content item go live.
}

The above do_side_effect proc will get interpreted when the "close" action is executed. So you can put anything in that proc that you want done when the "Close" action button is pressed from ad_form.

Hope that helps.

Cheers,
Nick.

Hi Carlos,

Did you remember to add the callback to your .info file? For example:

&lt;callbacks&gt;
&lt;callback type="before-uninstall" proc="curriculum_central::install::package_uninstall"/&gt;
&lt;callback type="after-install" proc="curriculum_central::install::package_install"/&gt;
&lt;callback type="before-uninstantiate" proc="curriculum_central::install::package_uninstantiate"/&gt;
&lt;callback type="after-instantiate" proc="curriculum_central::install::package_instantiate"/&gt;
&lt;/callbacks&gt;

The callback that calls your side-effect implementation is the package_install proc. That proc is provided below:

ad_proc -private curriculum_central::install::package_install {} {
Package installation callback proc
} {
db_transaction {
curriculum_central::install::register_uos_go_live_impl
}
}

The package_install proc in turn calls the proc that registers the side-effect implementation.

So in short, there is no special naming conventions for your procs. You just need to make sure that you can trace them from the callbacks section in your .info file.

To answer you second question, no you don't need to pass parameters into your implementation proc. This is done for you through the workflow package.

Cheers,
Nick.

Not all the callbacks are necessary to define. They were just examples of how to define callbacks. Although you should define the package_uninstantiate callback so that you can deregister your workflow service contract implementations.