view release on metacpan or  search on metacpan

lib/FAQ/OMatic/Bags.pm  view on Meta::CPAN

}

sub untaintBagName {
	# untaint a bag name -- result is either a valid name or ''
	my $name = FAQ::OMatic::untaintFilename(shift());
	# Don't want user overwriting .desc files with binary bags -- YUK!
	return '' if ($name =~ m/\.desc$/);
	return $name;
}

sub updateDependents {
	my $bagName = shift;

	my $dependent;
	foreach $dependent (FAQ::OMatic::Item::getDependencies("bags.".$bagName)) {
		my $dependentItem = new FAQ::OMatic::Item($dependent);
		$dependentItem->writeCacheCopy();
	}
}

1;

lib/FAQ/OMatic/Item.pm  view on Meta::CPAN

# its parent), the old parent had to get written, and this item knew it
# was dependent on that parent, so this item gets rewritten, too, and has
# its dependencies updated, at which point it detects any new parent.
#
# But for sibling links, this item has no way of discovering (via
# dependencies) when those links change. Whenever a category changes its
# directory part list, it has also changed the sibling links for some
# of its children. In any case like that, it's the parent's responsibility
# to rewrite all of its children, so their dependencies and caches
# can be recomputed.
sub updateAllChildren {
	my $self = shift;

	my $filei;
	foreach $filei ($self->getChildren()) {
		#FAQ::OMatic::gripe('debug', "Updating child $filei of ".$self->{'filename'});
		my $itemi = new FAQ::OMatic::Item($filei);
		if (not $itemi->isBroken()) {
	#		$itemi->writeCacheCopy();
	# jonh: only writing the cache copy isn't enough -- if $itemi's set of
	# siblings has changed, then its IDependOns have changed, too. Those