Articles

Anahita Project

Anahita Project's Articles

Arash Sanieyan

Arash Sanieyan

December 29 2011

Anahita High Level Overview

This tutorial covers a very high level look on the Anahita platform and its work flow from when a user request hits the server until a response is returned back to the user. It also covers a MVC design pattern is used within a component.

The Anahita platform is made of following elements

  1. components (apps)
  2. modules
  3. plugins
  4. templates
Components (App) are the main extensions that actually perform tasks based on the request and return an output or redirect a user to another page. A component often has an admin side and an app side (front). Admin side is normally for configuring a component behavior and the app side is the main portal where a user interacts with a component. For example for the app com_photos the directories ROOT/components/com_photos and ROOT/administrator/components/com_photos represent the app and the admin side respectively.

Modules are blocks of HTML that fits somewhere on the final output based on its configuration.

Plugins are event observers. During handling a user request, some system events are generated, Plugins are a way to intercept those event calls to accomplish certain tasks

Templates combines the outputs returned from the modules and a component to renders the final output to the user.

When a user request hits the server, Anahita parses the request URL to see which component to call. This process is called Routing. The requests must always contains the name of the component (app) in their URL in the format of "index.php?option=com_[COMPONENT_NAME]" where COMPONENT_NAME refers to the name of the component. For example

index.php?option=com_photos

is referring to the component com_photos located at ROOT/components/com_photos.

Once Anahita knows which component is being requested, it passes the control to the component entry file which is always located at

ROOT/components/com_[COMPONENT_NAME]/[COMPONENT_NAME].php

then Anahita waits until an output is returned or the user is redirected to another page.

So in our example with com_photos, the entry file would be located at

ROOT/components/com_photos/photos.php

Where's the MVC happening ?

A component is primary made of three elements Controllers/Domain Entity/Views. This structure is generally known as Model/View/Controller. To learn more about generic behavior of MVC, please read http://www.phpwact.org/pattern/model_view_controller and http://en.wikipedia.org/wiki/Model-view-controller

To explain in a most simple and generic fashion, A controller analyze a request, fetches the appropriate data (entities) and then passes them to the view to render the HTML output.

If a request is a POST request (like when submitting a form), then the controller analyze the request, perform a task, store the appropriate data and then redirects the user to another page.

A set of Controller/Domain Entity/View that manages one resource type is called a MVC stack. Depending on the number of resource types a component manages, a component may contains one or many MVC stacks. For example the com_photos app contains two MVC stacks one for managing photo resources and one for managing album resources. You can see that by counting the number of controllers it contains (http://svn.anahitapolis.com/photos/branches/1.6-branch/code/site/controllers/)

When the control is passed to a component, the component entry file dispatches the appropriate MVC stack within the component by examining the view parameter in the request. The singular value of the view parameter always refers to the name of the controller within the component. For example the following request URLs points to the photo controller in the com_photos

index.php?option=com_photos&view=photos //singular value of photos = photo index.php?option=com_photos&view=photo

and the following request URLs points to the album controller in the com_photos

index.php?option=com_photos&view=albums //singular value of albums = album index.php?option=com_photos&view= album

When the controller name is determined, then the entry file dispatcher, instantiate the controller object and ask the controller to perform a task by calling an action on the controller object. Actions are special methods in the controller object that perform fetching/storing and rendering HTML view. They can be spotted in a controller class definition as methods that have the _action[ActionName] prefix (http://svn.anahitapolis.com/photos/branches/1.6-branch/code/site/controllers/photo.php)

By default, the action value is set to the request type. There are two types of request GET and POST (submitting a form). So for the GET requests _actionGet is performed and for the post requests _actionPost is performed on the controller. If an 'action' parameter is passed in the request then value of the 'action' parameter is used as the task to perform. Please note that it's only possible to pass an action parameter in POST request and not GET. Any action parameter in the GET request is discarded for the security reasons.

When the the task is perform by the controller, the entry file dispatcher return the output to Anahita.

The above explains Anahita MVC in the most generic form, however, there are exceptions and special tricks that can be used to bend the power of Anahita to one's need. In the next tutorial, I will cover how to build a simple Anahita app from scratch.

#anahita #platform #mvc #designpattern #entity

3 people liked this
Zhuo Song
Zhuo Song
December 29 2011 Permalink
This is a definitely NEW YEAR GIFT. Thanks.
Terry Irish
Terry Irish
December 31 2011 Permalink
Thanks for the overview. Very helpful.
Umesh
Umesh
January 02 2012 Permalink
@Arash / @Rastin - Thanks a lot!!! This is really helpful and waiting for next article in this series
Patrick Thach
Patrick Thach
January 03 2012 Permalink
Thanks a lot I like this kb
Zach Furniss
Zach Furniss
January 05 2012 Permalink
Much appreciated!

Additional Information

Powered by Anahita