Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Steven Noels wrote:
On 28 Sep 2004, at 10:39, Pier Fumagalli wrote:
Thanks, that I didn't know... Since the WIKI moved off to that
MoinMoin crap, I seriously tend to ignore it a lot more...
I have to agree with Pier. I'm a picky bastard in term of s
Stefano Mazzocchi wrote:
Steven Noels wrote:
On 28 Sep 2004, at 10:39, Pier Fumagalli wrote:
Thanks, that I didn't know... Since the WIKI moved off to that
MoinMoin crap, I seriously tend to ignore it a lot more...
I have to agree with Pier. I'm a picky bastard in term of style: it the
thing is n
Steven Noels wrote:
On 28 Sep 2004, at 10:39, Pier Fumagalli wrote:
Thanks, that I didn't know... Since the WIKI moved off to that
MoinMoin crap, I seriously tend to ignore it a lot more...
For somehow who maintained the previous Wiki for two years, and
reluctantly gave up after the daily reboot
On 28 Sep 2004, at 19:10, Vadim Gritsenko wrote:
Ok, like Hashtable usage:
+this.x_parameters = new Hashtable();
Instead of HashMap (with default map size):
+this.x_parameters = new HashMap(3);
FUDGE! :-) I blame that on Eclipse's auto-completion! ;-P
Or, like doing:
+this.x_source = at
Pier Fumagalli wrote:
On 28 Sep 2004, at 18:13, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 28 Sep 2004, at 12:00, Vadim Gritsenko wrote:
Go ahead, add parameters.
...
value
Done, I'm posting the patch here before applying just to triple-check
I'm not f***ing up the whole thing. I mean, it
On 28 Sep 2004, at 18:13, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 28 Sep 2004, at 12:00, Vadim Gritsenko wrote:
Go ahead, add parameters.
...
value
Done, I'm posting the patch here before applying just to triple-check
I'm not f***ing up the whole thing. I mean, it works for me, but do
Pier Fumagalli wrote:
On 28 Sep 2004, at 12:00, Vadim Gritsenko wrote:
Go ahead, add parameters.
...
value
Done, I'm posting the patch here before applying just to triple-check
I'm not f***ing up the whole thing. I mean, it works for me, but do a
quick review.
Beside minor nitpicks, looks go
On 28 Sep 2004, at 14:54, Pier Fumagalli wrote:
+// TODO: remove this debugging code!
+System.err.println("Including \"" + encodedSource
+ "\" from \""
+ + source.getURI() + "\" ("
+
On 28 Sep 2004, at 12:00, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 27 Sep 2004, at 23:49, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
Then we could re-create the request by something like:
value
Well, if the only thing which troubles you is request, then you can
easily do this now wi
Pier Fumagalli wrote:
On 27 Sep 2004, at 23:49, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
Then we could re-create the request by something like:
value
Well, if the only thing which troubles you is request, then you can
easily do this now with simple:
And be done with it. You won't need
On 28 Sep 2004, at 10:39, Pier Fumagalli wrote:
Thanks, that I didn't know... Since the WIKI moved off to that
MoinMoin crap, I seriously tend to ignore it a lot more...
For somehow who maintained the previous Wiki for two years, and
reluctantly gave up after the daily reboots of JSPWiki became t
On 27 Sep 2004, at 23:43, Conal Tuohy wrote:
Pier Fumagalli wrote:
I was thinking about one thing... The one thing that troubles
us is the
"request". That introduce a degree of variability that (i
don't know to
what degree), might be counter-productive to analyze and cache...
What about if we were
On 27 Sep 2004, at 23:49, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 27 Sep 2004, at 21:06, Vadim Gritsenko wrote:
What about using a similar approach to generate the cache? I'll try
to set up a test environment and to give it a shot if you have
nothing against it!
Do you refer to the fact
Pier Fumagalli wrote:
On 27 Sep 2004, at 21:06, Vadim Gritsenko wrote:
What about using a similar approach to generate the cache? I'll try
to set up a test environment and to give it a shot if you have
nothing against it!
Do you refer to the fact that it uses list of request parameters and
its
Pier Fumagalli wrote:
> I was thinking about one thing... The one thing that troubles
> us is the
> "request". That introduce a degree of variability that (i
> don't know to
> what degree), might be counter-productive to analyze and cache...
>
> What about if we were doing "subrequest"s, much
On 27 Sep 2004, at 21:06, Vadim Gritsenko wrote:
What about using a similar approach to generate the cache? I'll try
to set up a test environment and to give it a shot if you have
nothing against it!
Do you refer to the fact that it uses list of request parameters and
its values as a cache key?
Pier Fumagalli wrote:
On 27 Sep 2004, at 20:17, Vadim Gritsenko wrote:
PK_G-file-doc.xml_T-I-cocoon://internal?pipelinehash=1234567890_S-xml
Have you seen my earlier commit of the "ResourceParameterGenerator"
today?
Yes, "RequestParameterGenerator".
What about using a similar approach to gener
On 27 Sep 2004, at 20:17, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
Sure. Problem is the following. Consider you have a pipeline
'internal' which generates different responses depending on the value
of request parameter 'a':
Example request and responses:
Requesting /interna
Pier Fumagalli wrote:
On 27 Sep 2004, at 19:15, Vadim Gritsenko wrote:
Don' wonder; properties were missing.
Cheeridos!
:)
Now, an annotated dump on the source tells me that you added the
following FIXME comment:
36336 unico public Serializable getKey() {
47017 vgritsenko // FI
On 27 Sep 2004, at 19:15, Vadim Gritsenko wrote:
Pier Fumagalli wrote:On 27 Sep 2004, at 18:57, [EMAIL PROTECTED] wrote:
Author: pier
Date: Mon Sep 27 10:57:10 2004
New Revision: 47320
Modified:
cocoon/branches/BRANCH_2_1_X/src/blocks/scratchpad/java/org/apache/
cocoon/transformation/IncludeT
20 matches
Mail list logo
