Re: Call for comments: File:BibTex
| From: | bertrand Gugger | Date: | Wed, 12 Apr 2006 07:20:09 +0000 |
| Subject: | Re: Call for comments: File:BibTex | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-42200@lists.php.net to get a copy of this message | ||
Bonjour,
Elmar Pitschke wrote:
Hi, first of all thanks for the great response and tips. I rewrote the whole parsing function and it should now not break anymore. Of course i tested that with different inputs. I also wrote a small doc about how it is parsed: http://www.helftgreg.de/bibtex/parsing.html I also used the rewriting to add a new feature. Now it is possible to tell the parser whether the delimiters should be stripped or not. Regarding the discussion of the package. I am not sure where it fits more, File or Structure. But looking at the features planned for the package - validation and export in different format - i agree that it fits more in Structure. So i am going to change that. Further tips are i appreciated Thank You Elmar Better recall the link to your draft : http://pear.php.net/pepr/pepr-proposal-show.php?id=386Btw, comments can only come in list, not on the server, so long you stay in "draft" , but I think you're aware of that. I can imagine your stuff can produce BibTex from an array, that could be done in 3 lines of php. Btw, I don't like the way you store cite and type whixh do not belong to the entry 's attibutes, some clash is possible and you don't check if the index is unique. Also you force the delimiters to {} ... I cannot believe this would parse correctly ... :) I think you still have some "edge" cases. * I don't succeed to get how "embedded" @ are not taken in the preg_split , I had done some preg_match_all on the global entry pattern , just including possibly malicious recursive ones. * take care \% is *not* a comment start * in _parseEntry() this loop to strip delimiters is abolutely ill and dangerous, :) again I had made a preg_match_all globally on the atttributes * btw, you accept undelimited attributes as year=2006 from your example ? Could be nice, but that should be optional as it's not strict. * generally, an ill formed file has reasonnable chances to break things or at least produce some warnings and funny results (?) * a release number is 3 numbers, 0.1 is incorrect, by proposal you may use 0.0.x and 0.1.0 should be the first alpha/devel release * the content is loadable from a string by direct affectation to the public property $content, that could be ok... * what are $this->_pos and $this->_oldpos ? * put a dependency on PHP-4.3.0 in your package.xml if it is the case. Regards -- toggg