[
Lists Home |
Date Index |
Thread Index
]
Arjun Ray wrote:
>
> james anderson <james.anderson@setf.de> 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.
unless the parser always works with a construction context, for which application provides the initial value. in that case, the context is in the position to
instantiate model nodes.
> 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.
is it? does "classic recursive descent" pass both a control instance and a model instance?
>
> | 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.
>
more general than that. the same class need not implement both the model and control interface. it applies to whatever is to be parsed, not just elements.
...
|
