Re: Re: Directory layout of package

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. Of course I don't want any confusion with pearweb, so I suppose I can just take its natural name: pearfrontendweb.php Tias

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc