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.
5:18 amFuture Theming
Currently, themes are separate from applications, although they are an integral part of the template selection process. Themes control the content central to a page, even while an application can determine which theme or page template will be displayed. I've left a lot of the options for theming in Clay on the drawing board, in the hope that people will join the discussion and help determine the future of theming in Clay. While options not offered aren't really options, the absence of a specific requirement for theming opens up a free avenue to explore and build upon. For instance, a theme today can be a page template and a stylesheet. There is no installation, only a boot loader setting to specify the default theme. I left it that way so I can use developer input to create the best possible theming system or leave it open for developers to choose/create their own options. One thing I would like to do is create an application that is used for creating and customizing themes from within the Clay package. That would create some overhead that doesn't exist with simply using a standard theme, but also make up for it with an extensible tool set for theming a site. There is a lot of work left before such an application is feasible or maintainable, but as ClayCMS and potentially other packages mature, I believe it would be a venerable asset to ClayCMS. Most modern content management systems do offer such tools, but I'm thinking more along the lines of a DreamWeaver built into the website, creating templates and stylesheets used for dynamic content, loaded dynamically as they become available. Clay's application object already supports full template overrides from the theme, so no underlying code changes would be necessary. That is the kind of flexibility I was wanting when I began building the Clay Framework.
4:57 amNext couple of Months
February is probably going to be a busy month, so I'm not sure how much time I'll have for development. The good news I've finally settled into my Dev environment a little better, so I have made some progress. Once I have time to run a full line of tests on my current code, I'll be doing a refresh here and pushing ClayCMS to the github repo on github.com/clay. I know there are a few things that need to be fixed/tweaked. From there I plan to keep this site updated with the current codebase and begin doing some releases. I will more than likely release small pieces at a time. My plan right now is to release Clay Framework, followed by the Installer, and probably a few packages, tests, and themes. I'm going to have to stick to Alpha release mode until I have more documentation. I don't plan to stay in beta for long on Clay Framework. It is intended to be light so most of the new functionality will come from packages and tested from there. Hopefully by March i'll have clay-project.com up and running and begin building in some community features. Also sometime in March I hope to announce a big project that will give Clay some attention. My hope is that project will help drive Clay faster and further than its gone so far.