My goal this week is to have CF 0.9.1 on GitHub, [hopefully] along with compatibility updates to Clay Installer. I would also like to push the ClayCMS core. ClayCMS may not make it, or I may just not push the files to the master repo yet (create an Unstable branch and put a note in the readme file about what is going on).
CF 0.9.1 includes some namespace changes, in both libraries and applications. It's some major changes, so I'm having to review and test the code to make sure everything is correct. I'm also commenting code as I do the review, which is something I've neglected quite a bit in the past.
Note: I've already pushed the namespace changes to the master repo. My goal is to have the code ready to tag as 0.9.1, which is Alpha 2 (see previous post about Clay release schedule).
I've finally figured out how to effectively use eGit in Eclipse with the different repos. It's kind of a pain, but it's better than anything else I've tried. I basically have a local repo I use for development. I have clones of the repos from Github. I use branches in my dev repo to make changes and pull in updates from the various repos. Once I've made a change in the dev repo, I pull it into the clones, verfiy all the changes made it into the clone, then push upstream back to GitHub.
Like I said, it's a pain, but I've had worse. This allows me to keep CF in its own repo, so I can continue development without effecting any of the projects using it. It also allows me to break everything up and tier the repos. I have clay-frame, clay-installer (which will soon include clay-framework), and I'll soon be pushing up claycms (which will include clay-installer, which includes clay-framework). It may seem odd, but it's the only way I can think of to ensure the project meets its goals of providing different component for different project needs.
If anyone knows me, they know I don't finish anything. Well, hopefully this time it at least works out better than normal. I believe I've finally hammered out a path to CF 1.0. The main reason I want to get there is so I can start over :) The good thing about having a new version to work on is I can build stuff for CF 1.0, while working on CF 2.0 to make it better. For a while CF 1 was too raw to build for, but now I can let the project mature around it and still look to the future. Fun time ahead :)
I've tagged the current version of Clay Framework, in the GitHub repo, as 0.9.0 (Alpha 1). I'm not publicizing it as a release, but it is the first 'complete' Alpha. Alpha 2 (0.9.1) will incorporate the new namespace changes. It will not be publicized either (other than here of course). Finally Alpha 3 (0.9.2) will have some changes to the way Application objects are created and will incorporate a few other improvements for applications. Alpha 3 will be the first public Alpha release. If all goes well, as in nothing catastrophic comes up, it will be the only Alpha release. Starting at 0.9.3 I hope to begin releasing Betas and to have clay-project.com launched by that point.
I've started changing the namespace/folder names in Clay Framework (CF) to match. Some of them are kind of strange, since the folder name should be plural, but the namespace is easier to read as singular. Such as \data\filter\html. You may think the html filter would be in a /filters folder. Clay is action-based, so the classes and functions are namespaced as actions, not sets. A lot of frameworks are using matching folders and namespaces, which I have planned to change to for a while.
Once I've finished some testing I will push the changes out to the repos. I've also started doing the changes in ClayCMS and Clay Installer. For instance Application Libaries will be in a /library folder to be uniform with the change in CF of /libraries to /library. The app library namespace is changing accordingly, from \application\*\api to \application\*\library. I am keeping the method of calling Library Static methods using static::api(), as those are API functions.
Once all of these changes are in affect, CF will be at version 0.9.1 (Alpha 2). I plan to do the first publicized Alpha release with 0.9.2 (Alpha 3).
I pushed some updates to GitHub for Clay Framework and Clay Installer. These mainly focused on PHP Strict Standards compliance. I also pushed the Autoboot package and the renamed feature for site configuration names.
I'm trying to decide on how to do the repos. I want to keep a repo of just Clay Framework. The rest are a little trickier. The plan has bee to keep them separated in their own repos. It's kind of a pain to keep track of what changes and doing the cross merges to the different repos. I'm thinking about tiering them instead. I had a long night at work, so I'm not deciding right now :)
I have Autoboot working, mostly. I still have to finish the method that creates/updates the configuration file to store domains -> configurations. I only spent about an hour on it, so considering I worked a night shift and then worked on Autoboot I think I did ok.
CF is amazing, and yes I am biased. To implement Autoboot's functionality took about 10 lines of code, 1 class extending the \clay class. I wouldn't have even had to extend \clay, if it wasn't for a static property I needed to access configuration data.
To use it you create an "installation" of the Autoboot package and name it 'default'. Then in the "installation" set up you match a domain name to an installation. That's it. The 10 lines of code does the rest. It's only accessible from the Clay Installer.
I also added a feature to rename "installations" to Clay Installer. I did that yesterday before going into work. It doesn't set up a restore point, which I may add later. The Site Restore feature isn't complete, so I didn't want to dive into that too much.
Once I put the finishing touches on Autoboot, I'll be back to working on ClayCMS. I'm hoping to have enough content apps soon to use Autoboot and launch clay-project.com.
Autoboot is a package I started on a while back, but could never think of a good way to implement it. It is a multisite boot utility, which works by taking the current domain name and determines which site configuration is being requested. This has become fairly easy to implement, now that \clay::bootstrap delegates initialization to the site configuration.
I started working on it again yesterday, but had to stop to get virtual domains working in Apache on my development server. I finally figured out what I was doing wrong and now I can make up my own domains and point them all to my Clay file system. Anyway, I'm finishing Autoboot so I can begin setting clay-project.com and other sites using the same Clay files as daviddyess.com (right now they all just show up as daviddyess.com).
I decided to work on it, because it had gone mostly forgotten so long. I didn't want to get ready to set up clay-project.com and then realize Autoboot isn't finished (making me rush it out). The idea right now is an Autoboot installation will be the 'default' site configuration and it will then hand off site initialization to the site being requested. Fairly typical for multisites, just adapted to the Clay style of doing things.
Downtime: It's a Clay Installer package that lets you take a site offline for maintenance. Doing it.
This one I've dreaded for a while. The problem with making applications loosely knitted, is when you need to make a menu. I'm still trying to decide how to do the Menu block. There are lots of potential ways, but those are based on other CMS' and none are perfect. Still trying to hammer this one out. I think I'll fall back to something like Xaraya's, which a few usability improvements (I hope). Anyway, don't be surprised if we end up with several menu blocks haha.
I've started to put the foundation for the Blocks app. It's going to be rather simple at first, just a service type and a way to create/group blocks. I have bigger plans on this front, but something simple will be easier to upgrade later on.
Objects is an app that I started a while back and it just sat for a long time. ClayCMS has a skeleton library named dataobjects, it allows you to build data structures for different types of purposes. The Objects app is a potential successor to dataobjects, if not a companion. It doesn't do a lot by itself, but can be used in a way similiar to Services. It allows you to create an object type and assign pieces of functionality called properties to that object. It can then be implemented in various ways by manipulating which properties are included in the assignment. The key to this functionality is the properties can inherit or be assigned other properties, which allows each structure to potentially be entirely different. One of the first implementations I've experimented with is a Forms app that allows you to build forms for data input. I've mentioned all of this before, in part, but it's been a while. It's similiar to DynamicData in Xaraya, but the implemenation is very different. I haven't decided on a name for it, exactly, but it's now dataobjects and I've toyed with the idea of renaming it ClayDO. I haven't decided if ClayDO and/or Objects app will be in early releases of ClayCMS or not. Unfortunately I had something a little simpler in mind with ClayCMS, so I may add it as an optional feature, instead of making it a Core requirement.
The idea for dataobjects actually began as another Application Platform I want to build using Clay Framework. While ClayCMS is intended to be a simple and straight-forward development platform, Sculpt, the other platform, would allow you to build a web site of applications without having to write any code. Applications would be created by assigning dataobjects properties and designing a template from the user interface, that's all. This is very different from what I have now. I have a lot to learn before I can build something like Sculpt, so I wouldn't be surprised to see dataobjects or ClayDO or Objects app-like functionality in ClayCMS for the time being.