MiddleKit (MK) is a component of Webware that provides for developing your application with an object model which is in turn used for other purposes.
In short, an object model is simply a listing of your classes and their attributes including details such as type, name, min, max, is-required, samples, delete rules, etc. Some would refer to this as "meta data" or "configuration" or a "class hierarchy description".
This Wiki page helps document some items that haven't made it to the main docs yet, but are still important and often appear on the mailing list.
Originally, MK was developed purely as an "object-relational mapper" or ORM, eg, software that maps objects to SQL databases. However, experience shows that the object model can be used for many other purposes including user interface.
This makes MK much more than just an ORM. Here is an excerpt from a reply I wrote:
The more I use MiddleKit the more uses I have for the object model:
generating forms
generating object browsing pages
generating detailed views
generating sample data
generating SQL table definitions
generating runtime SQL
Note that SQL now occupies less than half the list of uses for an object model.
The pay off to using the object model is that it is very easy to edit and all of the above things automagically work right after the edit (with the occasional caveat).
Another use for the object model is as a concise, precise document of what data is being tracked and what their relationships, delete rules, etc. are. The object model is much more clean to read and write than either Python or SQL. I even use them in meetings with non-technical clients.
MK will have its documentation revamped to reflect the object-model focus and eventually receive additional code from a project of mine to aid in the above tasks.
You can read the MK docs online at:
If you wish to begin using your object models in a generic fashion, read this section.
Although it certainly encourages it. In order to simulate object references and lists, as Python programmers are used to the terms, MiddleKit has some interesting schema approaches. In particular, an object reference is implemented as a 64-bit id split into 2 parts: the class id and object id. This approach allows for the full power of pointing to arbitrary objects. As a Python user you will never notice this (MK hides it from you), but it doesn't jive well with other SQL tools such as a SQL-oriented report generator.
If that is a problem for your projects, then do not use the "obj ref" type described in the docs. Instead use whatever type you are using for your SQL joins (such as "int" or "string") and implement the method yourself to fetch the object. You will still get the other MK benefits such as an object model (which makes a nice form of concise documentation), uniquing, autogeneration of UPDATEs and INSERTs, the other object model uses described above, etc.
When you change your object model, your SQL schema changes as well. If your database is already live and you can't discard the data, you have to ALTER it into shape. I used to do this by hand, but GeoffTalvola pointed me to mysqldiff which saves enormous effort. Before you use it, read the important MiddleKit note on the MySQLThirdParty page!
See MiddleKitAndWebKit.
For unknown reasons, the question comes up periodically, "Is MiddleKit still being actively developed?" The answer is "yes". I use MiddleKit in all my projects on a daily basis and still check in fixes and enhancements. MK will only get bigger and better.
I think this might come up because MK is less active than WebKit for a couple reasons. One, is that WebKit is more popular and hence has more users peering at it, asking questions, submitting patches, etc. Another is that MK is exceptionally stable with an excellent test suite. While MK has a wish list like any other project, stability and testing are already there. Frequent patches aren't required.
-- ChuckEsterbrook - 31 Dec 2001