New Site

I am moving the news and information about Digitalus Framework over to its new site: http://framework.digitaluscms.com/.

Digitalus Framework Core

The Dig_Core package is the base of Digitalus Framework, and should be the first thing that you install in your project. It registers the Dig library with the application and adds the core classes.

You can check it out here: 

• SVN: http://code.google.com/p/digitalus-framework/source/browse/#svn/trunk/core
• Wiki: http://code.google.com/p/digitalus-framework/wiki/Dig_Core

Package Structure

Digitalus Framework is going to be released as a set of packages, so you can export just what you need for a project, and don't have to sort through hundreds of files that you will never use.

Each package is going to follow the ZF standard project structure: /library, /public, /application

This will enable you to create a default project with Zend_Tool and then export the packages that you need into the root of the project.

I just released the first component, Dig_Core, but that is another story...

Digitalus Framework API

I constantly find myself copying and pasting library items from project to project; usually the same items. I am in the process of building a Digitalus Framework based API that will make it much easier to share this functionality.

The first component (user mgmt) is mostly done; I will release it as a private beta. If you are interested in taking part please contact me through the Digitalus Media site.

CMS Pages

The default ZF MVC structure makes a lot of sense for web applications. It only stands to reason that CRUD functions, for example, should be encapsulated in a single controller class.

On the other hand, it is difficult to explain to new developers why you need to create the controller class, a new view folder, and a view script to render a simple content page.

I think it is time to start looking at these as separate components of a CMS site. Well designed CMS sites generally consist of a number of landing pages, which load dynamic content from modules, such as news, events, or blog posts. This abstraction makes it possible to aggregate content, making the most out of your resources.

I am working on a different way to manage these pages. From a high level it works like this:

1. You build a site much like you would a static HTML site, but you build it out of Zend View scripts.
2. The CMS indexes the site folder and adds each page to the router. The CMS routes to the pages in exactly the same way that a standard site would; /about/team would render /site/about/team/index.phtml.

Each of these view scripts can have an optional controller, which is a little different than a standard Zend Controller. There is a one to one relationship between controllers and view scripts. If you render /about/team.phtml the CMS will look for a controller class in /about/TeamController.php. Since these controllers are tightly coupled with the views they are able to share information much more easily. You can access any public property in the controller from the view, without explicitly passing it.

A few Notes

• This works in addition to ZF; the rest of your application functions exactly like any other ZF application. You can still create as many controllers and modules as you need, and you should. This is where all of the data management happens.
• These views are rendered through the standard Digitalus Framework template engine.
  

Another approach to models?

I have been playing around with a couple alternatives to the single table approach that the first round of the models used. I just came up with a pretty cool alternative; a conventional db structure that the models build.  It works like this:

1. You set 'buildDb' parameter to true in your db connection options. You can do this in application.ini.
2. You create a new model class. You add fields to this class in the init() method, exactly the way to do with a form. There are types for each type of db field. Note that at this point this uses SQLite as the back end,which makes permissions much easier.
3. When you create an instance of the model it checks the buildDb flag; if it is set to true then it creates the table if it does not exist. It then confirms that each of the fields exists; creating those that do not. 
4. It also validates the type, but at this point it just throws an exception. I will probably add a clean mode option which will change types, but this will take some consideration.

Rapid CMS Development

Digitalus Framework will provide Zend Tool providers to aid in rapid application development. At this point I'm just playing with the providers, but the goal is to be able to build content types with a single command. The command will look something like this:


zf create person customer

This will do the following:

1. Create a new person model
2. Create a new person form
3. Create a new person controller, with the following actions:
1. index: this will display a list of the people, with links to open / delete them
2. open: this will open the person. Initially it will simply render a list of the properties (k => v)
   
3. create: create a new person
4. update: update an existing person
5. delete: delete the person

Each of the concrete models will contain a set of default properties. You can optionally pass a third parameter, which is a CSV list of the properties to create.

You can create models in modules by specifying the module as the fourth parameter.