Re: handling my PerlSAX handler

Vynce,

I really like the freshness of your ideas. Though I'm not an actual POOPer, I have some feelings about namespace. One of the main rules is:

Thou shalt not pollute thy namespace with auto-generated, out-of-control aka user-supplied names.

So I wouldn't use any module that would take one XML file, and pollute my namespace with (potentially) unexpected names that could overwrite my original namespace. Well, and that spells disaster for your module that generates Package:: subclasses. Even if they just are nodes on your own module. If there however is one or the other XML standard that nicely translates into an object-tree, than it's OK. But in that case, you are writing a package for a specific XML standard subclass rather than a generic XML parser.

But the idea is cool. There are real XML experts over here, so wait for better answers. Until than, peek at Processing XML with Perl (by mirod) for a nice overview of different libs.

Cheers,

Jeroen
"We are not alone"(FZ)

Edit: chipmunk 2001-05-21

Comment on Re: handling my PerlSAX handler

Replies are listed 'Best First'.
Re: Re: handling my PerlSAX handler by Vynce (Friar) on May 21, 2001 at 14:14 UTC
Oooh, i see i was unclear. Thou shalt not pollute thy namespace with auto-generated, out-of-control aka user-supplied names Indeed! i meant to imply the case where the coder has already written the packages; the handler would create a new object of the appropriate type, not a new class. of course, you have to know what the classes are called for each element; i was thinking along the lines of: my $handler = new XML::PerlSAX::Handler::Sanctum( # assume all packages are named "Publish::$element" baseclass => 'Publisher', # prefer "Publish::$parent::$element" # over "Publish::$element", to allow a book title # to be a different object than a chapter title. heirarchic => 'preferred', ); my $otherhandler = new XML::PerlSAX::Handler::Sanctum( dictionary => { # clear cases... BOOK => 'Publish::Book', CHAPTER => 'Publish::Chapter', PARAGRAPH => 'Publish::Paragraph', # <BOOK><TITLE></TITLE></BOOK> gets treated differently # than <CHAPTER><TITLE>... or <PARAGRAPH><TITLE>... 'BOOK TITLE' => 'Publish::Book::Title', 'CHAPTER TITLE' => 'Publish::Chapter::Title', TITLE => 'Publish::SectionHeading', } ); [download] honestly, it had occurred to me to create the classes if they couldn't be found, but i decided that i'd only do that if the user told me to do so, and even then only if they didn't already exist. and maybe not even then; let the user auto-create their objects if they want. thanks for the pointer to mirod's work, as well. .	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: handling my PerlSAX handler
by Vynce (Friar) on May 21, 2001 at 14:14 UTC

Oooh, i see i was unclear.

Thou shalt not pollute thy namespace with auto-generated, out-of-control aka user-supplied names

Indeed! i meant to imply the case where the coder has already written the packages; the handler would create a new object of the appropriate type, not a new class.

of course, you have to know what the classes are called for each element; i was thinking along the lines of:


my $handler = new XML::PerlSAX::Handler::Sanctum(
  # assume all packages are named "Publish::$element"
  baseclass => 'Publisher',
  # prefer "Publish::$parent::$element" 
  #   over "Publish::$element", to allow a book title 
  #   to be a different object than a chapter title.
  heirarchic => 'preferred',
  );

my $otherhandler = new XML::PerlSAX::Handler::Sanctum(
  dictionary => { 
    # clear cases...
    BOOK => 'Publish::Book',
    CHAPTER => 'Publish::Chapter',
    PARAGRAPH => 'Publish::Paragraph',
    # <BOOK><TITLE></TITLE></BOOK> gets treated differently
    # than <CHAPTER><TITLE>... or <PARAGRAPH><TITLE>...
    'BOOK TITLE' => 'Publish::Book::Title',
    'CHAPTER TITLE' => 'Publish::Chapter::Title',
    TITLE => 'Publish::SectionHeading',
    }
  );
[download]

honestly, it had occurred to me to create the classes if they couldn't be found, but i decided that i'd only do that if the user told me to do so, and even then only if they didn't already exist. and maybe not even then; let the user auto-create their objects if they want.

thanks for the pointer to mirod's work, as well.

[reply]
[d/l]