[Gforge-devel] Hardcoded Paths in GForge

[Christian BAYLE]

The only required use of a path var is when you want to "fopen" a file 
which should be done as less as possible
I would prefer not to have the need of any fixed path, and the 
getConfigDirectory would probably store a path.

I would prefer a convention that all plugin have a config.php file that 
have to be found in the path under some
minimalist structured form like plugins/<pluginname>/config.php, so you 
can put all transparently e.g. in /etc/gforge or
whatever place you put config files (It's more or less like this for 
many plugins but the path is 
plugins/<plugname>/etc/plugins/<plugname>/config.php which is not very 
convenient)

I would be tempted to propose to put all vars in a table, I'm not sure 
it would slow down page display, but it would have the convenient
property to build easily config page

Indeed I think that only some db connection related vars are necessary 
in a file, and I would be tempted to remove the use of passwd, which I 
think is finally worst than allowing non passworded db connection to 
apache user.

Luxuous solution would be the propose the two possibilities, file or db.

Christian


Robert Nelson wrote:
>
> Christian and I were discussing the hard-coded paths in GForge on the 
> IRC. As part of my changes I introduced a new configuration variable 
> sys_etc_path. This is used instead of the previously hardcoded 
> /etc/gforge in a number of files. Christian suggested, and I agreed, 
> that we should avoid manual configuration and make GForge self 
> configuring using the include path.
>
> Currently the sys_etc_path variable is used to form directory paths 
> which are checked for existence or to form file paths which are passed 
> to fopen. Both of these scenarios are easily handled using a routine 
> that searches the include path and returns the matching path.
>
> However the Plugin Manager is more problematic since it creates the 
> symlink so there isn’t an existing file or path to search. I could 
> search for the local.inc file and then use the directory as the 
> equivalent of /etc/gforge. This could be packaged as a function 
> getConfigDirectory for example. Then the existing references to 
> /etc/gforge or sys_etc_path could be replaced with calls to this new 
> function.
>
> How does this sound? Would it address your concerns Christian? Anyone 
> have any better ideas?
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gforge-devel mailing list
> Gforge-devel at lists.gforge.org
> http://lists.gforge.org/mailman/listinfo/gforge-devel
>