On Sat, 11 Sep 2004, Nikolaus Rath wrote:
I suspect that Cocoon uses some sort of Serialization to implement
Continuations and that the size and amount of referenced objects
directly influences performance.
The JavaFlow stores the Continuable objects in the session, so that
the field have
On Sat, 11 Sep 2004, Rolf Kulemann wrote:
Hello,
I just tried out the Javaflow block.
I wonder how I can access the parameters passed from the sitemap within
my flow methods.
I had a look to o.a.c.c.f.j.JavaInterpreter.callFunction(String
methodName, List params, Redirector redirector).
Am So, den 04.07.2004 schrieb bernhard huber um 20:06:
hi,
i have committed some more junit tests for cocoon core components.
The committed junit tests are
* ParameterMatcher.java
* PreparableMatcher.java
* RegexpURIMatcher.java
* RequestAttributeMatcher.java
*
Can you revert this change, I need this method time to time.
Thanks, Stephan.
1.14 +50 -37
cocoon-2.1/src/blocks/javaflow/java/org/apache/cocoon/components/flow/java/ContinuationClassLoader.java
Index: ContinuationClassLoader.java
Please cast your votes:
[ ] do not keep sources
[X] keep sources as separate zip files
but only in this special case, otherwise don't keep the sources.
[ ] keep sources in jar files
Stephan.
Am Mo, den 28.06.2004 schrieb Bart Molenkamp um 14:23:
Hi,
I want to use JavaFlow for writing my application flow. But I've got a
problem; it isn't working with Tomcat, I'm getting a black page (view
source also shows that there is really nothing). However, it is working
with Jetty (both
Am Mo, den 28.06.2004 schrieb Bart Molenkamp um 16:25:
Hello,
I want to lookup a component in a JavaFlow class, but I get a BCEL
error. I get the following error:
org.apache.bcel.verifier.exc.StructuralCodeConstraintException:
Instruction GETSTATIC constraint violated: Class
Hi,
I want to share some news and information about the javaflow
development, in cases that someone want to step in. I want also prevent
a one-man show.
Okay, the theory behind the introduction of continuation within java
is plain simple. Store and restore stack and local variables in cases
of
Am Fr, den 11.06.2004 schrieb Stephan Coboos um 19:06:
Hello,
please have a look at the following java flow code:
...
public class TestFlow extends AbstractContinuable{
private boolean foo= false;
public void doTest() throws Exception {
while(true) {
On Sat, 5 Jun 2004, Gianugo Rabellino wrote:
On Jun 5, 2004, at 7:19 PM, Antonio Gallardo wrote:
Hi:
After 11 hours of work, the first implementation of a Groovy Flow
engine
for Cocoon is working on my hard drive.
Great work, Antonio! Perhaps you can send me a copy.
Cool! But.
Am Di, den 01.06.2004 schrieb Stephan Coboos um 20:23:
Hello,
I have a problem using Objects in JavaFlow before a while loop. Please
see my first posting [JavaFlow] java.lang.VerifyException. In my opinion
it can be a bug in the JavaFlow block.
Because my fist posting was not so clear,
Am Do, den 03.06.2004 schrieb Stephan Michels um 15:00:
Am Di, den 01.06.2004 schrieb Stephan Coboos um 20:23:
Hello,
I have a problem using Objects in JavaFlow before a while loop. Please
see my first posting [JavaFlow] java.lang.VerifyException. In my opinion
it can be a bug
Am Mi, den 28.04.2004 schrieb Dave Brondsema um 2:18:
I'm a forrest developer and the attached patches fix the following for parsing
.cwiki files:
* handle nested bulletlists like nested numberedlists are
Can you also provide a snippet for selftest.txt to test the changes?
* use the file
Am Do, den 29.04.2004 schrieb [EMAIL PROTECTED] um 15:17:
Stefano and Bruno,
thanks for the explanation. I'm probably more of a hobby programmer for
not knowing the details on class loaders. :-( More study to do then.
Reading your explanation I agree that it sounds obvious that there
- message key=datatype.conversion-failedKeine gültige {0}./message
+ message key=datatype.conversion-failedUnültige(s) {0}./message
Unültige ?!
Stephan.
Am Mi, den 14.04.2004 schrieb Peter Mortier um 17:19:
Hello,
I'm trying out the new Java continuations stuff seperately from Cocoon.
However, I have run into a problem. The instrumented bytecode throws a
ClassCastException In the case where I am trying to resume a Continuation
from a
Am Fr, den 16.04.2004 schrieb Ugo Cei um 0:02:
In order to move forward, I propose to reparent the
org.apache.cocoon.ProcessingException to extend
org.apache.avalon.framework.CascadingRuntimeException instead of
CascadingException.
So, please cast your votes.
+1
Stephan.
Am Mi, den 14.04.2004 schrieb Guido Casper um 9:08:
Stephan Michels wrote:
The Repository IFs seems be more helper classes than components. And I
think we should using the Source objects instead to reflect all aspects
like locking, property handling etc.
Care to elaborate why do you
Am Di, den 13.04.2004 schrieb Ugo Cei um 21:54:
So, I'd like to make a proposal:
- use unchecked exceptions *by default* unless there's a good reason
otherwise, not just because that's the way it's always been done.
- wrap exceptions thrown by 3rd party packages (e.g.
Am Mi, den 14.04.2004 schrieb Mats Norén um 10:08:
Hi,
I've been following the discussions on both the repository API and the
Slide Source and I have a few questions to consider.
The Source IF is an abstraction layer but not a particularly good one in
this context.
I agree that the Slide
Am Mi, den 14.04.2004 schrieb Unico Hommes um 12:09:
From: Stephan Michels [mailto:[EMAIL PROTECTED]
The Repository IFs seems be more helper classes than components. And I
think we should using the Source objects instead to reflect
all aspects
like locking, property handling etc
Am Mi, den 14.04.2004 schrieb Guido Casper um 15:21:
Stephan Michels wrote:
The current webdav methods are:
... SUBSCRIBE UNSUBSCRIBE
POLL EVENT TRANSACTION ...
Where do these come from? They are not webdav methods.
Okay okay ;-) Not methods of the specs but of Slide, see
jakarta
Hi,
I currently think about the Slide/WebDAV access layer, since I
need it for my next project. The access to the Slide repository was my
first approach in the past, and perhaps not the best. The Slide API is
some parts very beautiful, but not intended to be used outside of Slide.
Nevertheless
of the WebDAVSource? It seems that it doesn't implement
any versioning. Or am I wrong?
Do you have plan to do something in this direction?
I currently think about to implement a system ontop of it.
Stephan Michels.
Am Do, den 08.04.2004 schrieb Guido Casper um 20:18:
Stephan Michels wrote:
What the status of the WebDAVSource? It seems that it doesn't implement
any versioning. Or am I wrong?
No. I (vaguely) remember some discussion considering your
VersionableSource vs. Sylvain's VersionedSource
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 22:44:
Why don't use (Object obj, Method method, Object[] args) in the
constructor of the continuation object.
That's a possible alternative, but makes prevents making Continuation an
abstract class.
Why should the continuation be
Am Di, den 06.04.2004 schrieb Antonio Gallardo um 13:12:
Hi:
Stephan Michels dijo:
Uhmm, yes, you know that you CP the uri of an POST request? So in this
case all request parameters get lost, and you got a
NullPointerException.
Yes it can look weird the idea of CP this URI
Am Di, den 06.04.2004 schrieb Bruno Dumon um 14:49:
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the browser is a stupid client
Am So, den 04.04.2004 schrieb Christopher Oliver um 20:32:
Stefano Mazzocchi wrote:
Next I would like to see is a groovy implementation of flow ;-)
It should be _fairly_ straightforward. The only tricky part I see is
controlling the byte-code transformation. All methods in the call-chain
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 4:42:
The current implementation needs some work to qualify as generalized
Java continuations. It would be nice to make it work more like Scheme
continuations:
1) When you access the current continuation, it captures the call
stack up
}
Continuation.SUICIDE.invoke(null); ?
*you see many question marks over my head*
I hope you have patience with me :)
Stephan Michels.
Am Do, den 01.04.2004 schrieb Carsten Ziegeler um 9:02:
Torsten Curdt wrote:
Is the block disabled by default?
no not yet ...would you prefer this
also for the dev version or only for
the release?
I personally would prefer to disable it already for
the dev version as many users
Am Do, den 01.04.2004 schrieb Joerg Heinicke um 14:39:
So now the vote:
[ ] exclude.block.blockname=true|false
[+1] include.block.blockname=true|false
Stephan.
Am Di, den 30.03.2004 schrieb Stephan Michels um 13:14:
Am Mo, den 29.03.2004 schrieb Antonio Gallardo um 23:38:
Stephan Michels dijo:
I rewrote the example now. I'm really not a OJB expert, nor a database
expert.
I made this example to learn more about OJB and JDO, and I didn't get
Am Di, den 30.03.2004 schrieb Marc Portier um 10:32:
my argumentation is primarily short-term/pragmatic:
starting at two observations:
1/ this is cool stuff and as far as I can see the reactions just about
everyone here is salivating and wants to interact with that code
Yes, seems so. And
Am Mo, den 29.03.2004 schrieb Carsten Ziegeler um 16:18:
I really value all the work and effort that you all put into this,
but I would say:
[X] nah... put it somewhere else
We only want to have one flow implementation (language), which is
Javascript. If we put the Java version as a
JMX client.
At the moment, most people see cocoon in the core of all beings. But to
be true, Cocoon is only a servlet, and should not include all business
logic.
My 2 cents, Stephan Michels.
Am Mo, den 29.03.2004 schrieb Sylvain Wallez um 19:05:
jflow isn't good as it doesn't allow the distinction between JS and Java.
Okay, seems that we agree on javaflow.
Now what should go in that block: the _flow_ implementations, or the
class enhancer? I would stay that only the flow
opinion.
Please accept my apology, Stephan Michels.
Am Mo, den 29.03.2004 schrieb Torsten Curdt um 15:30:
Dear friends and folks,
as already announce on the PMC list we now
have another flow implementation for java!
Stephan completed my proof-of-concept and
replaced the Brakes stuff by an own
implementation. So we are now fully in
ASL
Am Mo, den 29.03.2004 schrieb Joerg Heinicke um 20:32:
On 29.03.2004 15:30, Torsten Curdt wrote:
[x] jflow
[ ] javaflow
[ ]
[ ] nah... put it somewhere else
Hmm, 4h for a vote was a bit short, wasn't it? So just for the records:
I'm with Antonio and so like JFlow vs.
Am Mo, den 29.03.2004 schrieb Reinhard Pötz um 21:17:
I tried out the new examples but I got the error below. I use eclipse to
build Cocoon which compiles the classes into WEB-INF/classes.
Any ideas?
org.apache.bcel.verifier.exc.StructuralCodeConstraintException: Instruction
INVOKESTATIC
Am Mo, den 29.03.2004 schrieb Gianugo Rabellino um 21:46:
Joerg Heinicke wrote:
On 29.03.2004 19:47, [EMAIL PROTECTED] wrote:
Remove the bcel classes from the xalan.jar and
create an extra jar for those.
*Ouch*. If I understand this correctly we have to do it for every
Am Mo, den 29.03.2004 schrieb Gianugo Rabellino um 22:10:
Reinhard Pötz wrote:
I tried out the new examples but I got the error below. I use eclipse to
build Cocoon which compiles the classes into WEB-INF/classes.
Any ideas?
. For example you could also use Groovy to implement your
flow, because Groovy also produces Java classes.
I done a lot of afford to make it work like the javascript
implementation. So that it is only a choise, which language you
prefer.
But I'm curious about our opinions, Stephan Michels.
Am Di, den 23.03.2004 schrieb Joerg Heinicke um 20:37:
On 23.03.2004 20:23, [EMAIL PROTECTED] wrote:
stephan 2004/03/23 11:23:07
Modified:tools/src blocks-build.xsl
Log:
Allow to share codebase to other blocks.
pathelement
Am Mi, den 17.03.2004 schrieb Carsten Ziegeler um 14:07:
Hi,
it seems that the latest CVS does not sort the list of the block
samples in alphabetic order. This now looks a little bit confusing.
Any idea how to fix this?
The patches are applied in order of the dependencies of the blocks. A
commit: cocoon-2.1/tools/src/anttasks
XConfToolTask.java
On 12.03.2004 14:29, Stephan Michels wrote:
In the orginal form of the blocks-build.xsl, we had
separate targets
for the patch files. But it was incredible slow. Then I merge these
targets to one target, and rewrote
Am Fr, den 12.03.2004 schrieb Bertrand Delacretaz um 07:47:
Sounds like the way to go, intelligently downloading dependencies from
some non-ASF repository should solve most, maybe all of the licensing
problems, and help make Cocoon more lightweight for many uses.
IIRC last time this was
Am Fr, den 12.03.2004 schrieb Carsten Ziegeler um 08:25:
Stephan Michels wrote
Ehm, are you sure that this works? The xconf's from the different
blocks have to be applied in the correct order (in the
order of their
dependencies). If you all apply at once this is imho
Am Fr, den 12.03.2004 schrieb Joerg Heinicke um 13:30:
On 12.03.2004 13:01, Carsten Ziegeler wrote:
I thought that previously all xpatches for all blocks were
executed in one go instead of separately and respecting
dependency order.
No, one patch after the other was applied
Hi,
some samples require the ExtendedResourceExistsAction. Where went
this action?
Marged with ResourceExistsAction?
Thanks, Stephan.
Am Do, den 11.03.2004 schrieb Carsten Ziegeler um 16:48:
[EMAIL PROTECTED] wrote:
Modified:tools/src blocks-build.xsl
Log:
Apply all xconf file in one shoot.
Ehm, are you sure that this works? The xconf's from the different
blocks have to be applied in the correct order
Am Do, den 11.03.2004 schrieb leo leonid um 18:24:
Hi,
I just updated my projects from woody to cocoon forms (absolutely
painless, BTW).
I see it similar, a simple s/woody/forms/g, and most of the work is
done. I doesn't see a real need to keep the woody block, but anyway...
Am Mi, den 10.03.2004 schrieb Unico Hommes um 19:24:
There remain a few issues that need resolving.
- InputModuleAction had to move along with xsp because it has a
dependency on some xsp helper class. This is unfortunate and maybe
unnecessary. Perhaps someone with more knowledge about this
Am Di, den 09.03.2004 schrieb Sylvain Wallez um 16:27:
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit :
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of
Am Di, den 09.03.2004 schrieb Bertrand Delacretaz um 16:37:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+0.5 (=good idea, won't be able to help)
I can offer some help, if nobody on it, then I can try it?!
Stephan.
I think here goes something wrong ;-)
Am Mi, den 10.03.2004 schrieb [EMAIL PROTECTED] um 10:48:
1.2 +48 -33cocoon-2.2/src/resources/dev/i18n/simple_dict.xml
Index: simple_dict.xml
===
RCS file:
Am Mi, den 10.03.2004 schrieb Joerg Heinicke um 12:41:
On 10.03.2004 10:36, [EMAIL PROTECTED] wrote:
Modified:tools/src blocks-build.xsl
...
Using one classpath for all blocks instead of one classpath for each block.
Any particular reason for this? I thought this was already
Am Mi, den 10.03.2004 schrieb Reinhard Pötz um 11:03:
Stephan Michels wrote:
Am Di, den 09.03.2004 schrieb Bertrand Delacretaz um 16:37:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+0.5 (=good idea, won't be able to help)
I
Am Mi, den 10.03.2004 schrieb Carsten Ziegeler um 14:24:
I have following problem, that
src/blocks/session-fw/conf/xsp-session-fw.xconf
depends on the xsp block, but won't be executed before the
patch files
of the xsp block :-/
This may require a change to the build
generating, generation, what the . Its all the same ;-) Thanks.
Am Mi, den 10.03.2004 schrieb [EMAIL PROTECTED] um 16:20:
unico 2004/03/10 07:20:54
Added: src/blocks/xsp/java/org/apache/cocoon/generation
AbstractServerPage.java
Am Di, den 09.03.2004 schrieb Unico Hommes um 16:39:
Reinhard Pötz wrote:
Stefano Mazzocchi wrote:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+1
Big +1
Stephan Michels.
Am Mo, den 08.03.2004 schrieb Steven Noels um 10:11:
On 08 Mar 2004, at 09:39, Reinhard Pötz wrote:
IIRC the argumentation was that Cocoon is about web publishing and web
applications and not about programming language interpreters. So it
should find a different place.
Exactly.
Am Fr, den 27.02.2004 schrieb Tim Larson um 16:25:
On Fri, Feb 27, 2004 at 11:33:32AM +0100, Dirk-Willem van Gulik wrote:
On Feb 27, 2004, at 12:45 AM, Conal Tuohy wrote:
I don't think the ASF should discourage developers from keeping useful
metadata about the code inside the source
Hi,
exists there possibility to call flow function inside of a transformer?
I only found
void Interpreter.callFunction(String, List, Environment)
First, the method returns no result. And second I must pass the
environment, which is harmful for the current process.
I can skip the second problem
Am Di, den 10.02.2004 schrieb Sylvain Wallez um 11:30:
Found a very interesting read at
http://www-106.ibm.com/developerworks/library/j-jtp01274.html?ca=drs-j0504
This articles explains the memory allocation and collection strategies
of modern JVM and show that object recycling and pooling
Am Fr, den 06.02.2004 schrieb Nicola Ken Barozzi um 15:07:
I tested it again, and -hold on- your example works as expected.
The code part is:
boolean didThisWork() {
return !failed();
}
And in the document (not well formet, the top element is missing, but it
Am Mo, den 02.02.2004 schrieb Nicola Ken Barozzi um 12:11:
Stephan Michels wrote:
On Fri, 23 Jan 2004, Nicola Ken Barozzi wrote:
How come with the wiki stuff with
{{{
source
code
}}}
I get this output:
pre
source
code
/pre
Any way to not make double linefeeds appear
On Fri, 23 Jan 2004, Nicola Ken Barozzi wrote:
How come with the wiki stuff with
{{{
source
code
}}}
I get this output:
pre
source
code
/pre
Any way to not make double linefeeds appear?
Hmm, where does this behaviour occur? Windows?
Are these double lfs also in the written
public final Map act(String type, String source, Parameters parameters)
throws AbstractCompositeTestException {
if (resolver == null) {
throw new AbstractCompositeTestException(Lookup of source
resolver failed);
}
}
You don't need to
Am Do, den 22.01.2004 schrieb Nicola Ken Barozzi um 16:45:
Stephan Michels wrote:
...
3 - the error reporting is nice, but for Forrest I need that all
errors go through the handle-errors, so that it gets actually
counted as such. ATM it seems that usual errors are handled
Am Do, den 22.01.2004 schrieb Nicola Ken Barozzi um 18:12:
Anyway, I move the handle-errors in the main sitemap, and there it gets
called. It even selects the map:when test=syntax, because if I put
in there a simple notifier I get the report.
But putting in there even only
On 11 Dec 2003 [EMAIL PROTECTED] wrote:
sylvain 2003/12/11 10:19:05
Modified:lib jars.xml
Removed: lib/core excalibur-component-20031126.jar
excalibur-store-1.0-dev.jar
Log:
New versions of:
- store: separate ROLE and TRANSIENT_ROLE,
On Fri, 12 Dec 2003, Sylvain Wallez wrote:
Stephan Michels wrote:
On 11 Dec 2003 [EMAIL PROTECTED] wrote:
sylvain 2003/12/11 10:19:05
Modified:lib jars.xml
Removed: lib/core excalibur-component-20031126.jar
excalibur-store-1.0-dev.jar
On Fri, 12 Dec 2003, bernhard huber wrote:
hi,
-libcore/excalibur-component-20031126.jar/lib
+libcore/excalibur-component-20031211.jar/lib
If you have access to the excalibur repository, can please
add the patch from
On 10 Dec 2003, David Crossley wrote:
Stephan Michels wrote:
after I made some positive experiences with jalopy, an open source
code formatter, I want to offer install jalopy with a proposal
for the our code convention.
What do you mean by install? In our CVS? Or does each committer
Hi,
after I made some positive experiences with jalopy, an open source
code formatter, I want to offer install jalopy with a proposal
for the our code convention.
This should be a welcome alternative to the various 'organize imports'
and 'dos2unix' etc.
What do'ya think?
Stephan Michels.
Hi,
I have following problem that I want to aggregate a document
with a help of a internal pipeline.
ci:inlcude src=cocoon:/internal/doc.xml/
But this internal pipeline can throw an exception, which
should be handled by an handle-errors section, and the produced
output should be included into
On Wed, 26 Nov 2003, Joerg Heinicke wrote:
[EMAIL PROTECTED] wrote:
stephan 2003/11/26 04:55:06
Modified:lib/core excalibur-component-1.2-dev.jar
But the naming is really bad as you can no longer get the recent sources for
this package. Please get back to dated package names
On Mon, 3 Nov 2003, Antonio Gallardo wrote:
peter royal dijo:
On Nov 3, 2003, at 4:33 PM, Berin Loritsch wrote:
Anyhoo, the basic solution is to either build a tree/graph of pure
components
or a tree/graph of pure beans. Either solution will work. We need to
get rid
of the need
On Sun, 2 Nov 2003, Stefano Mazzocchi wrote:
On Sunday, Nov 2, 2003, at 15:57 Europe/Rome, Vadim Gritsenko wrote:
Stephan Michels wrote:
On Sun, 2 Nov 2003, Stefano Mazzocchi wrote:
On Saturday, Nov 1, 2003, at 23:29 Europe/Rome, Steve K wrote:
And finally, on a somewhat
On Sun, 2 Nov 2003, Stefano Mazzocchi wrote:
On Saturday, Nov 1, 2003, at 23:29 Europe/Rome, Steve K wrote:
And finally, on a somewhat unrelated subject, one thing that I've
always wanted Cocoon to do may be possible if support for collecting
the XML at each pipeline step is added. To
On Fri, 10 Oct 2003, Stefano Mazzocchi wrote:
On Friday, Oct 10, 2003, at 13:22 Europe/Rome, Stephan Michels wrote:
To prevent component name collisions within, we could use prefixes like
match type=basic:wildcard pattern=*.html
map:generate type=basic:file src={1}.xml
Puh, finally arrived at home. I took some days to visit the belgium
coast.
The name 'modifiers' comes from the java grammar, and include more
than private and public. But if we talking only about accessibility,
then @access is ok.
On Thu, 9 Oct 2003, Sylvain Wallez wrote:
Geoff Howard wrote:
On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
Stefano Mazzocchi wrote:
I have updated the block design documents on the wiki. Changes were:
...
A few things are left to decide:
1) the block metadata
On Thu, 9 Oct 2003, Sylvain Wallez wrote:
Stephan Michels wrote:
On Tue, 7 Oct 2003, Sylvain Wallez wrote:
AFAIU, the use of JXTemplate as a generator allows the template to be
pre-analyzed and stored into the cache, thus allowing a greater
performance. This cannot be achieved
]
___
Stephan Michels EMail: [EMAIL PROTECTED]
ICQ: 115535699Tel: +49-030-314-21583
+|+|+|+|+|+|+|-|
On Fri, 10 Oct 2003, Stefano Mazzocchi wrote:
On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote:
Exposing classes
Stephen proposed to separate the classes to expose in a different
jar
and expose that. I like this. It's simple and effective
.
___
Stephan Michels EMail: [EMAIL PROTECTED]
ICQ: 115535699Tel: +49-030-314-21583
+|+|+|+|+|+|+|-|
, Stephan.
___
Stephan Michels EMail: [EMAIL PROTECTED]
ICQ: 115535699Tel: +49-030-314-21583
+|+|+|+|+|+|+|-|
On Tue, 7 Oct 2003, Sylvain Wallez wrote:
Stephan Michels wrote:
Just another thought,
I noticed that the JXTemplateGenerator/Transformer implements both
contracts: generator and transformer. It should be easier to
implements this component as transformer, and offer this transformer
On Tue, 26 Aug 2003, Gianugo Rabellino wrote:
A source property (both in webdav sense and in the SourceProperty
implementation) is made of three part: a local name (String), a
namespace (String) and a value (DOM Element). It's worth noticing that
the property value is actually the *holder
On Mon, 4 Aug 2003, Mark Leicester wrote:
On 4/08/2003 15:15, Stephan Michels [EMAIL PROTECTED] wrote:
Have you take a look into
src/test/org/apache/cocoon/AbstractCompositeTestCase.java
Heh, no I haven't seen this at all! Cool! Wow, this is the real thing! Is
this quite new? I looked
On Wed, 6 Aug 2003, Bertrand Delacretaz wrote:
...I think the logical (and annoying) question now is: couldn't
chaperon be
used?
Most probably, but after looking at (and doing some work on) the wiki
grammar of Chaperon I have a feeling that Chaperon isn't ideal for
semi-structured
On Tue, 12 Aug 2003, Jeremy Quinn wrote:
On Tuesday, August 12, 2003, at 12:36 PM, Bertrand Delacretaz wrote:
Le Mardi, 12 aoû 2003, à 12:09 Europe/Zurich, Jeremy Quinn a écrit :
Does anyone know if there is an equivalent to the javadoc tool for
JavaScript files?
Did you try the
On Tue, 5 Aug 2003, Mark Leicester wrote:
Thank you for pointing me to your Cocoon unit testing framework[1] Stephan!
I got a unit test for my MIDIGenerator going very quickly, and it *is* very
easy to use. I was able to configure the .xtest file without too much
trouble. Your testing
On Mon, 4 Aug 2003, Mark Leicester wrote:
Hi,
I'd like to get your comments on the approach to Unit testing I have used in
developing my Cocoon components. I think that this approach can be extended
to provide unit tests for all Cocoon components - and I'd like to help write
these. For
On Fri, 1 Aug 2003, Sylvain Wallez wrote:
Gianugo Rabellino wrote:
Before the upcoming release, I'd like to promote the
TraversableGenerator stuff to the main trunk. There are several things
to discuss, though:
1. naming. TraversableGenerator sucks, yes. I guess the best option as
On Fri, 1 Aug 2003, Guido Casper wrote:
Stephan Michels wrote:
At least, we should agree on one name
SourceHierarchyGenerator - http://apache.org/cocoon/hierachy/1.0
SourceCollectionGenerator - http://apache.org/cocoon/collection/1.0
SourceDirectoryGenerator - http://apache.org
1 - 100 of 113 matches
Mail list logo
