Although my reply is not directly related to your Perl question, I really hope you will find what I wrote is helpful. This is actually more related to your overall design.
- This first point is much less important than my second point, but it helps to understand the second one. I want to clearly distinguish handler from parser, and make the SAX architecture straight.
I am not quite sure whether you have other pieces of code, which you didn't show here, but really acts as the parser. I am saying this because, this piece of code you post here is not really the parser, but the handler.
The parser is the generator, which takes the xml data as a stream, (it is not important whether the stream comes from a file, a socket, a string, or whatever), trying to understand the stream piece by piece, and generating events accordingly.
On the other hand, the handler is the consumer, consuming those events generated by the parser, and processing them, (migth as simple as printing the events on screen, or more complex, like storing them in certain data structure as you did here...)
- I am not trying to bug you with some wording stuff, my real point here is that, I clearly see an opportunity for you to excise the filtering concept defined in SAX architecture.
As you described, you only care a subset of those nodes, but not all. In this case, only nodes concerning particular books in a predefined list.
In stead of, as you showed here, to mix this filtering functionality with the event handling functionality, I would really like to suggest you, to put the filtering part in a separate package as a different class. When you look at the big picture, you see this filter standing between your parser and event hanlder.
By doing this, your interface is more clear, and it is more OO. One common mistake people are making from time to time in the OO area is that, they just create one or couple of huge class(es), which contains more than what they should, if not all, and wasted the good opportunities to carefully define and design their classes. In this way, the code looks like OO, (and in fact it is OO from a pure language point of view,) but that is really NOT OO from a methodology point of view.
By separating your filter from your event handler, you will gain a much more clear interface and architecture, and open up the door for you and other people to reuse your code more easily, for similar purposes.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|
