21 Sep 12
I've been a little quiet on here lately, sorry about that. I have worked on Clay some, but my family and I are getting ready to move after the new year, so it's been kind of hard to find time. I'll post where we are moving after I get my orders from the USAF, just in case something doesn't work out.
I've been working on the Roles and Privileges admin GUIs, some of the updates have been pushed to the repo. I'm worrying a little about how the privilege system is going to affect performance, the Roles hierarchy system may be a bit complex. I'm going with it for now, as I don't really have a better solution at the moment.
I've made some enhancements here and there, but nothing really major. The code base is getting a little heavier than I like, so I will likely be splitting up some of the code that isn't always needed. By code base, I mean the amount of code needed for a page to load. I'm trying to figure out a good way to implement the submodules to move some of the code out of the main module classes.
As I wrote in my last blog, I'm looking at some ideas for applications to work on. I'm adding an Editors service, so I have have more than just TinyMCE. I like TinyMCE, but I want to go a different route, something more HTML5 based. The Editors service will allow you to pick which editor you want, so TinyMCE will very likely be available. I've been trying to workout how to do the Blocks and Hooks, which will open the door to a lot of applications I've been putting on hold. One thing I've been bouncing back and forth on is an application generator. The Nodes in Drupal have been its bread and butter, so a way to create pseudo applications is going to be more of a requirement than an option, development-wise. Xaraya's Articles and XarPages modules also strengthen the case for it.
One of my ideas for an application generator is by using it as a component of the Apps application. It would basically allow you to piece together an application from a GUI and then generate some generic templates to go along with it. The generated application would then be listed as an installed app, but with a different status code to show it isn't a native application. The app could then be exported and imported somewhere else or used to build a native application. I have some experimental code that could be applied to implement that, such as the Object app.
I've been looking for ways to improve the Dashboard. I want to keep it simple, but as usable as possible. I'm thinking the Blocks will be a big helper there. I want it as dynamic as possible, but that also takes away from performance as well. Last, but not least, I will likely be moving toward a short url system fairly soon. I'm not expecting to use a strictly defined router or mapping system, as I had previously looked into. I may use something like that as a fallback system, but I'd prefer to allow each application to define it's URL schema. Too many things to think about at once :)
11 Sep 12
I've been working on bug fixes to fix anything left over from the transition to modules. I've fixed a few and there don't appear to be too many left. I will probably push Clay onto the server sometime this week and make sure there aren't issues with the code there. Once that is verified I'll upgrade this site to the latest version of Clay. I'm excited to see what the performance difference will be. This site runs a little faster than my local server and performance has improved quite a bit on local. There are still optimizations to do, but I've tried to work in as many lately as I could find time for.
I'm probably going to be splitting my development time a little more that I have been lately. I have a few application ideas I'd like to push out, but there are still project goals to finish as well. I want to do some social apps and maybe something that works with the Github API.
Once the Privileges are finished on the administrative side I'll enable user registration here, followed shortly by adding comments functionality to blog posts. The comments system may be temporary, as I plan to expand that quite a bit once the hooks system is finished. I'll try to put in some temporary stints that will allow me to simply open it up to hooks, but I may be able to just make it simple enough to convert, it later on, to a newer system.
10 Sep 12
Have a Git repo that is getting rather large, from multiple deleted branches and merges? Use "git gc".
git gc is the garbage collection command and frees up space by removing unneeded clutter in the repo. It reduced my local Clay repo from 19mb to 12mb.
09 Sep 12
Over the past month and 6 days there have been 127 commits to the Privs branch, all of which have now been merged into the Master branch. There had only been 77 commits to the Clay repo since it was created on May 22. Clay now features a module system, featuring several modules that can be used within any application platform built on Clay Framework. ClayCMS has been merged into Clay, simplifying the naming scheme. A new privilege system, which was the primary reason for the creation of the Privs branch, is now in place and awaiting an administration interface.
The past month has by far been the most code I've written in a long while. The merge brings changes to over 850 files, most of which have been cleaned up and commented better. There are still a few glitches, from the Privileges system change and the move of Application APIs to Module APIs. Clay also is transitioning toward full compatibility with Doxygen, a documentation generator.
Prepping for Merge
I've been doing some premerge audits to make sure I haven't missed anything in the privs branch that will require a lot of rework from the master branch. I try not to make big changes to the code base within the master branch, especially if it is something that makes it unstable for an extended period of time. I've pushed a lot of code to the privs branch since my last post. I've totally deprecated the ClayCMS library, all of it has been replaced by modules or built into the Clay library. I've cleaned up a lot of code too, but there are still some applications that are not commented or cleaned up. I removed the Security application, as that was mostly used as a setup application and modules have replaced it. The admin backend for privileges management hasn't been implemented, but that can easily be added into the master branch. It is the continuing end to the current goal at least.
I need to do some testing to make sure the new module installer works correctly and I've correctly implemented the setups for those. Modules have replaced a lot of functionality of both libraries and applications, with applications becoming dependents. The goal is to build up modules, so applications are lighter and implemented using existing code from modules. The modules also allow developers to create application platforms ontop of Clay and use what they need from existing modules.
I'm weighing my choices for the next step, but I will likely work on Blocks and User Profiles next. There's plenty to do, but I think those are a logical next step. There are a lot of core features to add, including Data Objects - used to create pages and applications more rapidly, including built in CRUD; Hooks - a generic service type that can be used to extend application functionality; Logger - used to audit for error messages, user activity, optimizations; and Debugger - visual data display, associating output data to templates, to name a few. There are lots of applications to be created and finished as well. The next step will likely be Blocks, which will be either a service type or a specialized application controller.
27 Aug 12
By this time next week the privs branch should be merged back into the master branch in the Clay repo. This branch has brought the most radical changes to Clay in quite some time. It features a new module system, with many former ClayCMS libraries now acting as modules. The modules are the last part of the work left to do, other than the usual pre-merge audits. Modules will support dependencies and work on demand. If an application uses a module, it will be set up automatically, including configuration files and database tables. The privileges system, which was the purpose of the branch to begin with, allows applications complete control over the privileges they provide and what they allow.
Finally, a lot of effort has gone into improving code readability and commenting every file. By the time this branch is merged into the master branch, every file in Clay will have been touched. I'm working toward defining coding standards and recommendations, while implementing those standards into the code base. This branch has obviously been more than just about privileges, but most of the changes were solutions for needs brought to light by the new privileges sytem.
23 Aug 12
Over the course of developing the Clay Framework and then building the platforms on top of it I have now, I've always developed with other developers' needs in mind. I've tried to make the Clay Framework as flexible as possible. None of that is going to change, but there is a big change coming.
The last couple of day I've torn Clay apart and started putting it back together. It's not a rewrite, it's simply a complete restructuring. Namespaces will be more easily identified. Application platforms will be able to share applications. Modules will be self-aware, resolve their own dependencies, and be reusable across all of Clay.
I've basically merged everything. Applications can use anything, regardless of the platform, and will be usable on any platform built with Clay.
I'll blog again with more details, why I've done this, and what it means.
16 Aug 12
Sometimes I get stuck on some code and have to just take a break from it. When that happens I normally just try to brain storm new ideas and hope my creativity kicks in. Sometimes it works and I finish the code, sometimes I get distracted with the brain storm and don't go back to the code until later.
As you can probably tell from my blog, my thought process is not exactly linear. I'm always thinking about new things to do and normally that leads to other things to do. I hardly ever finish a project, which proves Clay is just meant to be or I would have stopped working on it by now! Here's a (n incomplete) map of my thought process tonight:
Writing code for the Roles module -> need a way to share a ClayDB link without extending an abstract class in every new class -> I can use a trait -> traits don't share static variables, so the link wouldn't really be "shared", just the code -> Once the Roles, User, and Privileges modules are finished I need to enable user registration on this site -> I need a comments application for my blog -> it should be a service or a hook or both? -> maybe I should add facebook comments -> I wonder if you could make facebook comments into a forum -> I think twitter would be more logical -> I could use twitter for all communication -> but twitter has that darn work limit -> I need to set up the Clay Project site -> I could integrate it with GitHub -> I could use the twitter forum idea for that too -> but it has that darn work limit -> I wonder if anyone in the profession-php developers group would be interested in a twitter forum -> *start writing email to group* -> *discard email* -> I need to make my own twitter -> I'll just use a trait -> I'll leave the abstract in case someone wants to use that too -> Maybe I should just drop libraries altogether and make all of them a module -> but I did go the library route to make the code extendable -> modules are going to be harder to extend, so I should just keep the libraries too -> I need to move a lot of code out of applications and into modules -> some other day -> this heart burn sucks -> traits aren't nearly as useful as I imagined -> abstracts are better, but you can only have one base class in PHP -> traits are better unless you need static variables -> how do traits provide multiple inheritance if static variables don't stay static -> I hate PHP -> Ah, finally finished with the Roles module -> shit, I have to write the setup class for the Roles module -> I'll do that later -> this heart burn sucks -> I need a cigarette
14 Aug 12
I've been implementing the new Module system in Clay and using it to test the documentation generator Doxygen on the source code. I'm changing some of the coding style in Clay. They say a develoeper's political and social values influence how they write code, well, I'm a conservative. I've always tried to keep my code condensed and as small as possible. I'm trying to move away from that and make the code a little "prettier", while also making it easier to read, and documenting it better.
The Module system allows a module developer complete freedom over his/her module. Each module is in reality a sublibrary to a library named Module, so a module's can be access using Clay's \Library() function or by using the Module library. This also allows developers using the modules use them in ways that fit their coding styles. They can be accessed directly or using methods within the Module object (as well as staticly).
The purpose behind the modules is to provide a layer between libraries and applications. A secondary benefit to the separation is the ability for application platforms to share modules. Modules have their own setup classes and a Manager that resolves module dependencies. The manager can determine if a module is installed, what version is installed or available, and any dependencies it may have or another module has on it. When an application is installed, it can invoke the module Manager and tell the manager it needs or no longer needs a module. The manager then sets up a database or whatever is specified in the module's setup class, including a dependence on another module.
Currently I am working on the "privs" branch within the Clay repository. The purpose of the branch is to mature Clay's privilege system, which led me to implement Modules. The first modules that will be included will be User and Security based, but I plan to move much of the ClayCMS library to modules.
I have been regularly regenerating the documentation with Doxygen to track any problems with changes I'm making and to learn what works best for me. I plan to put the Doxygen generated docs up on the web, likely a placeholder on clay-project.com or on a GitHub page, once the privs branch is merged back into master.
12 Aug 12
"Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#, and to some extent D."
I've struggled to find time to write documentation, especially when I'd much prefer to write code instead. Lately I've been trying to get better at writing documentation inside the code. I decided if I used something that would generate documentation from the code, I could at least provide some type of documentation source. It's a start at least.
Doxygen takes comments placed in source code and uses it to produce a formatted reference documentation. I've been testing it out on my development code and it works really well. I have found, of course, that some of the my comments aren't up to Doxygen's standards, so I will have to fix quite a bit of my in-code documentation. One of the plus sides to Doxygen (and I'm not saying other Doc generators don't do this) is it supports for Markdown documents as well. That is a huge plus, actually, because all of the docs I have written so far are in Markdown format. GitHub also uses Markdown, so it works out quite well.
I am currently in the process of performing a very large upgrade to some of the foundational structures within Clay. Many of the features I had planned to hold off for Clay Framework 2.0 are making their way into the current code base. During this process I've gone from chicken-scratch code, I once used, to better formatted code and standardization of a lot of the ways I write code. Nearly all of the source files have been getting formatting changes, so this is a good time to document as much as possible within the code.
I'm getting ready to fill the void of not having a web site dedicated to the Clay Project, as you may have guessed from my logo annoucement earlier. I'm going to start it out simple and grow it as I can. My main concern is content (is king), so I want to have as much documentation as possible. Doxygen will help me fill that void and save some time in the process.