OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Lark 0.90 available, with an applica

[ 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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS