Antonio Gallardo wrote:
We already have map:action to this. With map:action the sitemap
complexity grows very fast in some times to unreadable sizes.
Yes, but why using Java on the one hand and JavaScript on the other? Why
not using for both solutions JavaScript as alternative way? This mix
Stephan Coboos dijo:
Antonio Gallardo wrote:
We already have map:action to this. With map:action the sitemap
complexity grows very fast in some times to unreadable sizes.
Yes, but why using Java on the one hand and JavaScript on the other? Why
not using for both solutions JavaScript as
Yes windows. Running from the command line with the linotype block
included does not give me the same error, so it must have to do with
something else too.
Unico
-Original Message-
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
Sent: woensdag 25 februari 2004 19:12
To: [EMAIL
Antonio Gallardo wrote:
AFAIK, there as an initiative to use javascript in XSP. But for a lack of
interest there is not fully developed.
Yes, I know. But I dont like XSP. I think XSP is not the best way to
integrate logic.
For historical reasons flow was introduced with flowscript for
On Thu, Feb 26, 2004 at 10:22:12AM +0100, Stephan Coboos wrote:
I think a solution like this:
map:match pattern=first
map:call function=getValues return=true/
map:transform type=jxt/
map:serialize/
/map:match
is more easier to understand than this:
map:match pattern=first
Stephan Coboos dijo:
is more easier to understand than this:
map:match pattern=first
map:call function=getValues/
/map:match
map:match pattern=second
map:generate type=jxt/
map:serialize/
/map:match
Did you already saw the advantage of this?:
map:pipeline
map:match
Leszek Gawron wrote:
On Thu, Feb 26, 2004 at 10:22:12AM +0100, Stephan Coboos wrote:
I think a solution like this:
map:match pattern=first
map:call function=getValues return=true/
map:transform type=jxt/
map:serialize/
/map:match
is more easier to understand than this:
map:match
Antonio Gallardo wrote:
Stephan Coboos dijo:
is more easier to understand than this:
map:match pattern=first
map:call function=getValues/
/map:match
map:match pattern=second
map:generate type=jxt/
map:serialize/
/map:match
Did you already saw the advantage of this?:
map:pipeline
I don't understand. I'm looking for the source that matches the snapshot
sent out in Cocoon 2.1.4.
-Original Message-
From: Hamilton Verissimo de Oliveira (Engenharia - SPO)
[mailto:[EMAIL PROTECTED]
Sent: Thursday, February 26, 2004 9:03 AM
To: [EMAIL PROTECTED]
Subject:
Easy, Carsten and Leo Sutic are working on a release by now. It will be
ready real soon.
regards,
hammett
-Mensagem original-
De: Ralph Goers [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 26 de fevereiro de 2004 13:55
Para: '[EMAIL PROTECTED]'
Assunto: excalibur-component
I
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27254.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stephan Coboos [EMAIL PROTECTED] writes:
Christopher Oliver wrote:
Um, how much harder is this:
map:match pattern=listProducts
map:generate type=file src=products.xml/
map:call function=readProductBeans/
/map:match
map:match pattern=listProducts-result-pipeline
Without looking into it...
What about a wiki page how you got this working?
Sounds like a good addition!
cheers
--
Torsten
I've got a weird problem generating pdfs using FOP from xml containing
SVG; but only when processed through Cocoon (2.1.2). Generation directly
with FOP is problem free.
Same FOP version? Do you imply other Cocoon versions are working?
cheers
--
Torsten
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27260.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
So what about the following...
+ the boilerplate
--
/*
Copyright 1999-2004 The Apache Software Foundation. All rights reserved.
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License
If you really want to use JavaScript in an action instead of Java, write an
action (in Java) that calls an arbitrary JavaScript function. Maybe that's
what BSF does, I don't know.
Ralph
-Original Message-
From: Stephan Coboos [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 26,
On 26 Feb 2004, at 17:12, Torsten Curdt wrote:
+ and we remove all author tags
I find this just a little bit too reactionary - especially for the
little known/used areas of code. We haven't had ownership issues
because of them in the past, not? These tags sometimes help to find a
contact, when
Ralph Goers wrote:
I guess Carsten is out of town? Does anybody else know how to get the
source for the snapshot of excalibur-component used in Cocoon. I looked at
the avalon-excalibur in CVS and didn't see any tags that match. Am I
supposed to check out by the date and hope that nothing else
Thanks for the info.
Maybe I misunderstood, but I had requested before the release that the
source for snapshots be made available from Cocoon's site. I thought that
this had been agreed to. It is a royal pain for me to do CVS checkouts from
work. Also, I'd like to know with 100% certainty
On Thu, Feb 26, 2004 at 07:00:09PM +0100, Torsten Curdt wrote:
Steven Noels wrote:
On 26 Feb 2004, at 17:12, Torsten Curdt wrote:
+ and we remove all author tags
I find this just a little bit too reactionary - especially for the
little known/used areas of code. We haven't had ownership
Torsten Curdt wrote:
What about a wiki page how you got this working?
See
http://xml.apache.org/fop/pdfencryption.html
for how to set up the infrastructure and the relevant
cocoon pages for passing options to the renderer.
J.Pietschmann
So how can I formally request that this be a requirement in future builds -
and possibly get something for 2.1.4 as well.
Suppose I was to deploy my product now base on 2.1.4 and I didn't capture
all the source for the dependent components and in 6 months or so a bug is
reported. To debug
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow seems to be too different from
those of outbound data flow.
For outbound data flow
* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow seems to be too
Alan wrote:
* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow
Daniel's message got me to thinking. In our case we don't really need the
power of Cocoon forms as we are perfectly happy using XSLT to generate html.
All we'd like is something a little better than the FormValidatorAction. I
could easily see a new action that that invokes a pipeline to process
Torsten Curdt wrote:
Steven Noels wrote:
Torsten Curdt wrote:
+ and we remove all author tags
I find this just a little bit too reactionary - especially for the
little known/used areas of code. We haven't had ownership issues
because of them in the past, not? These tags
I agree with Antonio about the utility of @author tags (I have also found them very
useful), and I also think that the ASF board's concerns about the dangers of
ownership are probably overblown.
I don't think the ASF should discourage developers from keeping useful metadata about
the code
--
/*
Copyright 1999-2004 The Apache Software Foundation. All rights reserved.
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
I noticed your discussion regarding the new licenses.
Torsten Curdt wrote:
Nah... we never cared about that before. I don't think...
...does anyone think we have to??
About the copyright dates, you can read the email of Conor McNeill.
Vadim Gritsenko wrote:
Torsten Curdt wrote:
David Crossley wrote:
Will we just have all files as 1999-2004 or do we need to
determine the actual first and last modification date of
each file? The latter is an awful lot of work, but if we
need to do it then there are some tools in the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27279.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Antonio Gallardo wrote:
Steven Noels dijo:
On 26 Feb 2004, at 17:12, Torsten Curdt wrote:
+ and we remove all author tags
I find this just a little bit too reactionary - especially for the
little known/used areas of code. We haven't had ownership issues
because of them in the past, not? These
Torsten Curdt wrote:
--
/*
Copyright 1999-2004 The Apache Software Foundation. All rights
reserved.
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
Torsten Curdt wrote:
So what about the following...
+ the boilerplate
--
/*
Copyright 1999-2004 The Apache Software Foundation. All rights reserved.
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
David Crossley wrote:
Torsten Curdt wrote:
Steven Noels wrote:
Torsten Curdt wrote:
+ and we remove all author tags
I find this just a little bit too reactionary - especially for the
little known/used areas of code. We haven't had ownership issues
because of them in the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27275.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://xml.apache.org/fop/pdfencryption.html
for how to set up the infrastructure and the relevant
cocoon pages for passing options to the renderer.
Excellent, thanks for the pointer...
...I put it into the wiki and added a new
way to configure the renderer...
Carsten,
I'm all for using only formal releases of dependent components. I asked
about that several months ago and was told it was not possible, so instead I
asked for a way to get the same source that was used by the person who
integrated it into Cocoon. If 2.1.5 and on will only use formal
As already said in this thread, the only working way to get
the sources of the developer builds for excalibur-components
(and some others) is to check out the state from exactly
the specified date. That's why a jar contains the date
in the name.
Now, we discussed this topic, but never agreed to
I guess Carsten is out of town? Does anybody else know how to get the
source for the snapshot of excalibur-component used in Cocoon. I looked at
the avalon-excalibur in CVS and didn't see any tags that match. Am I
supposed to check out by the date and hope that nothing else got changed
after it
If you really want to use JavaScript in an action instead of Java, write an
action (in Java) that calls an arbitrary JavaScript function. Maybe that's
what BSF does, I don't know.
We already have a ScriptAction in the BSF block
cheers
--
Torsten
First, let's collect what we like about the two components
It would be very cool if we could provide something that helps with flow
applications.
I like the combination of OR-Mapping/CForms/Flow but this
is for many beginners overkill. They shouldn't be forced to write Java
code e.g. in order
Hi
I've got a weird problem generating pdfs using FOP from xml containing
SVG; but only when processed through Cocoon (2.1.2). Generation directly
with FOP is problem free.
Same FOP version? Do you imply other Cocoon versions are working?
Nope, I'm implying FOP standalone with the same FOP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
47 matches
Mail list logo
