[isf-wifidog] Re: PATH troubles in Wifidog - and some more thoughts
Benoit Gregoire
bock at step.polymtl.ca
Lun 4 Sep 09:12:16 EDT 2006
On Sunday 03 September 2006 23:10, Max Horváth wrote:
> - gpg control packet
> Hey guys,
>
> just a question: how do handle the path defines at the command line?
>
> I.e. right now I don't have a clue how to run the cron scripts as
> with php-cli there is no DOCUMENT_ROOT and stuff like that.
I had made the necessary modifications so that the mail script would only
require WIFIDOG_ABS_FILE_PATH, . From the command line, most other path's
simply make no sense. Defining them would just cause the failure to occur
further in the code.
For testing, I presume you would want to use the GUI methods. There is
actually code to manually define the low level paths. You'd need to add the
same facility for BASE_NON_SSL_PATH and could then define it in your test
scripts.
> Now it's also getting harder as I started writing unit test and the
> cli doesn't know the path's of course ;) ...
>
> I know this topic has been a mess for a long time - why don't we just
> switch to hard coded path defines in the config.php before the 1.0
> release? All the trouble would be gone :)
We can't define them in config.php, or it wouldn't work out of the box on most
webservers like it does now.
In the begining, the file paths were defined through an explicit relative
definition of the basepath at the top of every PHP script. I still think
this was clearer and simpler, and I wouldn't mind going back. It would make
your basic commandline problems disapear overnight. We are kind of doing the
equivalent by doing a relative include on common.php, and reverse engineering
it from there. While needlessly complicated, it should work just the same
from the command line.
The other part of path detection (the one dealing with URLs) is quite frankly
fine now.
> Cheers, Max!
>
> PS: Anyone working on the PDO implementation? Or any thoughts about
> it, yet? Design docs / thoughts?
Now that we don't ever intend to support MySql, In practice converting
everything to PDO only gives us prepared statements, and a more standart
database syntax.
If we don't want to loose our SQL profiling functions (that just went back in)
and make it possible to do a progressive transition. We can get the same
benefits by doing the following:
1-Pourting our current AbstractDb to PDO
2-Rename all the current methods in the class deprecated_methodName, and
search and replace in the whole tree.
3-Make the class inherit from PDO, and make the standard PDO functions log to
our profiler.
4-Progressively move to the new syntax.
That would work, but I'd say it's a "If someone feels like it" priority.
> PPS: Being maybe revolutionary in this mail, what about seperating
> the classes folder into a package installable via PEAR? :) :) :) It
> could solve / ease dependency problems when installing Wifidog auth
> server.
How? None of our dependencies except for a few RADIUS ones are part of PEAR
anyway!
Plus d'informations sur la liste de diffusion WiFiDog