Carsten Ziegeler wrote:
> Gianugo Rabellino wrote:
>
> Now on to the bad one:
> Cocoon has parser abstraction which works very well for us. The new parser
> abstraction from Avalon is even better (as it is theoretically possible
> to make the parser thread safe), but with the disadvantage of having a
> different
> interface.
>
> So the only compatible solution here, is to have both roles (the cocoon
> parser and the avalon parser) at the same time. All "old" components looking
> up the cocoon parser still work.
>
> All new code should not look up the cocoon parser, but the new avalon
> parser,
> so we have to change some code - but again in a compatible way as we only
> change implementation but no interfaces.
>
> But this all ends up in having two parser roles in the cocoon.xconf which
> can (and in some environments must) be configured.
>
> So one solution is to say:
> a) If the user has a special environment and has components using the "old"
> parser role, he has to configure both roles
> or
> b) We change the "old" parser role so that this parser itself uses the new
> parser. So only one role, the new avalon parser, has to be configured.
> But all components using the old parser role will decrease in
> performance.
c) The "parser" role stays the same, and the implementation is a tight wrapper
around the new Parser implementation. That way, we have one Component
that can operate as either role! (IOW the Cocoon Parser components implement
the new role and the old role). This reduces the performance issue,
while providing a transitional Component until all dependancies are
cleaned up. Note, this means that all functionality is in the Avalon
implementation, but no aditional lookup is required.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
