From: Alex L. <ad...@ya...> - 2007-03-01 21:33:41
|
no...@se... wrote: > Hi folks, > > I've got a strong dislike for the committed pathing fix by Alex and I want > to disargee the need of such a global variable like $root_path. > > As fas as I can see there is no need for a global variable in a library > such as OpenDocumentPHP anyway. > > Let think of the following scenarios: > > a) You are root of you webserver and have total control: > > You can put OpenDocumentPHP where ever you want and can add the Path to > the classpath either by put it in the php.ini or adding it with a propper > set_ini statement. > > b) You are nor root neither have total control: > > In this case you can ask your administrator to add it to the php > classpath, which he/she probably don't. You can try to add it with a > propper set_ini statement, which will probably won't work. Or, and this > will allways work, you put the directory OpenDocumentPHP/ in the same > directory (as a subdirectory) as you application. Because your application > is in the classpath, the require_once statement will find the > OpenDocumentPHP stuff anyway. > > Planed before 0.6.0 is also a PEAR package, so you can install > OpenDocumenPHP as simple as: > > >> pear discover-channel pear.opendocumentphp.org >> pear install opendocumentphp/OpenDocumentPHP >> > > In this case OpenDocumentPHP will be in your PEAR directory and this > should work for end users and developers. > > But why is a global variable, like Alex did it, such a bad thing, you may > ask? > > The answers is easy: It is not OOP and you, as a library developer, don't > know if an other application needs exactly this variable for something > different. > > If I am (totally) wrong, please stand up and tell me what I am miss! > > Yours, > Norman > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > OpenDocumentPHP-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opendocumentphp-developers > I agree Norman, this is a hack. This is a problem that 90% of web applications have to deal with. If you want to use OpenDocumentPHP as a library to build other applications and this is what it is designed for then I agree that the global variable is not the correct usage, however in my eyes the best path for OpenDocumentPHP is not just as a library, but it should be used with both an input and output module with the current SVN copy being used only an a process between the two. At the current moment we take input from a web-page, or from where-ever so that it meets a set Interface. This then gets processed and turned in a OpenDocument file, .odt for example. In my opinion this is great, but it could be better. What is stopping us from being able to accept .odt files as inputs and then producing a web-page as an output. To me this offers the most flexibility and the best usage of OpenDocumentPHP. As for $root_path, if you wish this to purely be a library for developers to pick up and develop with then that's great, in its current form it does it's job, but even if it only for my benefit we need to clarify the exact direction of the project. Is it as a PEAR library or as an input, process, output application? Thanks, Alex. |