The user home pages will also be the basis for a project manager, help system, and other community driven applications.
The dashboard is obviously my top priority at the moment and a focal point for managing the site. My hope with it is to provide a simple interface that uses privileges to show a user what he/she can do on the site. One of the things I want to do after the dashboard is in place is create a user home page. The dashboard is available from any page, using an overlay, but the user homepage is a way to communication with other users, share content, and decide what kind of content he/she wants to display to other. In a way it is like an extended multipurpose profile and the Facebook wall. The homepage will be a separate app and the basis for future improvements toward social networking. The hope is to eventually allow a user to create a website inside the ClayCMS and have applications he/she can use, although they will actually be a service hook from actual ClayCMS applications.
One of the priorities one my todo list is to finish the HTML filter. The filter will likely use a config file that stores a list of allowed HTML tags and attributes. There will be an administrative interface to add, remove, edit, etc the tags list and a service hook that will allow you to hook different HTML filters to users or content types. It's fairly straightforward and also works as an HTML tidying tool if you don't want to put restrictions on tags.
Last night I did an audit of the privileges, compared to the ones used in apps. It appears some of the privileges didn't make it into the app install processes. One of those, which I spent half an hour trying to figure out, was user registration. I was working on the dashboard and couldn't figure out why it wasn't displaying a login/register form when a guest user visited the dashboard. Guests didn't have the privilege of logging in or registering. I fixed it in the database and decided to audit the other apps for privileges. I made a note of all of the missing privileges and wrote a temporary routine into the security app to log queries of privileges that do not exist.
I worked on the Dashboard some more today. I didn't get a lot finished. I was mostly digging through the code to see what I finished a while back when I was working on it. There seemed to be some things missing, but its hard to tell if its missing or if I never implemented them. I know there is code missing some places. I fixed the blog title shortening a while back and it wasn't fixed in my current working copy. I now back up everything to a portable drive and have a backup manager that regularly backs up my Home folder to a different drive. Hopefully I wont have to worry about losing months or even years of work again. Anyway, the Dashboard will be the default dashboard. The services library allows applications to create service types and services. Any app can create a service type and any app can create/provide services for service types. Service types have a registered service provider, which provides the object interface for its services to use. A service type should never be removed. Another application can begin offering the dashboard service type and other applications simply have to use the new application's object interface (unless the new application is compatible with the old service provider's object - this would normally be the case in a transitional period). Anyway, the Dashboard will be the default dashboard service provider and there shouldnt be a need to implement the System Admin service I discussed yesterday.
I'm planning on setting a solid release date for Clay Framework 0.9. It will be an Alpha release, coming out the same time as the clay project web site. The alpha stigma is only because of a lack of documentation. I've already begun The planning stage for Clay 2, so I think that means its time to get 1.0 released haha.
I'm trying to decide if I want to make the Dashboard a default app or if I want to create a new System Admin service that acts like a content hook. The service would keep the apps broken up better, providing an interface for administration of Core apps. The other side is there aren't a lot of Core apps, so it wouldn't be that hard to hard code it into the Dashboard. But then, that makes it harder on someone of they want to create a different dashboard that uses the same service hooks other apps provide to the current Dashboard. More than likely I'll settle for some kind of admin function that loads the Core apps into the dashboard for now. The main thing is to provide an administrative interface that will allow you to have a starting point after an install.
I'm excited about Traits being added to PHP 5.4. That is something I've used workarounds by having abstract classes that simply add in a method. It works the same, but having the traits make the code easier to follow and opens up inheritance.
I finally got around to coding some last night. Fixed some bugs, which is hard when you can't remember how your own code works. It's also hard when you don't finish something and months later have to go back and figure out what was left. To add to that, I lost some code and am using a backup, so some of the code was finished and I had to rewrite it again. I am making progress at least :)
5:41 amSee a Warning?
Yes, I know about it. It was fixed long ago in the codebase. I guess my host finally upgrade PHP. That should go away once I do the site refresh.
5:38 amTruly IDE
Intregrated Development Environments are essential in streamlining and maintaining software, even though a plain text editor is still my preference most of the time. One of the planned development strategies of Clay is to implement a data transport library to transfer and authenticate data between hosts. There are several potential and desired uses for such a system, but one such use is an IDE built into a package in Clay. The package would be a web-based development environment, using its own interfaces for testing code output. The code could be created anywhere, even developed simultaneously by multiple developers. When the code is ready to deploy or ready to test on a different server, the data transport system could be used to authenticate the developer and deploy the code. The same could be done for data to/from a database, to create backups, or for replicating web sites across multiple servers. The IDE could be setup to be used with version control tools or as a seudo version control system, requiring developers to checkout and checkin code as it progressed. There are many exciting choices and considerations when you are building a framework designed to be only as much as you need it to be.