[Tattoo path] DeploymentPackages and StaticResources

I’ve had a new idea developing in my Tattoo prototype for the past few days. It started as I was considering how we could make distributable packages of MODx sites, sub-sites, or just sets of related resources and components, without sacrificing the portability of the database abstraction layer. What I’ve come up with I’d like to describe as DeploymentPackages.

Basically a DeploymentPackage will be a PHP file (or set of PHP files) containing code that will persist a taxonomy (i.e. hierarchy or map) of serialized objects from the data model. These packages are exported by the simple process of generating this file, and imported by including it (much like how the current siteSettings cache file works). This would provide a way to import/export distributable packages of the CMS data across any DB platform with very little effort.

The next challenge was to define how to include external resources in this package, such as js, css, etc. But as these are simply resources that can already be included as virtual resources in the system, why not make them part of the core data definition. Then, the only thing that has to be physically placed on a server in order install MODx, is the index.php, a /system folder structure containing the core classes and installer files, and a default manager context (i.e. system/manager/index.php). The rest is packaged as a core DeploymentPackage, which takes care of installing all of the required core data objects, as well as any optional sub packages, like a default template, sample site, etc.

Finally, as I was considering all this, it dawned on me how I could include any static, physical resource in the deployment package by providing one additional flag in the Resource database, indicating if the resource was static vs. dynamic (or perhaps physical vs. virtual). In this way, we can include ANY static file resource in our site definitions, and still have it reside on the file system as a static, physical resource which can be edited/updated as usual via any IDE or FTP system (e.g. module or snippet includes, images, CSS, anything). The only caveat of a static resource would be that it could only define one content element, and that element would not be processed like other virtual CMS resources (e.g. no tags processing, TV’s attached, or even CMS security/permissions, etc.), but then all of our site resources can be managed, including revisioning and rolling back content for static or dynamic resources, in a consistent manner. And more importantly, can be imported/exported and distributed in a single, cross-platform distribution package.

Any thoughts on these ideas as I progress towards releasing the initial Tattoo prototype?

It sounds to me to be tremendously powerful, but you said some words that went "woosh!" right over my head.

I say prototype it and lets see how it works. I learn by doing by the way, so reading or talking about stuff typically doesn’t work so well for me... I have to actually get my hands on stuff before I make any calls good or bad usually when it comes to things with which I’m not familiar.

Sounds like a great idea to me. But it also sounds like one of those things that seems simple in theory but could get very dicey when the rubber meets the road. But by all means let’s give it a shot.

One question though. When you talk about serializing the objects I assume that you are talking about using the built-in PHP serializers. I don’t know a lot about serilization honestly but would there be any isues with moving serialized obects between different versions of PHP or Windows and Linux or other compatability issues at all?

Like I said I don’t know a lot about serialization and I’m not really sure that if it saves this sort of thing in a plain-text or binary format and if a binary format, how closely tied it would be to the OS and PHP version.

Very good idea Jason.

@re: serialization, I am actually going to try two different approaches, one using serialized versions of the objects and one using array representations of the objects (since all the objects in the Tattoo model include toArray() and fromArray() methods, which ever way is most efficient would be best). I don’t think there are any issues with serialization, other than the performance of these processes is less than optimal. The tradeoff is portability and simplicity -- there’s not much to serializing and unserializing objects, while generating PHP code with arrays takes a tiny bit more work, but we’ll see which one wins the contest. [NOTE: the code is extremely short and sweet for this so far, using either method]

@re: prototype: it’s coming, but I can’t just code it all in a vacuum by myself without any collaboration -- I’ve got to be able to talk about and get feedback on it -- otherwise, the prototype will be practically worthless except maybe to me I come from a development environment where team was the key focus and everything was discussed together as we coded; now I’m sitting in an office at home, by myself -- just let me talk about it, will ya? ...and if you understand, jump in, otherwise, feel free to ignore the design discussion and wait for the implementation. These are use cases and design decisions I am talking about, and where I’m from, no coding occured until the use case was finalized. And honestly, how can we maintain or address the roadmap if we can’t discuss use cases and code/architecture decisions up front?

Also, when terms I use go over your head, feel free to ask questions about them (or even better, look them up at Wikipedia... ). I’m certainly not trying to whoosh anything over your head or anyone else’s. Just comes naturally I guess. LOL.

Wooshmaster,

I mean Jason. :p

I’ll ask more questions next time. My gut says that everything mentioned in the thread is a great idea. As far as implementation of it goes, I just prefer the faster route.