Re: Re: Directory layout of package
| From: | Justin Patrin | Date: | Wed, 16 May 2007 18:44:06 +0000 |
| Subject: | Re: Re: Directory layout of package | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.pear.qa |
| Request: | Send a blank email to pear-qa+get-4318@lists.php.net to get a copy of this message | ||
On 5/16/07, Tias <tias@ulyssis.org> wrote:
Justin Patrin wrote: On 5/16/07, Tias <tias@ulyssis.org> wrote:Then it's in installer frontend. ;-)I'd still say it should include something about being an installer or it can get confused with pearweb. pearwwwinstaller.php? I see why you think the previous name was fine too : ) For me the webfrontend is much more then an 'installer', sure it allows you to install packages, but its about managing all your channels and the packages of those channels, including reviewing its documentation and other features that extend on the basic 'installer' functionality. To make a comparison: you could say that pear is like apt and the webfrontend is like synaptic.Justin Patrin wrote:On 5/14/07, Tias <tias@ulyssis.org> wrote:Ah...that sounds like a bad idea since pearweb is the name of the website's package. What exactly was wrong wit the WebInstaller.php name? Perhaps PEAR/Frontend/Web/RequestHandler.php?theI am familiar with the guidelines as written in the manual (http://pear.php.net/manual/en/group.php#group.directory_structure,email:same content as in the link you gave). The 2 questions I had for QA, in the last paragraph of my originaltake1) First and far mostly: Is it OK to do file renames -> I presume the answer is 'YES, the standard is more important then easely reviewable version information'; which is (in this case) OK for me. 2) Is Frontend_Web.php in this case a good name, or is it better tofilesomething like Frontend_Web_Handler.php to avoid confusion on whatfiledoes what. -> I'll try to explain in detail how this is 'different' then normal. Let's take the example of Cache_Lite as suggested in the manual. First off, the manual is not complete, in that every package has athat'Name.php' too: The_Package_Name |-- Name.php |-- Name (contains subclasses) |... PEAR_Frontend_Web is a webfrontend for PEAR, the default frontend is CLI, which looks like this: PEAR/Frontend/CLI.php (implements PEAR/Frontend.php) Logically, my package should have (by the standard: PEAR/Frontend/Web.php (implements PEAR/Frontend.php) PEAR/Frontend/Web/ (contains subclasses) PEAR/Frontend/Web/data (contains data). So far, so good. Only, my package does not recieve its input from PEAR itself, but throught the browser, so it needs a file that translates _GET and _POST requests into pear requests. The file that handles user input for CLI is: pearcmd.php (in the PEAR installation dir) The file that handles user input for my package is (by legacy): PEAR/WebInstaller.php Which is a horrible name that creates confusion about its use and existence. By explaining this in so much detail, I have come to the conclusionthe answer is simple: rename it to pearweb.php (in the PEAR installation dir)The problem is that the file is not a library, it doesn't contain a class or functions that can be reused. When the file is included it shows the webfrontend, its an application file. That's why I don't want it inside PEAR/Frontend/Web and neither inside PEAR/. The only files inside PEAR that are similar to this one is pearcmd.php and peclcmd.php so I reason that it should be placed with them, and named in a similar fashion. If pearweb.php is not prefered, perhaps pearwww.php ? That would give: /pearcmd.php /pearwww.php /peclcmd.php
Of course I don't want any confusion with pearweb, so I suppose I can just take its natural name: pearfrontendweb.phpI'd be happier with that one. :-) -- Justin Patrin