[Agavi-Tickets] [Agavi] #1341: autoload_folders
Agavi
-------------------------------+--------------------------------------------
Reporter: JanS@… | Owner: david
Type: enhancement | Status: new
Priority: low | Milestone: 1.0.5
Component: config | Version: 1.0.4
Severity: major | Keywords: autoload
Has_patch: 1 |
-------------------------------+--------------------------------------------
This tiny patch enhances the autoload mechanism of agavi in a way, to
allow autoload_folder-elements.
Those autoload_folders can be used to automatically add all files of a
folder, which match a specific pattern.
'''Example Usage'''
{{{
<?xml version="1.0" encoding="UTF-8"?>
<ae:configurations
xmlns="http://agavi.org/agavi/config/parts/autoload/1.0"
xmlns:ae="http://agavi.org/agavi/config/global/envelope/1.0"
parent="%core.config_dir%/autoload.xml">
<ae:configuration>
<autoload_folders>
<autoload_folder
pattern="/^.+\/(.+)\.(interface|class)\.php$/i">%core.lib_dir%/services/</autoload_folder>
</autoload_folders>
</ae:configuration>
</ae:configurations>
}}}
'''Implementation details'''
Since this is done all at compile time, the resulting
cache/config/autoload_xml_*.php should be exactly the same size.
Performance is only lower, in case one has %core.debug%=true. In this case
it would automatically find new classes.
If %core.debug%=false the autoload_folders behave the same like xincludes.
The cache has to be cleared to find new files added to the folder.
--
Ticket URL: <http://trac.agavi.org/ticket/1341>
Agavi <http://www.agavi.org/>
An MVC Framework for PHP5
_______________________________________________
Agavi Tickets Mailing List
tic...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/tickets
Agavi
-------------------------------+--------------------------------------------
Reporter: JanS@… | Owner: david
Type: enhancement | Status: new
Component: config | Version:
Has_patch: 1 |
-------------------------------+--------------------------------------------
* version: 1.0.4 =>
* milestone: 1.0.5 => 1.1
Comment:
Not a completely terrible idea (I would maybe use named subpatterns), but
the problem with this is that you can't have a class structure like Zend
Framework's (although that might not be necessary).
--
Ticket URL: <http://trac.agavi.org/ticket/1341#comment:1>
Agavi
-------------------------------+--------------------------------------------
Reporter: JanS@… | Owner: david
Component: config | Version:
Keywords: autoload | Has_patch: 1
-------------------------------+--------------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
#1454 is the simpler, better and more future-proof option for this...
--
Ticket URL: <http://trac.agavi.org/ticket/1341#comment:2>
Agavi
-------------------------------+--------------------------------------------
Reporter: JanS@… | Owner: david
Priority: low | Milestone: 1.1
Component: config | Version:
Severity: major | Resolution: wontfix
-------------------------------+--------------------------------------------
Comment(by JanS@…):
Nice to see namespace support in agavi. But I would argue that this is an
improvement over registering multiple autoloaders nor over having x
elements in php's require-path.
The idea of autoload folders is to have agavi's autoload-system at compile
time to use key (ClassName) + value (destination of file) to decide,
whether the file can be loaded or not.
It should be possible to have Zend-Frameworks Class-Structure if you add a
simple str_replace for '/' to "_" in path to retrieve the class name.
--
Ticket URL: <http://trac.agavi.org/ticket/1341#comment:3>
Agavi
-------------------------------+--------------------------------------------
Reporter: JanS@… | Owner: david
Priority: low | Milestone: 1.1
Component: config | Version:
Severity: major | Resolution: wontfix
-------------------------------+--------------------------------------------
Comment(by david):
But why not migrate your stuff to PSR-0 or use Zend_Loader if it's not
using namespaces yet? I don't see the benefit of {{{glob()}}}ing stuff.
You'd usually have some kind of class prefix and delegate handling of that
prefix to an autoloader who can then just {{{include()}}} without further
checks (since it's reasonable to assume that if has full control over all
classes under the prefix).
Agavi of course is a different story in that it must use a class map
because its class and package hierarchy does not follow a fixed pattern,
but that's an unfixable situation for 1.x :(
--
Ticket URL: <http://trac.agavi.org/ticket/1341#comment:4>