opendocumentphp-developers

[ODP-dev] Using $root_path.

[Alex L. <ad...@ya...>]

Howdy guys,

Just committed the pathing fix, at the current moment to run 
OpenDocumentPHP the directory is it contained in must be within the ini 
files classpath, as a result this makes it annoying to use, as a work 
around please include the $root_path when including a new file, when 
starting a new test case please define $root_path to set it to the root 
of the /src directory.

So, if I have...

OpendocumentPHP
    src
       OpenDocumentPHP
          >> This is where the ODPHP Code is.
       Samples
          >> This is where the test cases are.
    doc

When defining a text case in the Samples directory please note that you 
should define the variable $root_path to point back to the src directory...
    $root_path = './../';

So that when this is called in the line to get the OpenDocumentText class..
    require_once $root_path . 'OpenDocumentPHP/OpenDocumentText.php';

the string becomes.. './../OpenDocumentPHP/OpenDocumentText.php', and 
therefore can be found from the Samples directory..

Enjoy.. Alex.

[ODP-dev] Why I think $root_path is evel --- was: Using $root_path.

[<no...@se...>]

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

Re: [ODP-dev] Why I think $root_path is evel --- was: Using $root_path.

[Alex L. <ad...@ya...>]

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.