CachingPoint algorithm and treeprocessor

[Michael Melhem <mi...@fztig938.bank.dresdner.net>]

Hi Carsten,

Hows things, I hope all is well in your neck of the woods!

As we have been discussing earlier, I have been doing some more work
on "cache points" I believe I have something that appears to be workng!

However, there a couple of issues I would like to run by you:

Issue 1.
I have added  a new method to the interface "ProcessingPipeline.java".
Namely,  public void informBranchPoint();

In "AbstractProcessingPipeline.java" the default implementation of this
method simply does nothing. ie public void informBranchPoint() {}. It is
redifined in CachingPOINTProcessingPipeline to do something meaningful.

The above method is used within the treeprocessor to inform the chosen pipeline
implementation that we have come across a branch in the tree.  What the
pipeline does with this information is up to the particular chosen
implementation. The default caching implementation ignores it. As an example,
here is a code snippet from GenerateNode.java.

---------------------------------------------
...
if (this.views != null) {
   //
   //
   // Inform the pipeline that we have a branch
   // point
   //
   context.getProcessingPipeline().informBranchPoint();

   String cocoonView = env.getView();
   if (cocoonView != null) {
...
---------------------------------------------

Do you think the above proposed change to treeprocessing is acceptable in terms of
performance etc? At the moment I dont see a way around it.



Issue 2.
I was thinking of breaking up some of the methods in CachingProcessingPipeline.java
so that my modifcations can be easly moved into a sub class. This Would
Involve creating something like AbstractCachingProcessingPipeline.java,
wth CachingProcessingPipeline.java and CachingIPointProcessingPipeline.java would
implementing this. What do you think of this?


Many thanks,
Michael Melhem



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: CachingPoint algorithm and treeprocessor

[Carsten Ziegeler <cz...@s-und-n.de>]

Michael Melhem wrote:
> 
> As we have been discussing earlier, I have been doing some more work
> on "cache points" I believe I have something that appears to be workng!
> 
> However, there a couple of issues I would like to run by you:
> 
> Issue 1.
> I have added  a new method to the interface "ProcessingPipeline.java".
> Namely,  public void informBranchPoint();

Ok.

> 
> In "AbstractProcessingPipeline.java" the default implementation of this
> method simply does nothing. ie public void informBranchPoint() {}. It is
> redifined in CachingPOINTProcessingPipeline to do something meaningful.
> 
ok.

> The above method is used within the treeprocessor to inform the 
> chosen pipeline
> implementation that we have come across a branch in the tree.  What the
> pipeline does with this information is up to the particular chosen
> implementation. The default caching implementation ignores it. As 
> an example,
> here is a code snippet from GenerateNode.java.
> 
> ---------------------------------------------
> ...
> if (this.views != null) {
>    //
>    //
>    // Inform the pipeline that we have a branch
>    // point
>    //
>    context.getProcessingPipeline().informBranchPoint();
> 
>    String cocoonView = env.getView();
>    if (cocoonView != null) {
> ...
> ---------------------------------------------
> 
> Do you think the above proposed change to treeprocessing is 
> acceptable in terms of
> performance etc? At the moment I dont see a way around it.
> 
> 
Yes, it seems that this is the only working way.

> 
> Issue 2.
> I was thinking of breaking up some of the methods in 
> CachingProcessingPipeline.java
> so that my modifcations can be easly moved into a sub class. This Would
> Involve creating something like AbstractCachingProcessingPipeline.java,
> wth CachingProcessingPipeline.java and 
> CachingIPointProcessingPipeline.java would
> implementing this. What do you think of this?
> 
Yes, that's okay, if it helps you.

Michael, I would suggest that you give this developer list a brief
overview on the topic and intention of your changes. I think, 
currently only we two know, what we are talking about.

Bye
Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org