Ning Architecture Basics

Ning is an online platform for creating your own social networks and social applications.

The Ning Content Store is a semi-structured relational database that stores all the content that is contributed to the social networks and applications across Ning.

The Ning Content Store has a couple of key benefits:

• Requires no database to set up or manage in order to run a social network.
• Automatically organizes your network's content with additional metadata: who contributed the content, which network owns the content, and the tags members have applied to that content.
• Enables fluid data sharing between networks running on (and off) Ning.

The Ning Core is the main engine of Ning built in Java and where the magic happens. It's where we've added all of the core services of the Ning Platform, including:

• OS Functions
• User Account Functions
• Content & Functions
• Application Management
• Media
• Mobile
• Social Networking
• Advertising
• Web Services
• Premium Services
• Cross-Application Content and Code
• APIs & Feed Auto-Generation
• Location Services

With Ning, almost everything offered on applications are actually core services accessed via our REST APIs, PHP APIs, and Javascript APIs. Both applications on Ning as well as external websites can use these APIs.

This architecture enables rapid development of new features. Most of the work is taken care of by the Ning Core and accessed by applications via APIs.

The Ning Playground is a language-neutral sandbox/run-time for creating and running social networks and applications. Today, applications on Ning are created in PHP and Javascript, using our PHP and Javascript APIs. In the future, this architecture can be expanded to support new scripting languages like Ruby, Perl, and others.

Every application in the Ning Playground automatically generates its own REST APIs and RSS/ATOM feeds. This makes taking data feeds from your new social network, or any application on Ning, very simple. Web Services are built it. So, for example, if you'd like to back-up your data on your own servers, you can do so by taking a REST, ATOM, or RSS feed of that data.

Summary

The Ning Platform make building social networks and social applications much easier and faster than building one on your own servers with your own database.

Changing PHP & HTML

Your network is built using Ning's Web Widget Framework (WWF), which makes things a little difficult at the beginning but makes it easy to change your network's behavior once you know what to look for.

WWF Basics

Controllers, Actions and Views

Finding the location of the code you want to modify is easy once you know some rules about how URLs in the network relate to the file structure of the network's code. WWF follows an MVC (Model-View-Controller) pattern. Each URL in the network includes a controller and an action, and each action generally uses one view, or template.

A controller is a class with one method for each of a group of related actions, and a view is a template which some dynamic information is plugged into to generate some output. The controller name and the action name in the URL tell you where to look to tweak the network.

For example, consider the My Videos page in the Videos Network:

http://videos.ning.com/index.php/main/video/new

The http://videos.ning.com/index.php/main bit is part of pretty much every page in the network. The interesting parts of the URL are the video and the new, where "video" is the controller responsible for this page and "new" is the action responsible for this page.

In general, then, WWF pages follow this pattern:

http://site/index.php/main/controller/action

Inside a Controller

All of the controllers are under the network's "/widgets/video/controllers" subdirectory, each in a different PHP file. To get the right file for a controller, capitalize the controller name, slap "/widgets/video/controllers/" before it, and add "Controller.php" to the end. For example, in the case of the videos module, the "video" controller specifically resides in a file named "VideoController.php". Another example: the "user" controller is at "/widgets/video/controllers/UserController.php".

Continuing with the videos example, inside the "VideoController.php" file is one class. This controller class defines methods for each action it knows about. The method for the "new" action is called "action_new". The method name for any action is just "action_" and then the action name.

Aside from the action methods, there are two special methods for controller classes: "_before" and "_after". If there's a "_before" method, the code in it is run before any action method. If there's an "_after" method, the code in it is run after any action method.

Any other methods in the controller class (aside from the "action_" methods, "_before", and "_after") are regular methods that don't get called automatically when processing a certain action but can just be helper methods that you explicitly call from other code.

Actions and Templates

Action methods typically do some calculations that determine what is going to be displayed for output and then they set some instance variables on the controller object containing data that the template file needs. After the action method is finished executing, the appropriate template file is loaded and generates output using those instance variables.

The "action_new" method in the "video" controller corresponds to the template (aka, the view) that lives at "/widgets/video/templates/video/new.php". Just as controller filenames do, template filenames have the "/widgets/video" prefix. Then, they are under a "templates" directory instead of a "controllers" directory. Under the "templates" directory is one directory for each controller: "video", "user", etc. Inside the controller-specific directory is one file per action. The "new.php" file goes with the "action_new()" method.

Other Network Files & Code

Not everything in the network is under the "/widgets/" directory. In particular, static resources such as images, style sheets, and Javascript files can be found under the /xn_resources/widgets directory for each corresponding widget.