[
Lists Home |
Date Index |
Thread Index
]
- From: Tim Bray <tbray@textuality.com>
- To: xml-dev@ic.ac.uk
- Date: Fri, 27 Jun 1997 14:39:49 -0700
At 02:08 PM 27/06/97 +0000, akirkpatrick@ims-global.com wrote:
>I did something very similar recently (admittedly in C++)
>and abandoned it...
>
>1. Leads to "class spaghetti" with similar code being spread
>all over the place.
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
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
|
