Digitalus Framework

New Site

2010-03-08T15:02:00.000-08:00

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

Digitalus Framework Core

2009-09-30T14:46:00.000-07:00

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:

Package Structure

2009-09-30T14:43:00.000-07:00

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

2009-09-28T18:04:00.000-07:00

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

2009-09-25T11:18:00.000-07:00

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:

You build a site much like you would a static HTML site, but you build it out of Zend View scripts.
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?

2009-09-12T20:08:00.000-07:00

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:

You set 'buildDb' parameter to true in your db connection options. You can do this in application.ini.
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.
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.
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

2009-09-05T21:03:00.000-07:00

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:

Create a new person model
Create a new person form
Create a new person controller, with the following actions:

index: this will display a list of the people, with links to open / delete them
open: this will open the person. Initially it will simply render a list of the properties (k => v)
create: create a new person
update: update an existing person
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.

Prototype

2009-09-03T19:41:00.000-07:00

The working prototype of Digitalus Framework has shown that the project has a ton of potential; it makes building custom CMS solutions easy, and that is the name of the game.

I just moved the prototype to a new tag, and cleaned out the trunk. I will replace the files as they are:

cleaned up
documented
unit tested

When this is done I will push out version 0.1!

Link Manager

2009-09-03T12:59:00.000-07:00

There are always a number of utility methods that you need to be able to use site wide but are specific to your site. I have used many approaches to this challenge and just tried a solution which involves utility plugins.

The first implementation is the LinkManager, which helps you fetch the right URLs to open dynamic content items with.

You configure them in application.ini:

resources.util.LinkManager.Forum_Model_Forum.open = "/forum/forum/open/{id}"

And then you can fetch the LinkManager from the Digitalus Core:

$linkManager = Dig_Core::getInstance()->getUtil()->LinkManager;
$forum = new Forum_Model_Forum(4);
echo $linkManager->getOpenModelUrl($forum);

Link Lists

2009-09-03T11:27:00.000-07:00

I have no idea how many times I have created a list of links, but its quite a few. I've written a couple different functions to make it easier, but none has stood the test of time.

I just put together one that ties into Digitalus models and supports link templates; its a big time saver.

Say for example you are rendering a list of links to threads.

$threadList = $this->linkList($threads, "<a href='/forum/thread/open/id/{id}'>{subject}</a>");

The helper searches the template and populates it with data from the threads.

REQUEST PARAMETERS

2009-09-02T14:59:00.000-07:00

I was never happy with the way that Digitalus handled URI parameters. We handled them outside the scope of Zend_Controller_Front and then manually set the request params. This is an effective way, but not as elegant as fuller integration.

I just created a new resource plugin for the application which parses the URI, then creates a new instance of Zend_Controller_Request_Http, and sets it up approapriately.

You set the separator in your application.ini file like this:

resources.request.paramSeparator = "p"

Then you can pass URI parameters like this:

/page/subpage/p/param/1

The trick here is the fact that this is done prior to the front controller being dispatched; this means that the front controller is none the wiser that you altered the URI; the technique works for your CMS pages as well as the ZF application pages (which use MVC routing).

PAGINATING CONTENT ITEMS

2009-09-02T12:42:00.000-07:00

I just ran into an issue that will likely come up many times; how to paginate model result sets. Zend Framework has the Zend_Paginator component, but the closest adapter to use would be the DbTableSelect adapter, which returns a Zend_Db_Table_ResultSet.

I could have made this work, but decided to try and write a Zend_Paginator adapter. It turns out (at least in this case) it was incredibly simple.

I copied the DbTableSelect adapter, which only has one method, get items.
I updated the constructor to take a Dig_Model rather than a select object. It sets the model, and then passes the model's select object down to the parent Zend_Paginator_Adapter_DbSelect class.
I updated the getItems method, so it uses the model's fetchAll() method, rather than the Zend_Db_Select fetchAll() method.

INTEGRATING THE DIG_FORM WITH MODELS

2009-09-01T22:46:00.000-07:00

I was just working with some comments and saw a familiar pattern for updating a model:

Get the values from the form.
Create an instance of the model.
Populate and save model.

I added a method to the Dig_Form class that should make this easier; getValuesAsModel(). You pass this method the class name of a model, and creates an instance and loads it for you.

$modelPost = $formPost->getValuesAsModel('Blog_Model_Post');

I added a second convenience method to this, saveToModel(), which you pass the name of a model to. It fetches the model (using the getValuesAsModel method) and saves it.

Digitalus Forms

2009-09-01T19:15:00.000-07:00

Digitalus Form is a fairly straight implementation at this point;

Digitalus Form adds a hash control to avoid cross site attacks.

The validatePost() method does a few things that you need to do every time you process a form. It:

determines that the request method was post
loads the post
validates the form

If the form is valid it returns true, otherwise it returns false.

The populate() method accepts a Digitalus_Model as the argument (as well as an arrray).

There is a getReferrer() method tells you which page submitted the form.

SIMPLIFYING THE DATA FOLDERS

2009-08-31T13:43:00.000-07:00

Providing multiple site / environment support for the site data (database and site tree) has been a key requirement from the start. I have worked on a few solutions, including having sections in the site tree file, but I am thinking that this is more confusing than separate files.

I am going to move these into folders, which hold a site tree and db file. You will then be able to add domains as necessary; just copy the default folder and rename it after the domain (eg: dev.digitalusframework.com).

/ data
     / default
         site.xml
         db.sqlite

STATIC PAGES

2009-08-31T08:08:00.000-07:00

Many CMS solutions (including the ones that I have developed) have limited support for static pages. I suppose the mindset is that with all those bells and whistles who would ever need a static page, but I beg to differ.

I like having the capability to work with static pages within the CMS, so I am adding this functionality to Digitalus Framework.

When you create a static page you can specify the URL or let the CMS create that for you. Your URL should map to the file in the static views folder (application/modules/digitalus/views/scripts/page/static), so for example a static page at about/directions would look for a file in ~static/about/directions.phtml.

APPLETS

2009-08-30T23:22:00.000-07:00

One of the most consistent issues I run into with web applications is add-ons or what ever term you prefer for them. Basically, the issue that I run into is my elegantly complicated system does not include a simple way to get something simple done.

Applets are an alternative with Digitalus Framework. Applets are mini programs which you can plug into pages. They are much simpler to write than modules, but are only really appropriate for simple functions like a link list or rss reader.

I am checking in the current implementation, which will almost definitely change some as we work with them. I will add a doc to the wiki once I have everything wired up and working.

UNOBTRUSIVE CMS

2009-08-30T19:43:00.000-07:00

I always sort of wondered what jQuery means about unobtrusive JavaScript. I assume it has to do with how gracefully it degrades, but it could have other meanings as well.

I am personally using the term to describe Digitalus Framework as well. In this context it means to the the CMS is more of a platform than a specific application. It is there waiting to make your job easier but you don't have to jump through any hoops in order to use it.

If a component makes you life easier than use it; if writing a snippet of code your self is easier then by all means do it!

FRAMEWORK UPDATES

2009-08-30T19:15:00.000-07:00

I just added the project SVN log feed to the sidebar of this site. Google code has a ton of feeds now so subscribe away. And if anyone figures out how to filter a feed with blogger let me know. I need to get rid of the 'updated wiki' messages!

Links
Project Information	Gadget
Project Updates	Atom
Downloads	Atom \| Gadget
Wiki	Atom \| Gadget
Issue Updates	Atom \| Gadget
Issues	Gadget \| CSV
SVN Source Changes	Atom \| Gadget
Hg Source Changes	Atom
Code Search	Gadget

THE DIGITALUS FRAMEWORK BOOK

2009-08-30T13:17:00.000-07:00

I am working on a book about Digitalus Framework in conjunction with the actual project. I was reading about the agile writing approach on the Pragmatic Bookshelf site and decided to give it a try.

It makes sense; writing about what you are working on at the moment is fun and it forces you to take the time to consider what it is you are doing from a different perspective. Trudging through chapter after chapter after the fact is much more like work!

I am releasing the alpha version of the book in the wiki as I write it.

INTEGRATING NAVIGATION WITH THE TREE

2009-08-30T11:28:00.000-07:00

I had some issues with Zend_Navigation that I could not work around. It provides tons of functionality, but is difficult to extend.
The following were key requirements:

It had to be easier to create custom page types
Less verbose, simpler site tree (though the CMS will be doing this)

After many tries i settled on a fairly simple approach that gives us the flexibility to have our way with navigation, but still uses the core Zend_Navigation component as much as possible. This enables you to use the standard Zend_View navigation helpers.

Basically it works like this: The site resource loads an XML site tree which it registers with Digitalus Core. Then the navigation resource fetches the tree's pages, builds the navigation object, and registers each of the pages with the front controller router as static routes.

WHAT DIGITALUS FRAMEWORK IS ALL ABOUT

2009-08-30T11:09:00.000-07:00

As I got started conceptualizing Digitalus 2 it became clear that the Zend Framework had evolved a great deal since building the 1.x release. It now offers a great deal of the functionality that is required for a CMS, but this is often confused by the mountains of configuration options. So before I could really get into building Digitalus 2 I need to try out the new tools and figure out what works for Digitalus.

After tooling around for a bit (and some advice from core ZF developers) I decided to build a CMS framework that aims squarely at the 80% side of the 80/20 rule. The whole thing will be built on ZF, and stock ZF components will be used whenever they make sense. Digitalus will build on to this base creating default components that you can use with little or no programming.