Adam R. B. Jack wrote:
<snip/>
> Still, I'm not "comfortable" w/ my implementation, partly 'cos of the age
> old (for Gump) problem of knowning what can be relied upon when converting
> XML to objects (i.e. what objects/properties are yet set.) Further,
> objectifier.py doesn't seem to have access to the work dir. I'm sure that is
> by design, but it means I have to 'delay' resolving of things. Seems a tad
> awkwards, and I'm not sure I'm in sync with why plugins have workdir, but
> core parts don't. Is it to be clean, i.e. model not physical?
I just changed a whole lot of this code (revision 209309). I think the
above caused 90% of your pain implementing all this. Didn't realise what
the problem was here until I actually tried to change some of the code
myself.
I went back through this thread and it became pretty clear to me where
the disconnect occurred (in the second paragraph starting the thread
:0). Basically the simplest thing (pass the workdir to the objectifier)
made a whole lot of other stuff easier.
To answer the original question above (now that I understand it), I
guess the "design" part of the objectifier until now not having access
to the work dir was because it didn't need it until now (well actually
until we started on this bit of code). By keeping all the relationships
and property use explicit (instead of passing around a big global
"config" or similar), we just pass in exactly what we use, but what we
use and hence what we pass in is subject to change (and easy to change,
if you look at the commit). Don't worry about making these kinds of
changes; just make sure you don't pass around big dictionaries (like the
entire config) unless you have to.
> Anyway, I'm
> open to changes on what I've done. If it stands, I'll add some unit tests
> 'cos I had to remove a few that were absed upon old Homedir.
I am ashamed to admit that I broke most of the unit tests today. I've
got uncommitted fixes for many of them, but I need to sort out the cruft
from my tree first. I just wanted to get this stuff in now since I could
use some feedback :-)
> (I'd need to
> learn what this does first though,
> self.assertRaises(AssertionError,Output,None) 'cos it seems like magic
> sprinkled all over the tests.)
the java equiv would be (yuck!):
try
{
Object o = new Output(None);
this.fail("Expected an AssertionError!");
}
catch(AssertionError ae) {}
basically it is testing that calling the "Output" function (the
constructor for the Output class, in this case) with the provided
arguments (in this case, only "None") results in an AssertionError.
cheers,
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
