Hi readers and developers,
I really appreciate the idea of adding custom components via the
configuration. That's much better than all the workarounds which cause a
great overhead just to hack a simple setting in oxubase.
As a general thought on this I would go a step further:
a developer has to deal with local, testing, continous integration,
staging and productive environments and - of course - all need different
settings. So we had to find a way to handle different environments which
need different configuration settings.
The way we solved this, is to set up an environment variable in
apache's vhost.conf like e.g.:
SetEnv APPLICATION_ENV production
(In most cases one could also do this using the .htacess file)
In config.inc.php we added something like this at the end:
// additional configuration values
$stage = getenv('APPLICATION_ENV');
if (is_readable(SHOP_PATH .'/config.' . $stage . '.php')) {
include SHOP_PATH .'/config.' . $stage . '.php';
}
This way you do have all possibilities to extend or replace
configuration settings depending on the environment, the current
instance is running on. Additionally our customer has a central place to
edit configuration settings and we don't need to create an admin view
for every single setting (time => costs).
It is somehow similar to the way the language array is extended if a
file exists in out/theme/language/. Maybe this is a way that could make
it into the core? If the file doesn't exist there is no disadvantage
(except some microseconds to find out that the file doesn't exist).
Additionally I would place all configurations in a sub folder called
"config" to clean up the htdocs-root (included files shouldn't be in the
document root).
In contrast to Marc I do feel, that a configuration file is the correct
place to place this. Because that's what we do: extending or changing
the standard configuration.
What do you think?
Best regards from Germany,
Daniel Schlichtholz
Mayflower Gmbh - [email protected]
Pleichertorstraße 2 - Tel.: +49 931 / 35965 - 1125
9707 Würzburg - Fax: +49 931 / 35965 - 28
http://www.mayflower.de
On Fri, 1 Jul 2011 13:34:47 +0000, Vilma Liorensaityte
<[email protected]> wrote:
> Hi,
>
> At the moment this is a quick fix to make it work. In future we will
> search for better solution.
>
> Besides, if you have any ideas how to improve - please tell us,
> working on this task we will consider them.
>
> Regards,
> Vilma
>
> ________________________________________
> Siuntėjas: [email protected]
> [[email protected]] development
> [[email protected]] vardu
> Išsiųsta: 2011 m. birželio 30 d. 15:28
> Kam: [email protected]
> Tema: Re: [oxid-dev-general] Custom components option
>
> Hi Vilma,
>
> Great news.
> We just discussed this missing functionality at the technical
> certification module yesterday in Freiburg!
> Will this solution be permanent or are there any plans for an even
> more convenient way to do it?
> Because I don't think the config.inc.php is really the right place,
> though I currently don't have any better place to recommend.
>
> Regards
> Marc
>
> ORCA Services AG
> Herrenmattstrasse 26
> CH-4132 Muttenz
> Office Basel: Aeschengraben 10, CH-4051 Basel
>
> [email protected]
> T. +41 61 205 80 80
> T. +41 61 205 80 73 (direkt)
> F. +41 61 205 80 81
>
> www.orca.ch, www.orca-services.ch
>
> "We convert your visitors into customers."
> -----Ursprüngliche Nachricht-----
> Von: [email protected]
> [mailto:[email protected]] Im Auftrag von Vilma
> Liorensaityte
> Gesendet: Donnerstag, 30. Juni 2011 15:15
> An: [email protected]
> Betreff: [oxid-dev-general] Custom components option
>
> Hi,
>
> According to reported bug
> http://bugs.oxid-esales.com/view.php?id=1721, we implemented suggested
> improvement for the next release: added $this->aUserComponentNames
> array option to config.inc.php. With this option it will be easier to
> override custom components array $_aUserComponentNames (class names,
> that are defined in this array, will be executed before any other
> regular operation) in oxubase. Till now the only way to override this
> array in oxubase was extending view classes and sometimes all of them.
>
> Regards,
> Vilma
> _______________________________________________
> dev-general mailing list
> [email protected]
> http://dir.gmane.org/gmane.comp.php.oxid.general
> _______________________________________________
> dev-general mailing list
> [email protected]
> http://dir.gmane.org/gmane.comp.php.oxid.general
> _______________________________________________
> dev-general mailing list
> [email protected]
> http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
