The actual foundation is created. People are split into the main groups, and all the main groups are linked to campuses. Subjects and Courses are up and seeded. There is even one very major upgrade that came out of no where but I really liked how it turned out. But let's go over the updates first.
Create the Student Record
Done! The student record is now created and assigned via the seeder to all the families so that every kid is a student of some sort. Each student record is linked to a campus, a level (grade), a year and a person. There is also now a management system that can set up student records manually through the person editor. It my original incarnation of this system, I was very adamant about letting people edit the records so directly. This led to a lot of issues when the student record was not created correctly. Many a times did I need to go into the DB raw and change some record info. I decided this time to let the user have the ability to manage the nitty-gritty of the student record.
Create the Interaction Between Employees and Campuses
Done! I was heavily debating whether it should be a special relationship or any person could be linked to any campuses for any reason. I decided against this, choosing instead to only have the many-to-many campus to person relationship for employees only. I also decided against the idea of a primary campus. I still see the need for that in a lot of places, but I would like to get away from the idea of a “working” campus that is changed through the settings, and concentrate instead of subject matter.
This mean that I do plan on having a current year, and current semester, but not a current campus.
Create the Interaction Between Parents and Campuses
Done! This was rather a complicated relationship, as I could not define it as a straight relationship, due to how many tables it has to cross. As such, parent campuses is a pretty expensive function that should probably be cached somehow. However, since I do have this information I figure I might use it, so I filled in a lot of the numbers, specially int eh directory and campuses pages.
Create Subject Matter
Done! Called “Subjects”, which is the large container that will hold all the courses for that subject. Each subject belongs to a single campus, so all the subject data is constrained by the campus and the grades it teaches. I did decide to add some stuff that will be used in the future, such as colors and order, which will be mainly be used in the transcript piece. I also added required terms, which will be used in the student planning piece.
Create the Courses
Done! I also added some extra options in them that I know I will use later. Mainly in the transcript. There's not many surprises in these, as they're the basic blocks that things get attached to. I will say that building these reminded me of my original LMS code that I built. In fact, most of the look for these last two features came from my original Learning Tool.
And something more…
So one of the things that's been bugging me is that amount of CRUD tables that I was using in the Person record. It seemed like a lot of SQL calls for not a lot of payoff. Just a few very rigid fields that added queries and they were very static. Sure, you could change the options, but you couldn't add more fields, or mark them as unnecessary. For example, title, which is pretty useless for anything other than parents, and mainly in the Fundraising section.
So I really wanted to add some extra fields, but only to the staff record. My first thought was to do what I used to do in my original and add an extra table with staff-only data. In my original LMS, I had an extra table for each “Persona”, which was staff, faculty, students and parents back then. Every time I would load a staff member, I would load the Person record and the attached faculty record. This was pretty crappy, as things like the faculty record was pretty much empty, which the student record had a lot more. It was annoying, but there weren't many options, as JSON was just coming into the scene. I decided to do things differently. Instead I extended the Role model into a SchoolRole that has a fields variable that uses MySQL's new JSON data field. Using this field I could store what the data structure would be for any data that I would like to attach to the Role model. From there, I added a pivot field to the Role-Person connector that would then store the values of the fields. The result is that I can define fields of extra data that I would like to capture on a per-role basis and fill it on the person's record. This data will be accessible through a JSON object, so it should be pretty query able. I'll be using that when I need to make rosters and lists.
What making this system has led me to decide is two things: I would like to decouple the people CRUD tables like title, ethnicity, gender, etc, and move them to their own role fields. I would like to define a few of them and then seed them. Note that this does not get rid of the CRUD tables, as I will still be suing them for top-level lookup tables, like reasons for withdrawal, or grades and that sort of thing. This way it should make less queries when retrieving Person objects.
The second thing that I realized is that the field viewing permissions are utter crap that need to be fixed. This one is going to be a bit harder I think. I have a few ideas, but nothing concrete. I know that this new system will have to include all the fields that I can define in the JSON fields, so it needs to be extendible and as easy as my current system.
With that aside, what should be next for my release? Well everything that I've been building has been towards the combination of all three pillars for the end result which is the class session. So I think that should be built next. Pretty much everything else can be built in as features, but the foundation is the classes. Of course, it will also mean finishing up the rest of the foundation, mainly classes and schedule, and then tying it to the class enrollment record. This is what the diagram would roughly look like:
So for this next dev cycle I will be far more ambitious in my LMS and plan to complete the above diagram. Now in every previous cycle I would be working on my DiCMS and Blogger first, then work on the LMS. This time around I'm changing the cycle, since it's Xmas, I'll have a break and I would like to concentrate on this rather than my CMS. Now I don't want to feel as if I'm leaving DiCMS behind, so instead of coding I will be writing a blog post about my plugin design.
This blog post was always going to be part of the documentation, and it feels right that it will be published in the medium it is made for. This blog post will be pretty long and will have lots of code, so I plan that to be my DiCMS/Blogger update for this development cycle. I will continue with my regular cycle after this one, of course.
So, with all that in mind, here is what I hope to archive for my next post:
Build Classes that will run for the year
Build Class Sessions that will run for the semester
Allow assigning teachers to the class sessions
Build a schedule system that will have periods and blocks
Allow the class to have multiple rooms to meet based on the schedule
Build the class enrollment to enroll students into classes.
Once this is built, the foundation will be complete and I will start laying out different features that I will like to build I will update when it's done.