Re: Virtual Filesystem
| From: | Alan Knowles | Date: | Sat, 28 Sep 2002 01:16:36 +0000 |
| Subject: | Re: Virtual Filesystem | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-9626@lists.php.net to get a copy of this message | ||
Chuck Hagenbuch wrote:
Quoting Alan Knowles <alan@akbkhome.com>:class Horde_VFS_Object_file extends Horde_VFS_Object {I don't understand why you'd need to duplicate the backends. Why not just have Horde_VFS_File and Horde_VFS_Directory (or Folder, either way) classes, that wrapped the appropriate methods and stored internal references to a VFS backend instance? That will probably/hopefully work for the existing backends.
http://docs.akbkhome.com/akpear/System_VFS_mgd_topic.html Basically, each directory and file can be of multiple types .., although they appear as files and folders to the user, the backend data comes out of different databases. But I think the General jist would be that If It is possible - add it to the original VFS...If a new driver is written for the object one, then the Horde_VFS, could provide a wrapper to it in a similar way...I see no reason to put backend code into the object drivers. You could even keep the API clean with a simple Horde_VFS_Object interface that wrapped a VFS backend instance in an object API, for any methods that the File and Directory objects mentioned above didn't cover. 3 classes, max, and you keep all the existing code and duplicate little to none of it... This is one of the reasons I would think that 'some' VFS drivers may not be suited to the current API, (although this is a highly specific example, which is more a 'User defined backend'...)
-chuck -- Charles Hagenbuch, <chuck@horde.org> "People ask me all the time what it will be like living without otters." - Google, thanks to Harpers