You are here

What is this?

Error message

Strict warning: Declaration of Samara_Renderer::RenderPage() should be compatible with _Samara_Renderer::RenderPage(Samara__BasePage $page) in require_once() (line 9 of /home/thego163/public_html/drupal/sites/all/modules/samara/samara/includes/renderer.php).

Samara - Academic Project

As part of a research project for my final year of Computer Science at the University of Calgary, I developed the Samara framework as a tool for creating web applications that can be integrated into content management systems or left as stand alone apps yet still be updated from the same source even after integration. The intention was to develop this framework for the purpose of developing shop software for non-profit bicycle organizations to use as outlined below.

Shop Software

What it Will Do

Nothing and anything. The software which I would like to develop will actually do noting at all on first install, but instead allow the organization to choose from a list of plugins which will fulfill their needs as this example illustrates:

This is not inteded to be the final list of plugins or even to suggest that all of these plugins will be created. Some, such as the 'Collective Community' plugins will require agreement and collaboration between parties which has not yet been decided upon. This is instead just an example of some of the ideas that might be created. Plugins may be created by anyone with a moderate amount of programming know-how and when complete can given back to the community for other organizations to make use of.

Below is an example of a page that might be seen as a result of installing the selected plugins above. Again, this is simply a sketch of what may be the result of the selected plugins and also style template, templates will customizable and shareable.

Why Might this Work?

The biggest hurdles or developing software for any non-profit bicycle organization to use is that there is a wide degree of variation between the way in which shops function and that these organizations often have also vary greatly in the technologies which they currently employ and could afford to employ. Thus a short list of requirements was developed:

  • Must be deployable (mustn't require the organization to use hosted software)
  • Must be customizable and able to easily adapt to new requirements
  • Must be compatible with most widely available technologies
  • Must be compatible with existing user systems such as Joomla, WordPress, and Drupal
  • Must be guaranteed to be maintained against the common enemy of volunteerism, volunteers who move on

When Will It Be Released?

Sometime in the future, I can't narrow it down further than that unfortunately.

Software Development

The Core

Smart data structures and dumb code works a lot better than the other way around.

At the core of the application will be the Samara framework. The logic in the core of the framework is intended to contain the highest degree of complexity in order to allow for plugins which may have a much much lower degree of complexity thus allowing for less barrier of entry to develop the core features. The framework will be developed using Object Oriented, Aspect Oriented, and Service Oriented PHP. The Aspect Oriented architecture is key to allowing extensibility but also for interoperability into existing web systems (such as content management systems). Service Oriented architecture allows for portability to non-PHP code especially keeping the idea of portability to mobile devices in mind for future development, many of which run JAVA applications.

The core, like all other aspects of development will remain open-source and new developers will be able to join when needed. The core developers will be a small group of experienced software developers which will allow for a large group of potentially less experienced plugin developers.

Plugins

The framework is intended to take care of much of the difficult work of database queries, migration, and many other aspects ranging from difficult to menial, if you have familiarity with Rails or Grails, this type of development ideal should be easily understandable. The intention is to make the plugin API as easy as possible to work with.

Hooks will be laid throughout the core to allow for plugins to intercept at the before, after, or around join points of nearly any method. It will also be trivial for plugins themselves to be extensible and thus one plugin can build onto another.

Interoperability

The around join point is the critical aspect of allowing for the application to be adopted into a larger framework such as WordPress or Drupal (as you can see on this site). Critical points of code can be modified on the fly, for example the user lookup method can be overridden to allow the application to use an alternate database table for loading and authorizing users.

Want to stay in the Loop?

If you want to receive the occasional email to let you know a new phase of development or a new release is ready please feel free to add your email address below. I promise this will be very infrequent, if it ever picks up, I'll divide the list.