Re: Some suggestions for documentation

[Nigel S. <nig...@us...>]

> hm, I can see that being able to update all the nodes in a set with one
> instruction is useful, but why getDataParts and not any of the other get
> functions?

getData() calls getDataParts(), so getData() takes a xPathQuery.  Have
updated the source...  Which other "get" functions are missing this?

> Documentation for getDataParts doesn't mention this!

The documentation for getDataParts doesn't mention this, because
getDataParts() was altered since the V3.0 release to support an xPathQuery,
hence it is different in the released documentation.  Sorry for the
confusion... I always refer the most recent version from CVS unless I
explicitly state otherwise.

> Surely the main reason it was 'such a common problem' was because the
> documentation wasn't clear. To get a particular node, use a get function;
to
> get a list of nodes meeting an xpathquery criterion, use evaluate/match,
and
> then loop through the resulting array. Seems clear to me!

I'm glad it was clear to you :o)  The way the class is now it is more
useable, at the expense of making novice users run less efficient calls by
passing a xPathQuery rather than an absolute XPath.

> > The functions are grouped as they appear in the source file, so by class
> > and then in the order that they are defined in the class.  I had some
> > debate with Sam over the ordering in the file and we decided that the
> > ordering of the functions in the source files should assist coding, and
the
> > doc will just have to live with it.  I know it's not ideal, but I don't
see
> > an easy solution to re-doing the order for the doc, so I don't plan to
do
> > anything about this.
>
> perhaps what's needed is a separate FAQ: 'how do I ...'

This is probably a good point to mention that ANYONE can author
documentation for the class, and submit it at
http://sourceforge.net/docman/new.php?group_id=36731  Sam or I have to
"authorise the document" but unless you swear, curse and blashpheme it's
likely to be published.

Given that there were nearly 2500 downloads of 2.2, and less than 1% support
requests, I wouldn't know what to put in a faq, so at this stage have no
intention of authoring one myself

> On a related issue, could you add the ability to set the source encoding.
> Though you have the options, which enable setting of target encoding, it
> looks like source definition isn't in phpxpath at present, meaning it uses
> the default, which in PHP for some reason is 8859-1. I would have thought
> PHP's default should be whatever is given in the xml file or, failing
that,
> the xml default, which is utf8 - but ...
> I am currently using non-Latin1 charsets only in a database, but intend to
> expand this into xml. I can foresee problems if it assumes everything is
in
> 8859-1 !

Ummm I don't really know where to start in coding this feature, as I don't
really understand what's required.  It does sound like a useful addition
though, as I know we have many european users.  It's not an issue that is
directly affecting me, so I'm afraid it's unlikely that I will look into
this with any sort of priority.  Don't suppose anyone else wants to?  Sam?
Peter?

:o)

Nigel