There are some things I really like about how my configuration object is implemented. One of these is explicit declarations of valid configuration directives, another is strict typing, where I can say whether or not I want an integer, a lookup array, a hash or a string. I also like the fact that these explicit declarations mean I have to document what the configuration does.
However, unhappy with its decentralized nature and its poor performance, I've decided, once again, to refactor refactor refactor. The evil master plan is here. I would be absolutely delighted if you gave it a glance through, and told me what you thought of it. Thank you!
Refactoring configuration again... am I crazy?
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: Refactoring configuration again... am I crazy?
I just started to read over your notes but I'm conscious of my boss looking over my shoulder so I'll read the rest later 
I don't recall what your current configuration system is like though I do remember your threads at the time making it look incredibly fine-grained and easily customizable.
Do you happen to know if type-hints trigger autoloading? i.e., if you include a class declaration which looks like:
Provided you never invoke foo($b), does PHP still autoload it because of the type-hint?
I don't recall what your current configuration system is like though I do remember your threads at the time making it look incredibly fine-grained and easily customizable.
Do you happen to know if type-hints trigger autoloading? i.e., if you include a class declaration which looks like:
Code: Select all
class A {
public function foo(B $b) {
}
}- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Re: Refactoring configuration again... am I crazy?
Just as new ClassName() doesn't trigger it,
doesn't trigger it either.
Thanks for reading it. I do treat the topic of autoload at the beginning (that was my initial problem), but it's hopefully short.
As a quick primer for those not familiar with my current configuration system, all configuration values get stuffed inside a Config object. When a user sets a value to this object, the configuration object checks whether or not:
* The configuration directive exists
* Whether or not the directive is an alias for another one
* The value is the proper type (converting the value into the proper type if necessary; for example, we can parse comma-separated lists into arrays)
* The value is in the list of allowed values
* ...any other constraints you can think of
Right now, source files register allowed configuration directives by making a ConfigSchema::define() function call. This builds up a global "schema", which the configuration object uses to do these validations. The proposal is not to change the schema, but the method by which the schema is generated.
Code: Select all
<?php
function __autoload($class) {
echo "$class autoloaded<br />";
}
class Baz
{
public function __construct(foo $foo) {
$this->foo = $foo;
$this->foo2 = new Foo();
}
}
Thanks for reading it. I do treat the topic of autoload at the beginning (that was my initial problem), but it's hopefully short.
As a quick primer for those not familiar with my current configuration system, all configuration values get stuffed inside a Config object. When a user sets a value to this object, the configuration object checks whether or not:
* The configuration directive exists
* Whether or not the directive is an alias for another one
* The value is the proper type (converting the value into the proper type if necessary; for example, we can parse comma-separated lists into arrays)
* The value is in the list of allowed values
* ...any other constraints you can think of
Right now, source files register allowed configuration directives by making a ConfigSchema::define() function call. This builds up a global "schema", which the configuration object uses to do these validations. The proposal is not to change the schema, but the method by which the schema is generated.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Refactoring configuration again... am I crazy?
I read it and am still not clear what your specific problem or solution is. Nor can I tell whether this including information you present is of general use or specific to your ConfigSchema and plugin architecture.
And can you give and example of your "include stubs" plan.
And can you give and example of your "include stubs" plan.
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Re: Refactoring configuration again... am I crazy?
The problem:
* Documentation is embedded inside PHP files which cannot be found unless they are included
* Manually building the schema at run-time is slow
* The syntax is clunky
The solution is to move documentation out of PHP files into text files, which are parsed by PHP into our internal format and then serialized for later use. This is quite specific to my architecture, but it's conceivable that someone else could use a similar structure.
As for include stubs, we hashed it to death on this thread. Basically, instead of having the user manually include every file necessary, we provide the ability to auto-generate this file based on what configuration they're using, or use a preset version which includes the basic functionality.
* Documentation is embedded inside PHP files which cannot be found unless they are included
* Manually building the schema at run-time is slow
* The syntax is clunky
The solution is to move documentation out of PHP files into text files, which are parsed by PHP into our internal format and then serialized for later use. This is quite specific to my architecture, but it's conceivable that someone else could use a similar structure.
As for include stubs, we hashed it to death on this thread. Basically, instead of having the user manually include every file necessary, we provide the ability to auto-generate this file based on what configuration they're using, or use a preset version which includes the basic functionality.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Refactoring configuration again... am I crazy?
I just missed the documentation part ... thanks for clearing that up for me.
Are there parts of your configuration architecture that you think really should be in general use configuration classes?
Are there parts of your configuration architecture that you think really should be in general use configuration classes?
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Re: Refactoring configuration again... am I crazy?
I don't know if there's any demand for it. Configuration is something integral to any application, so I imagine most people would want to do it "their way." Still, I imagine if I want to reuse it in some of my projects, I'd best keep it as generic as possible. 