In the XtoH application, the ElementLogic class from which all the
element classes are subclassed has an atStart(), an atEnd(), and
a doText(). In a lot of cases, the atStart/atEnd amounted to "emit the
following string, interpolating the following attribute values". So
yes, a lot of parallelism, but this seemed a fair price to pay for
the independence and modularity.
>2. There is usually a large degree of dependence between the
>elements and the driving application. Often the elements need
>to access the driving application directly and there is no obvious
>and efficient way provide this interface.
Not always true. I don't do C++, but in Java, after the controller
cooks up the per-element object, he calls its method
registerController(this) - the per-element classes all have
a mController member, thus they can callback to the controller.
The amount they had to do so was pretty small.
>3. You need to create a new class for each new element type
>(less of a problem in Java?). For C++, this means recompiling
>the application.
Non-problem in Java... in fact, you don't even need to know what
you've got when you start; when you find a new element, you can
dynamically see if there's a class for it.
>I'd be really interested to hear views in favour of the class approach.
Why I wrote this. I would say that while we'd all prefer a declarative
stylesheet approach, it is my belief that in a lot of cases it's going
to be common to use, at least occasionally, some per-element custom
logic. Java makes this easy enough to be very appealing as a general
framework.
- Tim