Xml For Once And Only Once

From the XpMailingList, 2003 June 17:

For me, "ThreeStrikesAndYouAutomate" is neither necessary nor sufficient. I want to automate the moment automating would be better than doing the process manually, and not until then.

TSA pops up where you least expect it.

For example, all big programs are multilingual, and use ConditionalCompilation?.

If the conditional compilation happens in two languages, then you might find yourself with a config.h and config.bas file, maintained in parallel.

This is code duplication that violates OnceAndOnlyOnce, like any other. Write a confix.xml to store the raw configuration settings, and then write a configCpp.xslt and configBas.xslt to convert the settings, at batch build time, into their target languages.

This looks non-simple and non-easy.

But the ugliest code, the xslt files, need never be editted again. Changing the config.xml file changes everything, and it's very readable.

Further, if you add a configHtml.xslt to the mix, then each time you build you can publish that Html to a server, detailing exactly what built.

OAOO is for code. TSA is for programmers' behaviors while coding. So the above system just automated the act of documenting what went into a given build.

-- PhlIp

We have just done that exact thing.

We have three teams developing 3 different software apps:

The BTS team had a enum .h file with 50 odd enums. These enum values were sent in socket messages to the BSC. The BSC would then send CORBA messages to the NMS which could contain any of the 50 enums from the BTS team, PLUS any of the 20 or so of their own enum values that they added to the original .h file.

With the NMS written in Java we hand rolled the usual typesafe enum class that represented all of the enum values that were found in the .h file.

Which worked fine the first time. Then the BTS team added some new enums, which meant the our team had to update our enum class. Then it happened again - only this time we convinced all three teams of the benefit of using a language neutral store for the enum values and using a tool to generate each teams own language enum .h or class file.

Just like you we use an XML file to store the enum values and have 3 XSLTs that generate each teams required source. And because the build systems all run the xslts every time we build all teams are constantly up to date.

Like you said, this sounds complicated, but it isn't...in fact writing any one of the xslts took as long as writing this email did ;-)

Weirdly enough, once we'd got this XML file describing the enums, we realised we could also store additional info in it, e.g. Help resources, descriptions and so on...

-- AndrewMcDonagh?

Once you go down that path, you will never turn back.

We do all our remote interface document and code generation this way (changing the protocol used is done by XSLT files, changing the content by XML).

We soon realised that all this XML relied on schemas that may contain errors, so a pair from my team developed XML Schema Unit Test (SUT) so we could test them as part of the unit test suite.

If you use a schema, have a look at

http://sut.sourceforge.net/

-- IanCollins?

The XCB project (http://xcb.freedesktop.org/), a replacement for hoary old Xlib, also uses XML to describe the XwindowProtocol. The protocol description is in an XML file, and the primary XSLT file translates it into CeeLanguage bindings. Plans are to write additional XSLT files for

XML processing has been used to implment MixedCodeGeneration macros in VisualBasic.

This type of function has also been done using InterfaceDefinitionLanguages.

EditText of this page (last edited June 17, 2005) or FindPage with title or text search