You mis one argument in new AttributesImpl();
it should be new AttributesImpl(attr), see comments in text
AS
Hi all. I need to implement a my own transform that does a
link rewriter. the scope is to change the href value of a
tag in a html file (a well formed html file checked by jtidy
Thorsten Scherler wrote:
El vie, 14-10-2005 a las 16:25 +0200, Felix Röthenbacher escribió:
Hi Thorsten
Thorsten Scherler wrote:
Hey all,
lenya just added the dynamic repeater example to the default pub. The
problem with it is, that if we use ajax=true and submit the form we
lose the
Thorsten Scherler wrote:
El jue, 27-10-2005 a las 12:58 +0200, Thorsten Scherler escribió:
Thx it seems recent commits have solved this issue.
I was wrong, only the error is gone but still it is not working. :(
Er... I don't follow you here: what is not working? Do you still have
This is quite complex what you want. When stored on filesystem and using
something in a cached pipeline, a change of the file will invalidate the cached
pipeline (do not know if this happens instantly or on requesting the pipeline
again, I suppose the last). But when you are using some
I think this should be
map:generate src=cocoon:/get-event/{../id} /
Doh. Yep; the works a charm. Thanks for that :).
Gary
*
The information contained in this message may be confidential or
legally privileged and is
Something like
map:match pattern=**
map:select type=resource-exists
map:when test={1}/sitemap.xmap
map:mount src={1} uri-prefix=whatever/
/map:when
map:otherwise
map:generate type=directory src={1}/
map:transform
I understand that protocol like http: or webdav: cannot check cache-key
validity over the network.
But my understanding is slide: protocol is just a direct access to the
Slide API, that in my case access the file locally on the server. So I
guess the overhead is small compare to a direct file
Cousson, Benoit wrote:
I understand that protocol like http: or webdav: cannot check cache-key
validity over the network.
But my understanding is slide: protocol is just a direct access to the
Slide API, that in my case access the file locally on the server. So I
guess the overhead is small
Ard Schrijvers wrote:
Something like
map:match pattern=**
map:select type=resource-exists
map:when test={1}/sitemap.xmap
map:mount src={1} uri-prefix=whatever/
/map:when
map:otherwise
map:generate type=directory src={1}/
Note that map:match pattern=** is totally useless, as it matches
everything!
Ard probably meant map:match pattern=*/** ..
:-)
G.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Geert Josten wrote:
Note that map:match pattern=** is totally useless, as it matches
everything!
Ard probably meant map:match pattern=*/** ..
:-)
Doh, you're right! I have a special brain matcher for match
pattern='**' that automatically triggers this answer without reading
much further
It was not meant as a top-level matcher of course. I use this kind of matcher
often at the end of of sitemap to match everything that was not matched before,
which seems pretty normal to me. Ofcourse, what Geert says, if you have
directories, you would use */**, unless dirs are 2 levels deep
Hello Dion,
thanks for the info. I really would like to test the new version, but - to
be honest - I've still some serious problems getting the 1.2 running, using
the ejbDeploy goal:
[wasEjbDeploy] Failure invoking BootLoader.startup method
[wasEjbDeploy]
Hi all
I need to process large xml file and as I tested with increasingly larger
file, the time to process suddently increased a lot. For instance, 200 K
files took 0.8 seconds, 400 K file 2.5 sec and when I get near 1 Meg, it
jumps to 30 seconds (nearly 10 times, for twice the size).. I played
Boisvert, Éric wrote:
Hi all
I need to process large xml file and as I tested with increasingly larger
file, the time to process suddently increased a lot. For instance, 200 K
files took 0.8 seconds, 400 K file 2.5 sec and when I get near 1 Meg, it
jumps to 30 seconds (nearly 10 times, for
Boisvert, Éric wrote:
Hi all
I need to process large xml file and as I tested with increasingly larger
file, the time to process suddently increased a lot. For instance, 200 K
files took 0.8 seconds, 400 K file 2.5 sec and when I get near 1 Meg, it
jumps to 30 seconds (nearly 10 times, for
finally got around to installing it - looks good!On 10/27/05, Sylvain Wallez [EMAIL PROTECTED] wrote:
Bruno Dumon wrote: In the _javascript_ validation (or in any validation for that matter), if
you return false, you should also set a validation error on the widget to which the validator belongs,
thanks, I saw that. I wondered if there was some obvious thing I could
check before starting rewriting the xslt (I know, I'm lazy)
Eric
-Message d'origine-
De : Ralph Goers [mailto:[EMAIL PROTECTED]
Envoyé : 28 octobre, 2005 11:51
À : users@cocoon.apache.org
Objet : Re: processing
You may not have to rewrite your xslt. Part of the idea is to reduce the
size of the document by eliminating unnecessary stuff in a transformer
before your XSLT is invoked.
Ralph
Boisvert, Éric wrote:
thanks, I saw that. I wondered if there was some obvious thing I could
check before
not much to remove, I'm afraid.. The xslt in question mostly reformat a
document into another format, but keeps all the same information.
I'm investigating Vermer's options right now..
keeps suggestions coming.. they are appreciated.
Eric
-Message d'origine-
De : Ralph Goers
hi,
have you seen Nico Verwer's presentation Performance on big documents.
You can download it as mp3/pdf on
http://www.cocoongt.org/Slides-and-recordings.html
They used a nice two-step appoach for transforming bid documents.
perhaps it helps,
Christoph
Boisvert, Éric wrote:
not much to
yeah. Verwer (I mispelled his name - my finger took control over my brain
again), this is what I'm reading.
Now I cannot make xsltc work (returns an empty document).. anything I should
know ?
Cheers
Eric
-Message d'origine-
De : Christoph Gaffga (triplemind.com) [mailto:[EMAIL
keeps suggestions coming.. they are appreciated.
XSLT transforms are the most obvious reason for the memory usage and speed behaviour you observe. It
is really a matter of limiting the memory usage, that will influence the performance the most. Is it
really necessary to use XSLT? Could STX be
Hello Éric,
If this file is not very complex and You don't need XPath to be
happy then You should to consider writing custom Transformer or
Generator. SAXParser interface is easy to use.
Friday, October 28, 2005, 5:30:50 PM, you wrote:
BÉ Hi all
BÉ I need to process large xml file and as
Merico Raffaele wrote:
Dear community
I hope somebody can explain me if the following situation is a feature or
bug.
The URL http://.../appl/auth/Index/TODO/ve2000 is auth-protected and matches
the pattern=auth** in the appl/sitemap.xmap.
The redirect-to uri=cocoon:/showLoginForm.cflow/ is
25 matches
Mail list logo
