Re: variable node structure (was idw - continued)

[Peter R. <php...@pe...>]

Going back to this thread, I've been looking into this a bit further and I 
find that getAttributes works as I would like whereas getData doesn't. So if 
I do 

getAttributes( ... specific attribute that doesn't exist)

it returns false, so I can do

if ($var = getAttributes)
   do whatever with $var;

which is what I want. Bizarrely, if I do the same with getData, i.e. for a 
path to an attribute that doesn't exist, it fails with an error.

So rather than different levels of reporting, I think all I really need is 
for getData (and for that matter nodeName, which has the same problem) to 
behave like getAttributes and return false if the node does not exist.

At the moment, given a xml file with variable structure, evaluate seems to be 
the only way of getting, for example, a list of child nodes or finding if a 
particular node exists. Evaluate, though, seems to really slow things down. 
I've just converted one such file from phpxml to phpxpath, thinking that it 
would speed things up, and it's actually substantially slower - I think 
because of all the evaluates that I have to include to check whether child 
nodes exist or not.


On Friday 18 Jan 2002 12:02 am, Nigel Swinson wrote:
> >
> > I have an xml file with large numbers of child (+ grandchild ...) nodes 
which
> > may or may not be present. My old phpxml script did an evaluate for the
> top
> > level and then get_Contents for any children it needed; if a child didn't
> > exist, phpxml simply set the variable to null. phpxpath, however, seems
> > to throw an error and refuse to continue if you try and getData or
> getDataParts
>
> > for a child or attribute that doesn't exist. If I have to do a
>
> match/evaluate
>
> > for each of these nodes before getData, not only is that a lot of extra
>
> work
>
> > but I'll probably have to rewrite the logic.
> >
> > Can phpxpath be changed to be like phpxml and simply set the variable to
>
> null
>
> > if getData doesn't find the node?
>
> A good point.  Sounds annoying.  :o(
>
> I think the plan is to support different levels of error reporting, so when
> you build the class, you set an option to say what kind of errors you want.
> So what you'd do then is say that you don't want errors if the node doesn't
> exist and you'd be happy, and if you want it to complain, you can leave the
> errors on.  So yeah, we are aiming for this too :o)