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
Monday, August 31, 2009
STATIC PAGES
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.
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.
Sunday, August 30, 2009
APPLETS
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.
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
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!
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
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
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.
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
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:
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.
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)
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
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.
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.
Subscribe to:
Posts (Atom)