[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: parser models

• To: xml-dev@l...
• Subject: Re: parser models
• From: Arjun Ray <aray@n...>
• Date: Tue, 24 Sep 2002 19:51:05 +0000
• In-reply-to: <3D9055F9.ED40863F@s...>
• References: <r01050300-1015-399AD282CE5611D6B76F0003937A08C2@[192.168.124.21]> <200209232145.RAA03126@m...> <skf0pugrt2v186al9126s64sdn2g062l0b@4...> <3D9055F9.ED40863F@s...>

james anderson <james.anderson@s...> wrote:

| in the case of a pull parser, calls like currContent.newChild, below, 
| produce instances which are eventually passed back to the application, 
| while in a push parser they pass control into the application. there 
| is little difference between the two. 

I'm probably misunderstanding what you're saying, but one big difference
would seem to be that the definition of the instance is determined by the
parser system with pull and by the application with push.  If you're
saying that access to the parser (to pull event notifications) could be
tag-teamed - on a call stack - between instance builders and content
handlers, I'd agree: this is just the classic recursive descent pattern.

| nb. it is better for the interface and logic to distinguish between the 
| construction context and the constructed instance and to permit the 
| application the opportunity to decide whether they coincide.

Yes, that's why I termed the example "cheesy".  The same class need not
implement both Element and Content interfaces. The point of the pattern is
the ability to separate them.

• Follow-Ups:
  • Re: parser models
    • From: james anderson <james.anderson@s...>

• References:
  • parser models
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: parser models
    • From: John Cowan <jcowan@r...>
  • Re: parser models
    • From: Arjun Ray <aray@n...>
  • Re: parser models
    • From: james anderson <james.anderson@s...>

• Prev by Date: RE: SVG implementations
• Next by Date: Re: parser models
• Previous by thread: Re: parser models
• Next by thread: Re: parser models
• Index(es):
  • Date
  • Thread