|
List Info
Thread: Re: Deleting links when expiring stories
|
|
| Re: Deleting links when expiring stories |

|
2007-06-08 08:13:16 |
> Wow, no.
> Package declarations don't have a list of options
after them,
> so you don't put qw(m) there. You're just stating
which
> package the following code belongs in, that's all. You
don't
> even want to have that.
You can tell I still have much to learn. Honestly, that's
one of
about 20 variations I've tried.
Thanks for all the explanation. This is the
related_list_print.mc
template we are trying to call:
<%perl>;
#first we're going to use story_list to find all the stories
that
have this story as a related story.
for my $rel ($m->comp( 'story_list.mc', max => 100,
stories_related_to => 1)) {
#now we used element_list to find all the container elements
within
this story that have those parameters -- type is story, they
are
objects of the related story we found in storylist, limit to
the
key_names that have related stories associated, and make
sure they're
active containers.
for my $elem ($m->comp( 'element_list.mc', object_type
=> 'story',
object => $rel, key_names => 1, active => 1) ) {
#once the list of containers is found we have to make sure
that we
get the specific one that links to this story so we compare
URIs.
if($elem->get_related_story->get_primary_uri eq
$story-
>get_primary_uri){
#now we've got it, so delete it, save it, and save the
story.
$elem->do_delete;
$elem = $elem->save;
$rel = $rel->save();
#grab the session user.
my $session_usr = Bric::App::Session::get_user_id();
#if rel is on a workflow we need to send an alert
if ($rel->get_workflow_id != 0){
#variables for alerts: grab the story user and session user
and
create the array for users that will get the alert
my $story_usr = $rel->get_user__id();
my $u = Bric::Biz::Person::User->lookup({ id =>
$session_usr });
my users;
#if the story is checked out, we want to send the alert to
both the
story user and the session user. If it's checked in we can
only send
it to the session user.
if($story_usr ne ''){
users = ($session_usr, $story_usr);
} else {
users = ($session_usr);
}
#grab available contact types, look up the correct alert
type,
activate the alert type, add the session user with his
primary
contact, and save the alert
my contact_types =
Bric::Biz::Contact->list_alertable_types();
my $at = Bric::Util::AlertType->lookup({ id => 1046
});
$at = $at->activate;
$at->add_users($contact_types[0], users);
$at = $at->save;
#log an event that the story was saved to trigger the alert
my $et = Bric::Util::EventType->lookup({name =>
'Story Changes
Saved'});
my $event = $et->log_event($u, $rel);
#delete the users from the alert type, deactivate the alert,
and save
it so it's ready for next time
$at->del_users($contact_types[0], users);
$at = $at->deactivate;
$at = $at->save;
}#end if in a workflow
#publish the story we just changed as long as we're not in
Syntax
mode, it is not on a workflow, and publish status is 1 (it
has
already been published).
return if $burner->get_mode == SYNTAX_MODE or
$rel->get_workflow_id !
= 0 or $rel->get_publish_status == 0;
my $b = Bric::Util::Burner->new;
$b->publish($rel, 'story', $session_usr, '');
}
}#end element list
} #end story list
</%perl>
|
|
| Re: Deleting links when expiring stories |

|
2007-06-08 09:23:24 |
It looks like you need to do these things in order
to plop that code into lib/Bric/Util/Burner.pm `publish':
1) replace the two $m->comp calls by whatever Perl is
inside them,
presumably just ->list calls
2) replace $story below with $ba (parameter to `publish')
3) replace $burner with $self
4) You might also have to put
use Bric::App::Session;
use Bric::Biz::Person::User;
use Bric::Biz::Contact;
use Bric::Util::AlertType;
use Bric::Util::EventType;
at the top ("Programatic Dependencies" [sic]) .
The idea is that you need to get rid of $m, $story,
$burner,
and any other global variables that are normally available
to templates; and you have to load classes that you're
calling
methods on.
On Fri, 8 Jun 2007, Matt Rolf wrote:
>> Wow, no.
>> Package declarations don't have a list of options
after them,
>> so you don't put qw(m) there. You're just stating
which
>> package the following code belongs in, that's all.
You don't
>> even want to have that.
>
> You can tell I still have much to learn. Honestly,
that's one of about 20
> variations I've tried.
>
> Thanks for all the explanation. This is the
related_list_print.mc template
> we are trying to call:
>
> <%perl>;
>
> #first we're going to use story_list to find all the
stories that have this
> story as a related story.
>
> for my $rel ($m->comp( 'story_list.mc', max =>
100, stories_related_to => 1))
> {
>
> #now we used element_list to find all the container
elements within this
> story that have those parameters -- type is story, they
are objects of the
> related story we found in storylist, limit to the
key_names that have related
> stories associated, and make sure they're active
containers.
>
> for my $elem ($m->comp( 'element_list.mc',
object_type => 'story', object =>
> $rel, key_names => 1, active => 1) ) {
>
>
> #once the list of containers is found we have to make
sure that we get the
> specific one that links to this story so we compare
URIs.
> if($elem->get_related_story->get_primary_uri eq
> $story->get_primary_uri){
> #now we've got it, so delete it, save it, and save the
story.
> $elem->do_delete;
> $elem = $elem->save;
> $rel = $rel->save();
> #grab the session user.
> my $session_usr = Bric::App::Session::get_user_id();
> #if rel is on a workflow we need to send an alert
> if ($rel->get_workflow_id != 0){
>
> #variables for alerts: grab the story user and session
user and create the
> array for users that will get the alert
> my $story_usr = $rel->get_user__id();
> my $u = Bric::Biz::Person::User->lookup({ id =>
$session_usr });
> my users;
>
> #if the story is checked out, we want to send the alert
to both the story
> user and the session user. If it's checked in we can
only send it to the
> session user.
> if($story_usr ne ''){
> users = ($session_usr, $story_usr);
> } else {
> users = ($session_usr);
> }
> #grab available contact types, look up the correct
alert
> type, activate the alert type, add the session user
with his primary contact,
> and save the alert
> my contact_types =
Bric::Biz::Contact->list_alertable_types();
> my $at = Bric::Util::AlertType->lookup({ id =>
1046 });
> $at = $at->activate;
> $at->add_users($contact_types[0], users);
> $at = $at->save;
>
> #log an event that the story was saved to trigger the
alert
> my $et = Bric::Util::EventType->lookup({name =>
'Story Changes
> Saved'});
> my $event = $et->log_event($u, $rel);
> #delete the users from the alert type, deactivate the
alert, and save
> it so it's ready for next
time $at->del_users($contact_types[0],
> users);
> $at = $at->deactivate;
> $at = $at->save;
> }#end if in a workflow
> #publish the story we just changed as long as we're
not in
> Syntax mode, it is not on a workflow, and publish
status is 1 (it has already
> been published).
> return if $burner->get_mode == SYNTAX_MODE or
$rel->get_workflow_id
> != 0 or $rel->get_publish_status == 0; my $b =
> Bric::Util::Burner->new;
> $b->publish($rel, 'story', $session_usr, '');
> }
> }#end element list
> } #end story list
>
>
> </%perl>
|
|
[1-2]
|
|