API Responses – Why Return XML/JSON for API Requests Instead of Directly Processing and Returning Modified Web Page?

First off, I would agree that most of the solutions that are already available look very complex and tied to concrete implementations. Although you are essentially going to be re-inventing the wheel, I don't think it is an overly difficult wheel to re-invent and I think that the benefits you will gain over time from having a nice, clean, simple solution will definitely justify the up-front investment.

My approach would be as follows:

• Themes should be able to produce their own metadata files. I was going to suggest that JSON would be just as good as XML for these files, but on reflection I think XML would be the better option. Either way, you wouldn't be editing them manually, so what matters is convenience for the theme programmer.

• I would write a separate validator to validate both theme metadata files and the config that the UI generator creates.

• I would then identify the different kinds of controls you are going to need and build those into the specifications of the theme metadata file. This is where some flexible thinking comes into play. I would have options like "boolean", which will get rendered as a checkbox but for lists I would provide "radio" and "dropdown" options, because sometimes a set of radio buttons is more appropriate than a drop down list and vice versa. I would also provide a "regex" option so that the UI can carry out some basic validation where necessary. Things like page number formatting I would implement by including a list of tokens with a field description, which the UI displays to the user so that the user knows they can use those tokens in the field. For example, the page format field might be a string field, max 30 characters and provides the [page_no] and [total_pages] tokens to be included in the config. So the theme metadata file would be fairly flexible, with elements containing optional parameters, validation info, option lists, etc.

• The resulting theme config files would use the same format (eg. XML) and, as mentioned, should be able to be validated by a stand-alone tool. (I realise that's an implementation detail, but it would be the first place I would start, as I would be running this tool constantly during development as both it and the theme metadata format evolved).

Rendering the UI based on this kind of file wouldn't be all that hard on any platform, assuming a single, vertically formatted scrollable page. I think the key to making this work is being creative around the definition of the theme metadata files and not boxing one's thinking into one paradigm or another.

If you really want something that works well for you, then I suggest you get used to the idea of "unnecessarily complex"... that's the nature of dealing with Microsoft Office file formats.

I (sort of) like your idea of "blocks"... I would make sub-classed block objects, like Table, with Columns and Rows independent of the notion of cells. Then use your block engine to convert these to XSLS files.

I've used the OpenXML SDK successfully in the past, but don't try to read the documentation and start from scratch. Instead, create an exact copy in Excel of what you want, save it, and inspect it using the provided Document Reflector tool. It will give you the C# code you need to create the document, which you can then learn from and modify.