COCOON3-126, xslt cache

[Jos Snellings]

Hi Francesco et al,

I proposed a patch for COCOON3-126, on the configurability of using an LRU
cache for
xslt transformations. I am not too happy with it though.

I would like to have a member function to set "isCacheEnabled", or to set
this at setup.
However, the resource is loaded in the constructor.
Would it be better to add a boolean "isCacheEnabled' to a constructor,
leaving the default
to "yes"?

What do you think?

Kind regards,
Jos

[Simone Tripodi]

Hi Jos,

the most important thing is IMHO having the XSLT transformer
dependencies-less as much as we can - I suggest to define a "cache"
interface (with a basic implementation) provided to XSLT transformer
(via constructor), then users are free to use whatever implementation
they need/prefer.

Having a default implementation would be a strict constraint, while
users should be able to plug their integration module depending to
their use case.

Does it sound reasonable?

I have ~0 spare cycles to OSS ATM, but I promise to have a look at
your patch during the WE, so I can at least provide you more
feedbacks.

Have a nice day, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi


On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings

Post by Jos Snellings
Hi Francesco et al,
I proposed a patch for COCOON3-126, on the configurability of using an LRU
cache for
xslt transformations. I am not too happy with it though.
I would like to have a member function to set "isCacheEnabled", or to set
this at setup.
However, the resource is loaded in the constructor.
Would it be better to add a boolean "isCacheEnabled' to a constructor,
leaving the default
to "yes"?
What do you think?
Kind regards,
Jos
--
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid. She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain

[Jos Snellings]

Yes, Simo, that is a good approach!
I think it is worth the work in order to keep the cocoon base classes tidy.

We can work out a proposal during the weekend, (though it will be very nice
weather in Belgium).

Cheers,
Jos

Post by Simone Tripodi
Hi Jos,
the most important thing is IMHO having the XSLT transformer
dependencies-less as much as we can - I suggest to define a "cache"
interface (with a basic implementation) provided to XSLT transformer
(via constructor), then users are free to use whatever implementation
they need/prefer.
Having a default implementation would be a strict constraint, while
users should be able to plug their integration module depending to
their use case.
Does it sound reasonable?
I have ~0 spare cycles to OSS ATM, but I promise to have a look at
your patch during the WE, so I can at least provide you more
feedbacks.
Have a nice day, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings

Post by Jos Snellings
Hi Francesco et al,
I proposed a patch for COCOON3-126, on the configurability of using an

LRU

Post by Jos Snellings
cache for
xslt transformations. I am not too happy with it though.
I would like to have a member function to set "isCacheEnabled", or to set
this at setup.
However, the resource is loaded in the constructor.
Would it be better to add a boolean "isCacheEnabled' to a constructor,
leaving the default
to "yes"?
What do you think?
Kind regards,
Jos
--
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid. She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain

[Simone Tripodi]

Post by Jos Snellings
We can work out a proposal during the weekend, (though it will be very nice
weather in Belgium).

we are having sunny days in Rome as well (finally!) so I'll do some
work in the night on the terrace :)

have a nice day, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi

[Jos Snellings]

Yet, as a Roman, you enjoy a different likelihood for sunny weather :-).
Nonetheless, getting inspiration is very important!

Jos

Post by Simone Tripodi

Post by Jos Snellings
We can work out a proposal during the weekend, (though it will be very

nice

Post by Jos Snellings
weather in Belgium).

we are having sunny days in Rome as well (finally!) so I'll do some
work in the night on the terrace :)
have a nice day, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi

[Jos Snellings]

Hi Simo (et al),

1. I do not get the point defining the 'cache' interface.
The simplest would be to allow a switch in the constructor:

In that case, forget the injection: "@Autowire private Settings settings;"

public XSLTTransformer(boolean enableLRUCache)
public XSLTTransformer(final URL url, boolean enableLRUCache)

If the behaviour 'without LRU Cache' is only desired from within the
sitemap, the first constructor is enough.
The parameter can be passed through through "setConfiguration" or setup().
Aren't 'settings' already a part of the
cocoon object that comes with the setup parameters.

2. Alternative: create two classes:

public class XSLTTransformerLRU extends AbstractSAXTransformer implements
CachingPipelineComponent

public class XSLTTransformer extends AbstractSAXTransformer implements
CachingPipelineComponent

I would say: the first is simpler.

Cheers,
Jos

Post by Simone Tripodi
Hi Jos,
the most important thing is IMHO having the XSLT transformer
dependencies-less as much as we can - I suggest to define a "cache"
interface (with a basic implementation) provided to XSLT transformer
(via constructor), then users are free to use whatever implementation
they need/prefer.
Having a default implementation would be a strict constraint, while
users should be able to plug their integration module depending to
their use case.
Does it sound reasonable?
I have ~0 spare cycles to OSS ATM, but I promise to have a look at
your patch during the WE, so I can at least provide you more
feedbacks.
Have a nice day, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings

Post by Jos Snellings
Hi Francesco et al,
I proposed a patch for COCOON3-126, on the configurability of using an

LRU

Post by Jos Snellings
cache for
xslt transformations. I am not too happy with it though.
I would like to have a member function to set "isCacheEnabled", or to set
this at setup.
However, the resource is loaded in the constructor.
Would it be better to add a boolean "isCacheEnabled' to a constructor,
leaving the default
to "yes"?
What do you think?
Kind regards,
Jos
--
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid. She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain