Worked on the navigation for Septuro Builder using the navigation plug-in I created a while back and it worked beautifully. The Navigation plug-in is object oriented and is created in the skin module. The navigation plug-in’s xsl in correlation with the skins xsl automatically created the navigation buttons in the location and in the order that the skin module asked for. I am very happy with the navigation plug-in.
In the Septuro Builder I created a folder called mysql. This folder holds the exports of the creation of the database and the export of each table associated with and object in the same name spaces as the objects themselves. I was thinking that each time there is a change to a database or a database table to do a export, then copy that export to the mysql folder for the application. This way subversion itself will be the version control for the database. I talked to Steve Phillips about this and he thinks that each change to the database be appended to the end of a database version control file. The main thing we need it to know is the state of the database at any version of an application in the past.
Today I started work on the modules for Septuro Builder. The objects have been created and are pretty close to being done. I have separated Septuro Builder into two name spaces of appbuilder and mocxsbuilder. The application builder will be used to create new applications to run on the framework Septuro. The mocxs builder will be used to create the mocxs(module, object, css, xsl, and scripts) for the application that was just created. I really am looking forward to getting the Septuro Builder done, so I will be working on it during my lunch hours and at home after work when I can.
I spent some time this weekend working on the Septuro Builder application. I put a lot of work into the objects and the mysql database. Cant wait to get this working with the form plugin that Steve Phillips is working on.
So, anyone who saw this site prior to today would notice something – that theme is awful. Well, screw you, I was in a hurry. I chose the old Wordpress default theme over the new one for one reason – the new one didn’t list the author name. Now, I know what you’re thinking, we created Septuro – we know code, I could’ve edited it. Yeah, I could’ve edited the new default theme to show authors, but I was just trying to get this set up on a stable host, since SourceForge’s hosting is pretty crappy. Well, today I updated to the iNove theme, which looks clean enough and shows the author names of each post.
One of these days, I’ll get the theme looking even better, but for now, this theme is acceptable and does what we need it to do. At some point, we’ll have this site running on Septuro, but until that time, this Wordpress blog is good enough for what we are using this site for – to just post on where the project is at.
Speaking of that, the project is still moving smoothly, and we’ve got our development machines working with DOMi and Septuro in such a way that we keep fixing DOMi bugs while doing Septuro work – so we’re now advancing both projects smoothly. The same thing will happen once we get Yeakum started, as it is just an extension of Septuro into a full blown CMS, but I can’t talk about that project too much… yet. Once it gets rolling, you’ll be hearing about it.
I am an extremely rabid fan of open source software, and Phil and I plan to release Septuro as an open source project. However, one hurdle that we are now encountering is not fully knowing how to do the open source copyright to make it complete and enforceable. This is the first open source project that either of us have worked to this extent. We did DOMi last year, but it was a standalone file that doesn’t have anywhere near the complexity that Septuro has.
We originally planned to use the Creative Commons 3.0 BY-SA license, but after a bit of research, I find out that their license is not ideal for software, and is more intended for works of art. I looked a little bit further, and now we are looking at using the GNU GPL license, and figuring out what we need to do to make it apply to Septuro. I have gone ahead and added a notice to each of the core source code files (a lot of the extended objects are pretty minimal and unimportant, so I don’t see the need to put the notice on everything).
If anyone out there could give us some pointers, I would be very appreciative. We want this software to be freely available to everyone. Part of that will be to make sure nobody else can come along and clamp it down, should we not set up our rights properly. This weekend, I’ll be doing some research into open source copyright law, and I’ll hopefully have this sorted out soon, so we can protect Septuro the way we want it to be protected – by protecting it’s free nature and make sure nobody can lock it down.
I am working on an application that will be a part of Septuro called “Septuro builder”. Septuro builder will have two modules called appBuilder and mocxsBuilder. The appBuilder module will work with the new form plugin to dynamically create a form that will ask all the questions needed to build the basics of an Septuro application. Once the form is filled out and submitted, an application folder with all that is needed for the basic start of an application will be created in the applications folder in Septuro. Once an application is created you will be able to use the mocxsBuilder to create a mocxs(module, object, css, xsl, and script) that will all works together and have the same name. Since I am a Disc Golfer I will use examples that have to do with Disc Golf. Lets say you want to build a website for Las Vegas Disc Golf. The application would be called lvdg(Las Vegas Disc Golf). Just run Septuro’s Builders appBuilder form, answer all the questions, submit, and a lvdg application will be created for you. Once you have the application built you will run the mocxsBuilder to create an object like “Golfer”. You will answer all the question(question like: What will the properties of this object be?) in the mocxsBuilder form and a golfer mocxs will be created in the lvdg application. At this point you should be able to set your VirtualHost for lvdg and have the bascs for a dynamic website users can enter their information in as a Disc Golfer in las vegas. The golfer mocxs will be able to use the form plugin to dynamically create a form for itself. Sweeeeeeeeeet.
Phillip Brown
Developer
Earlier today, I killed the folder-restructure branch, merged back into trunk, and called it a day. The ‘element’ folder no longer exists, anywhere, and the plugin folder has been readjusted so each plugin is its own folder. When we first did the layout of Septuro, we created an element folder to house all of the PHP, broken down into sub sections like ‘objects’ and ‘modules’. After a few months… we realized we ONLY use objects and modules. So, we decided to do some retooling, eliminate the elements folder, and move objects and modules to the top level.
Now that I am done with this, I will be working on the form plugin. I’m doing this on the trunk, since the current application/plugin set up makes it easy to build new things without interfering with others. The folder restructuring would’ve messed with others quite a bit, so I had to do that on a branch.
This form plugin is going to be really, really cool. I can’t rant and rave about it enough. It’s a great idea that will smooth out form creation, validation and processing into a few simple steps, even supporting multi page forms that require session or cookie data to be stored.
Speaking of sessions, while making this form, I’ll be working on a new session object, alongside the database object and xml object, to store object data in session variables as its system of persistent storage. Like the other object-storage layers, it will handle everything without interfering with the first or third tiers.
I’ll post more on it as it comes along, since this will be a hefty project.
Recently, Phil and I were looking at a new system that he is developing for Septuro – where the autoload cascades across the application, parent applications, plugins and finally onto the system core. This is a really cool system that lets you override existing objects with new objects, or even extend existing modules. It is taking the concept of object oriented programming in a new direction, and applying those concepts to entire file structures.
While working on this, we noticed that the plugin directory wasn’t structured in the ideal way, and while looking at the folder structure, we also finally decided to do what Phil has long suggested – kill the element folder and relocate its contents into an object and module folder. I created a new branch today – folder-restructure – where I will be doing all of this tweaking. This really is a pain, but better to do it now than deal with the pain of it later.
I should have this branch finished and reintegrated into the trunk before the end of the day, and then I can get back onto working on the long awaited form plugin. That plugin is going to be really, really cool. I’m excited to get down into working on it. It takes my previous work on the dataTemplates and abstract objects and puts them in a new light. An object can be converted into a form really easily. Just tell the form what object it is working with, the object already contains information on how to be displayed in a form, plus it’s validation rules, and then give it a callback function to execute on completion – it’ll be sweet.
Last night, I was working on a branch, building the new form module tools. These tools are going to be really powerful and let you whip forms together out of existing objects really easily. They use the object properties as defined in the third tier of each object, and do all of the PHP / jQuery validation setup for you, and since it all runs through a single location, the HTML structure of all forms remains consistent, making CSS framework designs easier.
However, while working on it, I realized that we have a long way to go in terms of error reporting and exception handling. I built a form application specifically to handle this, and could not get it running through the proper skin module. These skin modules are just like regular modules, but contain rules for determining the outermost skin, and it is code that Phil added in over the past week. I was getting few helpful error messages, and I was never quite able to get a working application.
We’ve got some work to do with those error messages so that developers working on Septuro have a better understanding of what went wrong. I think the first step is to adjust the magic __call method built into DOMi, which is at the core of Septuro. It was built in to silently feed function calls over to DOMDocument, DOMXpath and XSLTProcessor, but if the function doesn’t exist, the error message that is provided is pretty minimal and easily silenced by other code.
