[
Lists Home |
Date Index |
Thread Index
]
There are two architectures you can use that solve this problem, I've used
them both satisfactorily. One is to write a ContentHandler that multicasts
events to recipients who have registered themselves: typically a recipient
registers itself as interested in element X, and when an X arrives you mark
that recipient as active and send it all events until the matching
end-element. The other approach is more of a pipeline: each event is
processed by the first filter in the pipeline, which then (if appropriate)
passes it on to further filters.
Michael Kay
http://www.saxonica.com/
> -----Original Message-----
> From: gbernd@gmx.de [mailto:gbernd@gmx.de]
> Sent: 29 January 2006 11:47
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] Maybe a newbie question: Awful OO software
> structure with SAX!?
>
> Hi,
>
> I have a software project holding its configuration data in an XML
> structured file. Currently I'm using DOM to load this
> configuration data and
> then kick off (instantiate) the relevant Java objects by providing the
> relevant DOM subtree to their constructor. Within each
> management object,
> this hierarchical evaluation of the configuration data is
> repeated as deep
> as necessary. For the example (see below), the "Evaluation" management
> receives the subtree below the <Evaluation>-node and provides
> DOM subtrees
> to the "Plot_2D" and "Plot_3D" management objects when
> instantiating them.
>
> <Main>
> <General>
> ...
> </General>
> <Evaluation>
> <Plot_2D>
> ...
> </Plot_2D>
> <Plot_2D>
> ...
> </Plot_2D>
> <Plot_3D>
> ...
> </Plot_3D>
> </Evaluation>
> </Main>
>
> When using the DOM concept, I like that each management
> object (General,
> Evaluation, Plot_2D, Plot_3D...) is responsible for parsing
> its own section
> of the configuration file. This reflects the OO software
> approach of putting
> the code to the data and simplifies code maintenance.
>
> Now, due the problem of determining line numbers in DOM, I'm
> considering
> using a SAX parser. But when reading the SAX tutorials, I'm
> horrified. All
> examples show one centralized event handler, which knows
> about all keywords
> and dispatches the values to the JAVA objects.
>
> This is against all OO approaches and requires changes in a
> central module
> each time a subsection of the configuration data is made. Now
> my question:
> Is this the intended way of using SAX? Or is there a way of
> forwarding the
> SAX-events to sub-eventhandlers located in the management
> objects, which I
> didn't find yet?
>
> With kind regards
> Bernd
>
> --
> DSL-Aktion wegen gro_er Nachfrage bis 28.2.2006 verldngert:
> GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
|
