Re: proposal preview of PEAR_PackageFileManager_Frontend

Hello Christian, Christian Weiske a écrit :

Laurent, Nice that you both found a way and a common api for the ppfmf classes! Some notes: - Could you make the realpathnix() and array_merge_recursive2() static class methods so they don't pollute the global namespace?

Even if realpathnix() and array_merge_recursive2() are only used into Frontend.php, is there a technical or QA reason to make them static methods ?

- No description for realpathnix()

Its noticed, as lot of phpdoc tags also missing, but i need more time. I expected to do it after open officially proposal, and before receive any feedback. You beat me at my own game; you're too fast Christian :-)

- Why are there no setMaintainers()/addMaintainer(), setFileList() methods? (Sorry if that's a stupid question; I just don't know why) There are no stupid questions, just bad answers. I hope it will not be the case for me !!!

setFileList() is defined, but usage is combined with getFileList(). When i want to get a package file list with CVS, SVN, or any other PFM generator plugin , we should call getFileList(), and if list is empty in session (first call), then setFileList() is called automatically. setMaintainers()/addMaintainer(): These functions are not defined due to PFM implementation. Remember that PFMFE is a layer outside PFM which stay the super backend for all actions. PFMFE should be used with a frontend Web/Gtk2 which has in charge to manage a maintainers list. In my web frontend i use directly PFM methods addMaintainer() and deleteMaintainer(). Hope i've answered to your question ?! Last but not least, thanks for your feedback :o) Laurent