Page 1 of 1

Classes that write to files, brittleness, and clutter

Posted: Wed Feb 07, 2007 10:22 am
by xx9
Hi. I'm writing a few classes to act as a sort of plugin scaffolding. One of the classes has to read from a file(which I call the "manifest" file). And in the future one or more classes will either have to write to this file or another one.

I'm not sure if I should use the same file that will be used from the real app code, if I should create and destroy the file on the fly with the setup() and teardown() methods, or if I should just create a separate one for development/testing.
The information the file holds: the name of the plugin; 1 or 0 denoting whether it is enabled; and a list
of optional, comma separated "namespaces".

Another problem will arise when I do my integration tests. The class that actually loads the plugins uses the manifest reader class and then reads the plugin files themselves from the file system. So they need to exist. So for that, should I create a set of dummy plugins just for testing? Actually that's what I've already done, for the plugin loader class, which needs to access real plugin files on the file system, but I don't know if that's the path I should continue on. If creating dummy plugins for testing is ok, should I keep them separate from the real plugins to keep from cluttering up the "real" app space?
In other words I don't think I really want dummy plugin entries in the real manifest file and it would be best I think to not have these test plugins in the release version.
Should I mix them together using the same files and directories and such that the "real" code will use and just remove them with a script when I make the release or should I just mix them in and not worry about it, or should I keep the test files completely separate so that the tests only work on dummy test files?

Write now the tests are using files in the "example_plugins" directory but that may change depending on the answers I get here.

Here's the url to the code: http://radiance.dreamhosters.com/jedPlugin/trunk
Be warned, it's still young and messy and not very pretty but it might help you understand my question more. Thanks.

Posted: Wed Feb 07, 2007 4:08 pm
by Kieran Huggins
sounds like a design issue - why aren't you using a database? It would be write safe, and you don't have to worry about file clutter.

Otherwise, just use an empty temp folder.

Posted: Wed Feb 07, 2007 6:00 pm
by xx9
Kieran Huggins wrote:sounds like a design issue - why aren't you using a database? It would be write safe, and you don't have to worry about file clutter.
- the file system is more likely to already be installed :)
- it's a very simple format and there are no complex relationships
- I'd like people to just be able to edit the file by hand to determine which plugins run and when
- writes shouldn't be much of a concern since for now there is no writing, and when I add writing to update the plugin records, I think flock will do the job, but the speed of reading might become an issue if the files get large, but even when I add that ability writes shouldn't occur often

Probably what I'll do though is create a factory for the reader and a fake abstract super class for the reader(PHP 4) , then I'll be able to easily switch from file system to RDB.

Kieran Huggins wrote: Otherwise, just use an empty temp folder.
That's pretty much what I've done so far. I just didn't name it temp.

Posted: Wed Feb 07, 2007 6:15 pm
by RobertGonzalez
How many files do you foresee this app generating? Ideally, dealing with files should be filesystem type work. But as the file system grows, performance wanes. A database seems like a logical choice to use for this type of application. And installation of a database is not that involved.

Posted: Wed Feb 07, 2007 6:54 pm
by Christopher
I am a little confused about the text file. You already have a config file ... why not just put the manifest data there there.

Code: Select all

$manifest = array(
     0 => array(
          'name' => 'MyCoolTestPlugin',
          'enabled' => 1,
          'namespaces' => array('admin','generate','site'),
     ),
     1 => array(
          'name' => 'MyHotTestPlugin',
          'enabled' => 1,
          'namespaces' => array('visitor','destroy','kaboom'),
     ),
);
You could then have dev and release config files, or separate sectons within the config file.