Additions:
Deletions:
Additions:
Additions:
Deletions:
Additions:
Additions:
Deletions:
Additions:
Deletions:
Additions:
Aliro is often distributed along with a number of add-ons, which are automatically installed during the installation of Aliro. But the actual Aliro framework does not have any user oriented applications built into it. This gives the maximum flexibility to leave out applications that are not needed for an application. And any application produced by the Aliro team can be replaced by an alternative.
Another group of classes are normally used by invoking their methods. Writers of add-ons should only invoke those methods that are described within the documentation here. The methods that are documented constitute the API for the class, from the standpoint of encapsulation. Object properties are not normally considered part of the API. The reason for restricting extension writers to use of the API methods is that they provide the services that are designed to be used generally. Every effort will be made to keep the API unaltered, although ongoing development will not always be able to achieve this. There could also be a legal implication. It is an Aliro policy that software that makes use of the API is not regarded as derived from Aliro, when it comes to interpreting the GPL.
You might ask why the classes in this group should have public methods that are not part of the API. The answer is that the notions of public, private and protected do not give sufficient control in all cases. The usual reason a method is made public but not part of the API is that Aliro includes within it frameworks of cooperating classes that need to use each other's methods. But the fact that a method has to be public because it is used in other related classes does not necessarily mean that it should be part of the API for add-ons.
These limitations are intended to enhance the robustness of Aliro, they are not intended to restrict add-ons or make their development more difficult. On the contrary, they are intended to make the whole system, both Aliro and the add-ons, more robust by having clear understandings of an API that can be relied on. They are also intended to clarify the legal position of extensions. Should an extension developer have any difficulty with the API provided, the Aliro team is always open to the possibility that the API should be developed or changed. The Aliro team is always willing to help add-on developers to get the best out of Aliro, and is extremely interested in add-on developers' experiences or suggestions on how Aliro can progress to be more helpful to add-on development.
Building Add-Ons - Applications
Deletions:
Aliro is often distributed along with a number of extensions, which are automatically installed during the installation of Aliro. But the actual Aliro framework does not have any user oriented applications built into it. This gives the maximum flexibility to leave out applications that are not needed for an application. And any application produced by the Aliro team can be replaced by an alternative.
Another group of classes are normally used by invoking their methods. Writers of extensions should only invoke those methods that are described within the documentation here. The methods that are documented constitute the API for the class, from the standpoint of encapsulation. Object properties are not normally considered part of the API. The reason for restricting extension writers to use of the API methods is that they provide the services that are designed to be used generally. Every effort will be made to keep the API unaltered, although ongoing development will not always be able to achieve this. There could also be a legal implication. It is an Aliro policy that software that makes use of the API is not regarded as derived from Aliro, when it comes to interpreting the GPL.
You might ask why the classes in this group should have public methods that are not part of the API. The answer is that the notions of public, private and protected do not give sufficient control in all cases. The usual reason a method is made public but not part of the API is that Aliro includes within it frameworks of cooperating classes that need to use each other's methods. But the fact that a method has to be public because it is used in other related classes does not necessarily mean that it should be part of the API for extensions.
These limitations are intended to enhance the robustness of Aliro, they are not intended to restrict extensions or make their development more difficult. The are also intended to clarify the legal position of extensions. Whenever an extension developer has difficulty with the API provided, the Aliro team are always open to the possibility that the API should be developed or changed. The Aliro team is always willing to help extension developers to get the best out of Aliro, and is extremely interested in extension developers' experiences or suggestions on how Aliro can progress to be more helpful to extension development.
Additions:
Additions:
Deletions:
Additions:
Additions:
Additions:
These limitations are intended to enhance the robustness of Aliro, they are not intended to restrict extensions or make their development more difficult. The are also intended to clarify the legal position of extensions. Whenever an extension developer has difficulty with the API provided, the Aliro team are always open to the possibility that the API should be developed or changed. The Aliro team is always willing to help extension developers to get the best out of Aliro, and is extremely interested in extension developers' experiences or suggestions on how Aliro can progress to be more helpful to extension development.
Aliro Framework
Aliro is often distributed along with a number of extensions, which are automatically installed during the installation of Aliro. But the actual Aliro framework does not have any user oriented applications built into it. This gives the maximum flexibility to leave out applications that are not needed for an application. And any application produced by the Aliro team can be replaced by an alternative.
Apart from a few lines of code, and a tiny number of functions, Aliro's PHP code consists entirely of classes. The classes tend to fall into three groups, which are documented separately. One group is entirely internal to Aliro, although they will often be parents of classes in the other groups. They will not be documented here, but will be listed.
Another group of classes are normally used by invoking their methods. Writers of extensions should only invoke those methods that are described within the documentation here. The methods that are documented constitute the API for the class, from the standpoint of encapsulation. Object properties are not normally considered part of the API. The reason for restricting extension writers to use of the API methods is that they provide the services that are designed to be used generally. Every effort will be made to keep the API unaltered, although ongoing development will not always be able to achieve this. There could also be a legal implication. It is an Aliro policy that software that makes use of the API is not regarded as derived from Aliro, when it comes to interpreting the GPL.
You might ask why the classes in this group should have public methods that are not part of the API. The answer is that the notions of public, private and protected do not give sufficient control in all cases. The usual reason a method is made public but not part of the API is that Aliro includes within it frameworks of cooperating classes that need to use each other's methods. But the fact that a method has to be public because it is used in other related classes does not necessarily mean that it should be part of the API for extensions.
The other main group of classes are normally used by subclassing from them. In this case, all the protected methods and any protected properties are available to subclasses. Also, methods and properties can be overridden if that is considered desirable. It seems fairly clear that subclassing from an Aliro class makes the new class a derived work. For that reason, following the Aliro policy of fully supporting open source yet being open to those developers who do not feel able to fully embrace it, the classes intended to be subclassed are licensed using the LGPL.
Internal PHP Classes
Non-extendable PHP classes
Extendable PHP classes