Documentation


SEARCH

TABLE OF CONTENT

    1. Getting started 2. Basic concepts 3. Request dispatching 4. Context container 5. Dual MVC 6. Component model: 7. Security 8. Configuration 9. Session handling 10. I18n 11. Cache 12. Logging 13. Error handling 14. Advanced Topics 15. API reference

      Tutorials: Frequently Asqued Questions

      See also:


      The Class Loader

      Class file lookup

      Table of Contents

      Lion class loader

      Lion has a class loader, a class in charge of locate and include class files on demand, it is, as soon as they are needed by the code).
      The main advantage of the class loader is the fact that it saves the effort of maintain and organize include directives, because it allow us to declare where our files are located in.

      The class loader allow to map classes with their files by declaring rules in the includepath file (/app/config/includepath.xml).

      We can group classes containing in the same directory by ussing the cluster tag. A cluster has an attribute to let the framework know where files are located in (all paths in a cluster are relative to the application):

      1. <?xml version "1.0" standalone="yes"?>
      2. <classes>
      3.  
      4.   <cluster name="My classes" path="/libs/classes">
      5.     ...
      6.   </cluster>
      7.  
      8. </classes>

      Inside a cluster we can declare in which files are located our classes as well as our interfaces by ussing the class and interface tag respectively:

      1. <?xml version "1.0" standalone="yes"?>
      2. <classes>
      3.  
      4.   <cluster name="My cluster" path="/libs/classes">
      5.     <class name="MyClass" file="MyClass.php"/>
      6.     <interface name="MyIFaz" file="MyIfaz.php"/>
      7.   </cluster>
      8.  
      9. </classes>

      We can also use wildcards in order to establish naming conventions.
      i.e. We can declare that whatever file with the suffix .class.php in a cluster corresponds to a class with the same name of the file (i.e. the file MySuperCoolController.class.php contains the definition of the MySuperCoolController class)

      1. <?xml version "1.0" standalone="yes"?>
      2. <classes>
      3.  
      4.   <cluster name="My classes" path="/libs/classes">
      5.     <class name="*" file="*.class.php"/>
      6.   </cluster>
      7.  
      8. </classes>

      Finally, we can map a cluster to a directory and all the sub-directories recursively by ending the path with 3 dots (...)
      i.e.

      1. <?xml version "1.0" standalone="yes"?>
      2. <classes>
      3.  
      4.   <cluster name="My classes" path="/libs/classes/...">
      5.     <class name="*" file="*.class.php"/>
      6.   </cluster>
      7.  
      8. </classes>

      So, in this example we are applying the same naming convention, affecting not just to files containing in /libs/classes but all the files in all the sub-directories recursively.

      includepath.xml files

      Whatever file names as includepath.xml and located wherever you prefer is read by the class loader in order to get mapping rules.
      Initially we have the app/config/includepath.xml file with the following content:

      1. <?xml version "1.0" standalone="yes"?>
      2. <classes>
      3.  
      4.   <!-- Components -->
      5.   <cluster name="Components" path="/libs/components/...">
      6.     <class name="*" file="*.class.php"/>
      7.     <interface name="*" file="*.interface.php"/>
      8.   </cluster>
      9.  
      10.   <!-- Event Handlers -->
      11.   <cluster name="Event Handlers" path="/libs/eventhandlers/...">
      12.     <class name="*" file="*.class.php"/>
      13.     <interface name="*" file="*.interface.php"/>
      14.   </cluster>
      15.  
      16.   <!-- Controllers -->
      17.   <cluster name="Controllers" path="/libs/controllers/...">
      18.     <class name="*" file="*.class.php"/>
      19.     <interface name="*" file="*.interface.php"/>
      20.   </cluster>
      21.   
      22.   <!-- Model classes -->
      23.   <cluster name="Model" path="/libs/model/...">
      24.     <class name="*" file="*.class.php"/>
      25.     <interface name="*" file="*.interface.php"/>
      26.   </cluster>
      27.  
      28.   <!-- Plugin classes -->
      29.   <cluster name="Plugins" path="/libs/plugins/...">
      30.     <class name="*" file="*.class.php"/>
      31.     <interface name="*" file="*.interface.php"/>
      32.   </cluster>
      33.   
      34. </classes>

      Here we have defined some clusters, so Lion will search recursivelly for files matching the defined patterns in order to establish the mapping between classes/interfaces and their respectively files.

      However, all of them have the same naming convention: Classes are contained in files with the same name plus the suffix .class.php while interfaces use the suffix .interface.php

      Benefits of using the class loader

      There are 3 main benefits on using the class loader:

      • To avoid the use of include directives within php files. On small project this doesn't matter, but on relative big projects it becomes a great advantage.
      • As consequence of the previous point, refactoring the code by moving files from one to other folder is a really easy task because just implies to adapt the specific includepath files without altering the code at all.
      • To plug new libraries ready to use on lion by just adding new includepath files. Again, code does not need to know where libraries are located on.