cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Pipeline components and Object Model issues
Date Sun, 19 Aug 2007 22:12:54 GMT
Joerg Heinicke pisze:
> On 19.08.2007 10:03 Uhr, Grzegorz Kossakowski wrote:
> 
>> Same goes for all other SAX events. It's actually one extra get and 
>> two puts calls on Map. Rather lightweight, yes?
> 
> But as you say it has to happen for EACH SAX event. I don't think it's 
> lightweight. It happens hundreds times even for simple HTML pages - per 
> component!

Correct me if I'm wrong but I thought that every pipeline component handles (even if it's
simple 
forwarding) every single SAX event, right? If so performance loss would at the most two times

slower. If you take into account components that actually do something the performance loss
could be 
less noticeable I think.

> Why do you go this low-level approach and instead of just implementing a 
> MethodInterceptor applied with Spring's AOP. That makes it independent 
> from Spring itself since the interceptor can be applied differently later.

I'm not Spring specialist, BeanPostProcessor was the first thing I found in docs (chapter
3) that 
fitted my needs. I'll adjust my code tomorrow.

> I wonder if that's a requirement at all. IMO a properly scoped OM *is* 
> part of the component setup. So I would not even care if the 
> corresponding code has to be touched.
> 
> Anyway, I can't see where the simple wrapper approach fails. We'll get 
> kind of a hierarchical OM similar to Spring's hierarchical application 
> contexts. Creating the wrapped OM can happen in the same AOP/ 
> BeanPostProcessor way, but it happens only on setup time and once, not 
> for each SAX event by intercepting the setObjectModel() method:
> 
> on setObjectModel(parentOM) on component xy
> do xy.setObjectModel(new ObjectModelWrapper(parentOM))
> 
> The ObjectModelWrapper holds a map of local vars and delegates to the 
> parent OM if it can not find a value in its local vars.

Ok, so component (let it be transformer) has wrapped OM puts local variable on wrapper only.
Now 
imagine that transformer is BeanFactoryAware that uses some other component (let it be a Foo

component) to transform some elements. Foo components depends on Bar component, that in turn
depends 
on Object Model.

What original transformer writer could expect is that it's current state of it's Object Model

(wrapper) is visible to the Bar component as it is derived from the transformer. As you guessed
it, 
only unwrapped Object Model will be visible to the Bar component.
I hope that you understand now why scope and it's changing is needed.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection                ***
*** incessantly so I'll not be able to respond to e-mails                     ***
*** regularly and my work will be somehow irregular.                          ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***

Mime
View raw message