Help me avoid a WTF
-
My employer assembles and sells complex widgets. Each widget is composed of multiple components. We have a configurator that allows users (and our sales team) to configure our widgets. This configurator is part of our home-grown CMS+CRM+ERP suite. I'm the last surviving member of the development team, the rest having run away over the years due to excessive corporate drama. (I'm only the last one because the other simply managed to leave first, and I didn't want to leave the company in a bad position.)
The WTFs in the Existing System are numerous but all very system-specific, so I'll save you all but the most entertaining. The main interface to make the configurator application work is hand-modified XML. Logically, this XML is never actually stored, but parsed on submission and regenerated on demand. The user gets a giant textbox in which to edit this XML. This was the bright idea of one of the company founders, and was not a horrible solution back when the Existing System was devised in the dark days of unreliable cross-browser DHTML.
For better or worse, the XML is the only way to make configurators. There are a few things that the XML does well, such as making it easy to copy/paste component lists between widgets, which tends to be a very common operation. Indeed, copy/paste of XML has become the preferred method of staging changes. The Existing System has no staging mechanism, you see. We have a development sandbox, in which the product administration people can play around and make their configurators, and the live system, in which they can finally make it all work to the outside world.
Being the last one left does have its advantages. I was able to convince the new management to finally
rewriteradically refactor parts of the Existing System, starting with the website tools, including the configurator. We're in the requirements gathering phase now, and the topic of staging has become a huge problem. This is the WTF that I'm seeking advice on avoiding. (Normally this would be something that the team would devise a solution for, but there won't be a team until we can find people to actually join the team.) The New System does away with the ugly hack that is the XML, in favor of a configurator configurator. Because the XML is going away, so is the old way of doing ugly half-assed staging.In the land of CMSes, staging new content is a no-brainer. Staging new versions of existing content is a little tricker, but it's still a well-solved problem. However, how exactly do I go about creating a staging system for a configurator? The problem is that each configurator has its own set of properties and behavior, and can incorporate hundreds of components, along with their properties and behavior. The changes that the product administrators might want to make might not be to the configurator itself, but to the components within it. Or both. Worse, sometimes they will wish to push out changes to components that are shared between configurators, changing some while leaving others alone.
The current idea on staging is to use a variety of versioning. Any content or component or widget will have a currently live version, a test version, a staged version, and sandbox versions. Test and Live versions are immutable, untouchable. Authorized users can create new versions of each variety of content, in the proper sandbox environment. Sandboxed things can be prompted to staging. Staged things can be prompted to testing. Tested things are promoted to live. This will give us a clear process and procedure, as well as an audit trail and other things lacking in the Existing System.
That's all a simple process for static content, but configurators are much more complex. How should/could/would I adapt this to work with the concept of a configurator and the components it contains? My current thoughts are that each reference to a component within the configurator can also include a version reference. By default, the reference would be "use live version." In the test environment, it would be "use test-approved version" whether that's live or test, staging would use "use staging-approved version," whether it's staging or testing or live. A problem would be synchronizing the pushing of content live. If I update a configurator under the assumption that a component it uses will also be updated, I don't want to push the configurator without also pushing the component. To solve this, I was thinking "use any suitable approved version greater than X" as a possible version test. I could then integrate that requirement into the "make this live" functionality, having it automatically promote the component version as needed.
What problems would you foresee with this setup? Keep in mind that the sandbox->staging->testing->live process has already been requested by the users. They don't care about the underlying mechanism, so much as they have proper places to prepare content, components, and widgets.
How would you go about solving the staging issue with configurators and their components?
tl;dr: Staging complex multi-layered content is hard, let's go shopping!
-
Also, wow, the edit button disappeared quickly. This might not be the best forum. Moderators are invited to find a more suitable location, but this is neither funny stuff, nor general discussion, soooo...
-
I didn't understand everything you wrote, but it reminded me an aweful lot of Don Batory's work with layers, and the concept of products that are a compilation of features that can modify and interact with other features in a structured manner. You might be interested in this paper. It requires an ACM membership, but you can probably find it on the internet if you really want.
-
@EX PLO SHUN said:
Also, wow, the edit button disappeared quickly. This might not be the best forum. Moderators are invited to find a more suitable location, but this is neither funny stuff, nor general discussion, soooo...
I think that's just the way the sofware is configured; you have a limited amount of time to make edits.
You usually just need to indicate your edits in another post. Or, just PM me and let me know what you'd like to fix if it's fairly simple and important, and I'd be happy to do it for you.
-
Seems to me that the easiest way to configure the configurators, is to introspect the components for their properties and behavior and description thereof. To get a little fancier, you could then create a textual DSL which can use the introspected metadata to describe an actual widget configuration with. That way the parser for your DSL is going to be the most intricate thing and there's no need for difficult Web pages.
Mixin layers: an object-oriented implementation technique for refinements and collaboration-based designs: ACM Transactions on Software Engineering and Methodology: Vol 11, No 2
