[Gforge-devel] Hardcoded Paths in GForge

[Christian BAYLE]

Ok, In fact I think we could/should get rid of fopen for plugin install

In fact I don't really see where fore exemple sys_etc_path it is 
required in

./plugins/scmccase/common/CCasePlugin.class
./www/include/BaseLanguage.class
./common/include/Plugin.class

as it was not used before

In fact system( rm ) or system (ln) has also the bad property not to be 
useable everywhere.

Anywhere were we can get rid of  path we should remove, but not problem 
for any function that make  things cleaner :)

Cheers

Christian



Robert Nelson wrote:
> I'm confused; your response doesn't seem to answer my questions.  My
> questions are specifically about how to handle the fopen cases, for which I
> suggested creating a function that searches the include path for the file
> rather than taking a hardcoded path.
>
> The other question was how to handle the installation of plugins.  The
> plugin installer needs to know the "/etc/gforge" path in order to install
> the plugin's config.php and other files.  My suggestion for this was the
> getConfigDirectory().  As I described in the message this function would NOT
> use a hardcoded path.  It would search along the include path for the
> local.inc file and return that directory.
>
>
>   
>> -----Original Message-----
>> From: gforge-devel-bounces at lists.gforge.org [mailto:gforge-devel-
>> bounces at lists.gforge.org] On Behalf Of Christian BAYLE
>> Sent: Saturday, March 10, 2007 11:37 AM
>> To: gforge-devel at lists.gforge.org
>> Subject: Re: [Gforge-devel] Hardcoded Paths in GForge
>>
>> 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
>>>
>>>       
>> _______________________________________________
>> Gforge-devel mailing list
>> Gforge-devel at lists.gforge.org
>> http://lists.gforge.org/mailman/listinfo/gforge-devel
>>     
>
>
>
> _______________________________________________
> Gforge-devel mailing list
> Gforge-devel at lists.gforge.org
> http://lists.gforge.org/mailman/listinfo/gforge-devel
>
>
>