Sculpt is a name that I've used for a few things so far, but it's never stuck. Maybe this time it will.
The concept is a little different from the standard Content Management System, such as ClayCMS. It's one that I've tossed around in my head for a years now, mainly because it's very complex on the code side and very simple on the user side. Let's just roll into it, shall we?
Most CMSs have a structure designed to be built upon, such as modules, applications, plugins, hooks, etc, and they used by developers from the bottom up. You have core functionality and build upon that functionality to create new functionality. The idea behind Sculpt is to have a system that builds upon itself as the developer builds in parallel. It requires a dynamic system of models, views, and controllers to allow a developer to create functionality based on events, instead of writing code.
For instance, if the developer wanted to create a blog, s/he would (from a user interface) describe what the blog needed to work, how it would look, and what it would be called. Sculpt would then use that information to build the blog. Then if the developer wanted to create something else, say a photo gallery, Sculpt would build it, and then offer cross functionality between the blog and photo gallery. So now, you can post images in a blog post, which adds an image to your gallery. Or, you could add an image to the gallery and write a blog about it. The concept is building vertically and horizontally at once, whereas the conventional system builds vertically or horizontally, but not both.
It's been really hard not to branch off into CF 2.0 territory. I see a lot of places the new PHP 5.4 features will be useful and it's driving me crazy not to jump into it yet :) Alas, I know I need to keep CF 1.0 as PHP 5.3+, so that means I have to keep pushing with what I have for now.
I've been doing to long-term maintenance to Clay Framework. I'm trying to stabilize it to a point that will be sustainable for the near future. There won't be a lot of big changes from here out for CF 1.x, mostly just additions and bug fixes. The recent namespace milestone included some structure changes that I'm now trying to catch up to in ClayCMS. I don't want to have to do that again until there is a new major revision closer to CF 2.0. CF 0.9.1 is essentially on GitHub now, I just havent finished the code review so I can tag it.
I'm beginning to shift back toward documentation and reviewing the codebase for comments. I want to have both the documentation and Clay-Project.com aligned so I can do a release as soon as the site is up. That means writing docs and writing new apps to use of the site. I have some exciting ideas for project management apps.
I haven't upgraded the site yet, so I missed my scheduled bi-weekly update. I was hoping to have the Blocks app finished in time, but my real life work schedule has cut into my playtime quite a bit.
I'll probably get around to doing the upgrade this week, with or without the Blocks. Most of the changes are on the admin side, so it's not like I have anything special to show off right now anyway.
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.