Naming Resolution

Thanks for your feedback on “File Mapping” post. We respect your feedback and have decided on the basic set of rules regarding class naming.

• All classes will start with either “Controller”, “View”, “Model”, “Api”, “Exception” , etc. We are also going to use CamelCase. Developers are free to introduce their own groups.
• Second part of the class, separated by “_” is going to be “Area”. “Core” is going to be used by the toolkit. Additional modules will resort to their own areas. For instance Controller_Billing_PayPal.
• There is going to be location for defining default classes. They are going to be defined like this:
  • class Page extends View_Core_Page {}
  • class Controller extends Controller_Core_generic {}
  • class Grid extends View_Core_Grid {}
  • if you wish to use your own grids in the system, you will have to create file lib/Grid.php which would extend any class of your choice. This way we can achieve maximum portability.
• As you know – Agile Toolkit does not like abstract classes. However if we are to use any abstract classes they will be named “generic”. For instance – Api_Core_generic.
• We are also going to use some default models:
  • Model_User
  • Model_Payment
  • Model_Subscription
  • those will be defined as: class Model_Payment extends Model_Billing_Payment. If you wish to add more fields to the payment classes – you can substitute it with your own. It’s recommended that you also inherit your class from Model_Billing_Payment, however it’s not mandatory as long as you make sure all the fields are in place.
• All classes will be auto-loaded from lib and atk/lib by default, but you can add more locations through addLocation. Pages are loaded from page/<page_name> which will be automatically brought to lower-case. One page may no longer inherit other page, they must inherit pages from lib/Page.
  • page classes now should be named p_<page> however page_ will also work for compatibility. This is to avoid clashes with library page names, such as Page_Billing_Payments.

As before, philosophy of Agile Toolkit remains strong with:

• trying to avoid constants
• no static classes
• we encourage use of public methods and properties. This helps in fine-tuning classes on individual basis, where necessary.
• quickest possible creation of new application.
• no namespaces
• no global variables
• even more security