Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The SAX code has a bunch of case statements in the handlers for which kind of tag is being processed. I would prefer to see this coded another way with SAX. I try to avoid big case statements.

    That's pretty much just how SAX works I'm afraid. It has a tendency to contain a large case statement with things that say: "If tag is this do this. If tag is that do that."

    I'd welcome alternate ways of designing SAX handlers though. Unfortunately that tends to be the way data driven code works.

    Trying SAX Modules
    • I'd welcome alternate ways of designing SAX handlers though. Unfortunately that tends to be the way data driven code works.

      I'm not really knowledgable enough about SAX to understand this design problem to make a good suggestion, but I won't let that stop me.

      I have been using XML::Twig and XML::Writer with some success, and have enjoyed the XPath features in XML::Twig.

      Instead of writing a large case statement, I usually use a dispatch table. Typically I use a hash of anonymous subs, where the key to

      --
      It should work perfectly the first time! - toma
  • The more I read about SAX programming the less I like it. I'd look at turning the element data structures into first class objects:

    sub start_element {
            my $self = shift;
            my $e = ElementFactory->make_from_struct(shift);
            $e->start_with_parser($self);
    }

    And have start_with_parser do the double dispatch trick:

    sub MyElement::docbook::para::start_with_parser {
            my $self = shift;