[Agavi-Dev] Move autoload.xml loading to bootstrap()

[David Zülke]

http://pastie.org/770456

Any objections?

- David

[Mike Seth]

David Zülke wrote:
> http://pastie.org/770456
>
> Any objections?
>
Perhaps it would be better to do this *after* settings.xml and not
before? Reading settings.xml would almost certainly yield
no runtime effects that need something out of the autoload list to be
loaded; on the other hand, autoload.xml may use configuration
values declared in settings.xml. I imagine this is conceivable:

<autoload
name="Dogtrine">/tmp/argh/Dogtrine/%org.rage.wtf.version_that_works_today%/Dogtrine.class.php</autoload>

_______________________________________________
Agavi Dev Mailing List
d...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/dev

[Mike Seth]

Mike Seth wrote:
> David Zülke wrote:
>> http://pastie.org/770456
>>
>> Any objections?
>>
> Perhaps it would be better to do this *after* settings.xml and not
> before? Reading settings.xml would almost certainly yield
> no runtime effects that need something out of the autoload list to be
> loaded; on the other hand, autoload.xml may use configuration
> values declared in settings.xml. I imagine this is conceivable:
>
> <autoload
> name="Dogtrine">/tmp/argh/Dogtrine/%org.rage.wtf.version_that_works_today%/Dogtrine.class.php</autoload>
>
>

Oh wait, there's no directive substitution inside the value itself, is
there? Silly me.

In either case if it can be guaranteed that parsing of autoload.xml
doesn't actually cause execution of any third party code that may depend
on settings.xml then I don't think there's a problem.

[David Zülke]

The first config compilation triggers the compilation of
config_handlers.xml (which is done through a static mapping for the
config handler definition). After that, autoload.xml is compiled, then
settings.xml. The settings.xml compilation might depend on autoloads
(e.g. for the assigned config handler). I'd rather not change that
order...

[Mike Seth]

David Zülke wrote:
> The first config compilation triggers the compilation of
> config_handlers.xml (which is done through a static mapping for the
> config handler definition). After that, autoload.xml is compiled, then
> settings.xml. The settings.xml compilation might depend on autoloads
> (e.g. for the assigned config handler). I'd rather not change that
> order...

Makes perfect sense.