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.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||