Apache-Wyrd

 view release on metacpan or  search on metacpan

Wyrd/DBL.pm  view on Meta::CPAN

		base_class
		blksize
		blocks
		ctime
		database
		db_password
		db_username
		dba
		dev
		file_path
		gid
		globals
		ino
		logfile
		loglevel
		mode
		mtime
		nlink
		rdev
		req
		self_path

Wyrd/DBL.pm  view on Meta::CPAN

=cut

sub uid {
	my ($self) = @_;
	return $self->{'uid'};
}


=pod

=item (scalar) C<gid> (void)

the numeric group ID of file's owner of the file currently being served. 
Derived from Apache::Wyrd::Handler, by default compatible with the C<stat()>
builtin function.

=cut

sub gid {
	my ($self) = @_;
	return $self->{'gid'};
}


=pod

=item (scalar) C<rdev> (void)

the the device identifier (special files only) of the file currently being
served.  Derived from Apache::Wyrd::Handler, by default compatible with the
C<stat()> builtin function.

Wyrd/Handler.pm  view on Meta::CPAN

	return DECLINED unless ($self->{'req'}->content_type eq 'text/html');
	$self->{'file'} = $file;
	my @stats = stat _;
	foreach my $datum (
		qw(
			dev
			ino
			mode
			nlink
			uid
			gid
			rdev
			size
			atime
			mtime
			ctime
			blksize
			blocks
		)
					) {
		$self->{'init'}->{$datum} = shift @stats;

Wyrd/Site.pod  view on Meta::CPAN

=head1 NAME

Apache::Wyrd::Site - Wyrds for site maintenance and integration

=head1 DESCRIPTION

The Apache::Wyrd::Site::* modules present re-useable solutions to a few of
the common problems of getting a web site to be integrated and
self-maintaining.  They are kept separate from the other modules in the
Apache::Wyrd hierarchy because they follow a more rigid set of conventions
on site construction than the other modules, and would introduce
inflexibility to the other Modules if more closely integrated.

As a whole, they represent the more functional aspects of a "house style",
which makes several assumptions:

=over

=item The host system is Unix-like, following a process model