Hi Benjamin, Am Donnerstag, den 27.03.2008, 14:34 +0100 schrieb Benjamin Schulz: > Hi, > i just read the phar examples in the manual and found things like this: [...] > First thing: yes i fully understand what the code is doing but i still > think that it doesn't need to be so "hackish". One thing is that i > think there is no point in using ArrayAccess here, in my oppinion > ArrayAccess is great to hack stuff but it doesn't belong in such > (maybe soon?) core functionality.
ArrayAccess is not hackish per se, but it just does not feels right for
working with archives.
[...]
> $p = new Phar('coollibrary.phar');
>
> /* What about creating a non-static pendant to canWrite()?
> Maybe there is an archive file that has only read permissions on
> the filesystem or
> phar will be able to generate readonly-archives later? (Might be
> interesting for companies that want to provide readonly and signed archives
> for
> the customers)
> if ($p->canWrite()) {
> // Create a file instance
> $hugeFile = $p->createFile();
>
> $fp = fopen('hugefile.dat', 'rb');
>
> // Set the content
> $hugeFile->setContent($fp); (or maybe even
> setContentResourceHandle(...))
> if (Phar::canCompress()) {
> /* how is the compression implemented? through streamfilters?
> than how about a ->setCompression('bzip')
> that internally resolves to the bzip.(de)compress:// stuff?
> $p['data/hugefile.dat']->setCompressedGZ();
> }
>
> // add the file to the archive
> $p->addFile($hugeFile, 'data/hugefile.dat');
> // another option would be to pass the file path to the
> createFile() method and
> // implicitely create it in the archive
> $indexPhp = $p->createFile('index.php');
> $indexPhp->setContent(...);
> }
>
I second your proposal, but a bit more flexible:
// Creating files
$phar = new Phar();
$file = $phar->createFile('/filename'); // Phar acts as a factory and returns
an object PharFile or something
$file->setContent('string'); // Polymorph signature, can either take a string
...
$file->setContent(fopen('file', 'r')); // ... or a resource
$file->setContent('foo', $data); // ... or a string and data
$file->setContent('bar', array('line1', 'line2')); // ... or an array of lines
$file->setContent('baz', fopen('file', 'r')); // ... or a name and a resource
if (!$phar->isReadonly()) {
$phar->save(); // Writes the newly create file to the filesystem
}
$phar = new Phar();
$phar->add('foo');
$phar->add('bar', $data);
$phar->add(new SplFileInfo('bar'));
Creating directories:
$phar = new Phar();
$dir = $phar->createDirectory('/foo'); // Return PharDirectory object
$dir->add(new DirectoryIterator("mydir")); // Adds every file in the directory
mydir
$dir->add(new RecursiveDirectoryIterator('otherdir')); // Adds every item
recursivly
$dir->add(new SplFile("foo")); // Adds the file foo
$dir->add('bar'); // Adds bar
$dir->add('baz', $data)
$file = $dir->createFile('bla')
$file->setContent($data);
$dir2 = $dir->createDirectory('foo');
...
$phar->save();
No, with fluent interfaces:
$phar = new Phar();
$phar->createDirectory('foo')
->add('foo')
->add(new SplFileInfo('bar'))
->add('baz', $data);
$phar->save();
if PharFile would include a reference to the original Phar object, the
last Phar::save() could even be included in the chain.
About compression:
I would prefer to have Phar::setCompression(Phar::GZIP) or something
similiar. Or even Phar::setCompressionStrategy(PharCompressionInterface
$interface) but I have the feeling that would go too far :-)
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
