Java – What’s the best way to merge two XML Strings with the same tag names

Try this. The initial reflection is certainly expensive, but if you're going to use it many many times, which I think you will, this is most certainly a better solution what what you're proposing. I don't like using reflection, but I find myself using it when I don't like the alternative to reflection. I do think that this will save your team a lot of headache, but you must pass the name of the method (in lowercase).

In other words, rather than pass "name", you would pass "fullname" because the name of the get method is "getFullName()".

Map<String, Method> methodMapping = null;

public Object getNode(String name) {
    Map<String, Method> methods = getMethodMapping(contact.getClass());
    return methods.get(name).invoke(contact);
}

public Map<String, Method> getMethodMapping(Class<?> contact) {
    if(methodMapping == null) {
        Map<String, Method> mapping = new HashMap<String, Method>();
        Method[] methods = contact.getDeclaredMethods();
        for(Method method : methods) {
            if(method.getParameterTypes().length() == 0) {
                if(method.getName().startsWith("get")) {
                    mapping.put(method.getName().substring(3).toLower(), method);
                } else if (method.getName().startsWith("is"))) {
                    mapping.put(method.getName().substring(2).toLower(), method);
                }
            }
        }
        methodMapping = mapping;
    }
    return methodMapping;
}

If you need to access data contained within members of contact, you might consider building a wrapper class for contact which has all methods to access any information required. This would also be useful for guaranteeing that the names of the access fields will always remain the same (I.e. if wrapper class has getFullName() and you call with fullname, it will always work even if contact's getFullName() has been renamed -- it would cause compilation error before it would let you do that).

public class ContactWrapper {
    private Contact contact;

    public ContactWrapper(Contact contact) {
        this.contact = contact;
    }

    public String getFullName() {
        return contact.getFullName();
    }
    ...
}

This solution has saved me several times, namely when I wanted to have a single data representation to use in jsf datatables and when that data needed to be exported into a report using jasper (which doesn't handle complicated object accessors well in my experience).

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.