Re: Re: Directory layout of package

From: 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:
Justin Patrin wrote:
On 5/14/07, Tias <tias@ulyssis.org> wrote:
I am familiar with the guidelines as written in the manual (http://pear.php.net/manual/en/group.php#group.directory_structure,
the
same content as in the link you gave). The 2 questions I had for QA, in the last paragraph of my original
email:
1) 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 to
take
something like Frontend_Web_Handler.php to avoid confusion on what
file
does 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 a
file
'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 conclusion
that
the answer is simple: rename it to pearweb.php (in the PEAR installation dir)
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?
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
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.
Then it's in installer frontend. ;-)
Of course I don't want any confusion with pearweb, so I suppose I can just take its natural name: pearfrontendweb.php
I'd be happier with that one. :-) -- Justin Patrin

« previous php.pear.qa (#4318) next »