Another version of the Gestinanna framework is on its way -- still working out some ripples. Exciting though.
I went to a newly installed test system to install the framework and found several assumptions that caused it to fail. It had worked just fine on my development system because it and that system had grown up together. Anyone else will see errors and missing parts if they try to install it. Oh, well. It's only the initial release of a fairly large, complex system. Not a good first impression, but hopefully it can be fixed with a second release.
Well, what started as an effort to just fix those problems and get another release out has snowballed into a series of refactorings that are making things a lot better.
There's now a packaging system. The shell tool can create and open packages (just compressed tarballs), list the contents, edit the contents of a file, manage the configuration file, manifest, and readme, and write them to disk. The package manager can find them. They can almost be installed.
The installation of a package led me to wonder where the information was that told me where to install them to. I wasn't trying to force installation on a per-site basis, especially when all the sites in a schema share the tables in a schema, which is where the files are installed to from the package. The repository for views, controllers, xslt, etc., is in the RDBMS schema and not necessarily tied to a particular site. Yet all the configuration information that tied a data type (view, xsm, xslt, etc.) to a table (View, XSM, XSLT, etc. and their associated auxiliary tables) was tied to a site.
So I saw the need for a global configuration. But if I try to create a site 0 using Alzabo, it ignores the primary key (site = 0) and uses the next sequence (since it is auto-incrementing the primary key). What to do....
Now, I have a site configuration package, Gestinanna::SiteConfiguration, whose constructor can take a parent site as an argument. This parent site doesn't have to be a global configuration. It just supplies information that can be overridden or augmented by the child site. The key is that the parent site is just a Gestinanna::SiteConfiguration object.
This simple design decision led to me being able to make arbitrarily long chains of single-inheriting site configurations :) Something I had been wanting to do for a long time, but hadn't quite figured out. It wasn't something that was important to me since we didn't really need it that much, but I knew someone else might want it. Now we have it, and it may make life a *lot* easier for anyone using this framework to manage multiply-branded applications.
Now, all the tag paths, data providers, content providers, etc., can be configured in one top-level configuration for a site that is never exposed. All the exposed sites can then inherit from it and just change the theme - resulting in the ability to manage one site, but have it show up on multiple URLs with different brandings.
The ripples? Well, the site configuration is now managed by a class instead of being a hash that the rest of the system could freely inspect. Data providers (for example, Gestinanna::POF::*) now need to be able to get info from the DOM during configuration (done during server startup). Content providers (Gestinanna::ContentProvider::*) likewise. URL mappings will need to be inheritable instead of looking at current site and site 0 (the marker for a global mapping). We now have a site path to search in addition to the tag path. The factory is created and managed by the site configuration. Etc., etc., ....
I was hoping to have a new set of packages out this week, but it looks like I'll need to hold off until next week. All because I wanted to fix some errors and get away from telling people to put a file in a particular location after installation :/
I recently did something similar, take a look at this if you're interested...
