bruno 2003/06/30 06:25:28
Modified:src/blocks/woody/java/org/apache/cocoon/woody
FormContext.java
src/blocks/woody/java/org/apache/cocoon/woody/acting
HandleFormSubmitAction.java
src/blocks/woody/java/org
bruno 2003/06/30 07:16:02
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
AggregateField.java
Log:
Fixed getValue() method
Revision ChangesPath
1.3 +22 -5
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody
bruno 2003/06/27 05:43:32
Modified:src/blocks/woody/java/org/apache/cocoon/woody/samples
Form1Handler.java
Added: src/blocks/woody/java/org/apache/cocoon/woody/event
RepeaterHandler.java
Log:
Moved common repeater handling
bruno 2003/06/27 06:01:47
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
AggregateField.java
Log:
Indicate required status in generated SAX.
Revision ChangesPath
1.2 +1 -0
cocoon-2.1/src/blocks/woody/java/org/apache
bruno 2003/06/26 02:09:11
Modified:lib jars.xml
.gump.xml
Added: src/blocks/woody/lib jakarta-oro-2.0.7.jar
Log:
Added jakarta-oro dependency to woody block
Revision ChangesPath
1.52 +11 -1 cocoon-2.1/lib/jars.xml
Index
bruno 2003/06/26 02:09:59
Added:
src/blocks/woody/java/org/apache/cocoon/woody/datatype/validationruleimpl
Mod10ValidationRule.java
Mod10ValidationRuleBuilder.java
src/blocks/woody/java/org/apache/cocoon/woody/formmodel
bruno 2003/06/26 02:11:24
Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype
ValidationRule.java
src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl
AbstractDatatypeBuilder.java
src
bruno 2003/06/26 02:12:12
Modified:src/blocks/woody/java/org/apache/cocoon/woody/util
DomHelper.java
Log:
Added a few methods to get child elements
Revision ChangesPath
1.3 +29 -0
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon
bruno 2003/06/26 02:13:14
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
AbstractWidgetDefinitionBuilder.java
Log:
fetch expressionmanager from the component manager
Revision ChangesPath
1.2 +3 -0
cocoon-2.1/src
bruno 2003/06/26 02:14:33
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
ExpressionContextImpl.java
Log:
Added new constructor
Revision ChangesPath
1.2 +16 -1
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody
bruno 2003/06/26 02:15:05
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
Repeater.java
Log:
Make addRow return the new row
Revision ChangesPath
1.4 +4 -2
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody
bruno 2003/06/26 02:15:32
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
Field.java
Log:
Added getValidationError method
Revision ChangesPath
1.4 +8 -0
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody
bruno 2003/06/26 02:15:58
Modified:src/blocks/woody/java/org/apache/cocoon/woody
FormManager.java
Log:
javadoc correction
Revision ChangesPath
1.4 +1 -1
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/FormManager.java
bruno 2003/06/26 02:17:37
Modified:src/blocks/woody/java/org/apache/cocoon/woody/samples
Form1Handler.java
Log:
Use proper way to access a widget in a row.
Revision ChangesPath
1.2 +1 -1
cocoon-2.1/src/blocks/woody/java/org/apache
bruno 2003/06/26 02:18:41
Modified:src/blocks/woody/samples/forms form1.xml form1_template.xml
Log:
Added aggregatefield sample
Revision ChangesPath
1.4 +33 -0 cocoon-2.1/src/blocks/woody/samples/forms/form1.xml
Index: form1.xml
bruno 2003/06/26 02:19:01
Modified:src/blocks/woody/samples/messages WoodyMessages.xml
Log:
Added a few new messages
Revision ChangesPath
1.3 +4 -0 cocoon-2.1/src/blocks/woody/samples/messages/WoodyMessages.xml
Index: WoodyMessages.xml
bruno 2003/06/26 02:19:29
Modified:src/blocks/woody/samples/xsl/html woody-default.xsl
Log:
Added template to format aggregatefield widget
Revision ChangesPath
1.4 +13 -0 cocoon-2.1/src/blocks/woody/samples/xsl/html/woody-default.xsl
Index: woody
bruno 2003/06/26 02:20:59
Modified:src/blocks/woody/conf woody.xconf
Log:
Added aggregatefield and mod10 validation rule declarations
Revision ChangesPath
1.3 +2 -0 cocoon-2.1/src/blocks/woody/conf/woody.xconf
Index: woody.xconf
bruno 2003/06/26 08:34:40
Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl
AbstractDatatypeBuilder.java
Log:
Added support for dynamic (non-cached) selection lists
Revision ChangesPath
1.3 +13 -3
cocoon-2.1/src
bruno 2003/06/15 09:15:20
Modified:lib jars.xml
Added: lib/core excalibur-sourceresolve-20030615.jar
Removed: lib/core excalibur-sourceresolve-20030610.jar
Log:
Upgraded sourceresolve
Revision ChangesPath
1.48 +2 -2 cocoon-2.1/lib/jars.xml
recursive
call anymore. If you spot any more problems, just give a yell.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
next week).
Thanks for spotting this!
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
On Tue, 2003-06-10 at 15:13, Berin Loritsch wrote:
Bruno, did you introduce a test where the behavior was
occuring? It would be really be useful to ensure the
recursion does not accidentally get reintroduced.
Good point -- but given Volker comments, I'll first look into
redesigning
the regexp only on the part before the '?' (BTW, if '?'
is part of the URI, it should be encoded as %3F
That's what I tried to propose :)
(Just now awakening)
Is this the cause of the infinite loop, or is that still a seperate
problem?
--
Bruno Dumon http
On Tue, 2003-06-10 at 11:01, Carsten Ziegeler wrote:
Bruno Dumon wrote:
On Tue, 2003-06-10 at 10:02, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
What about using the two ;-)
1/ test if the URI is absolute. For this, you can use Excalibur's
SourceUtil.getScheme() which
bruno 2003/06/10 02:43:19
Modified:lib jars.xml
Added: lib/core excalibur-sourceresolve-20030610.jar
Removed: lib/core excalibur-sourceresolve-20030607.jar
Log:
Updated excalibur-sourceresolve
Revision ChangesPath
1.47 +2 -2 cocoon-2.1/lib
On Tue, 2003-06-10 at 11:16, Carsten Ziegeler wrote:
Bruno Dumon wrote:
Yep, after trying it out I saw it too.
Anybody working on this already? (or can I do it?)
No, I'm not :) so: go for it ;)
done :-)
--
Bruno Dumon http://outerthought.org
(AbstractEnvironment.java:467)
at
org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvironment.java:457)
[...]
Line 467 in AbstractEnvironment.java is somewhere in the middle of a
javadoc. Are you using a modified version of AbstractEnvironment (or
maybe a sticky cvs tag) ?
--
Bruno Dumon
highlighted here are also the cause of bug
20084.
If you have some time, could you compare the current behaviour with that
of xalan 2.5 and 2.4.1, to see if this got worse recently?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML
bruno 2003/06/07 14:15:27
Modified:lib jars.xml
Added: lib/core excalibur-sourceresolve-20030607.jar
Removed: lib/core excalibur-sourceresolve-1.0.jar
Log:
Upgraded excalibur-sourceresolve
Revision ChangesPath
1.1 cocoon-2.1/lib/core
bruno 2003/06/07 14:16:10
Modified:src/java/org/apache/cocoon/xml XMLBaseSupport.java
Log:
Refactored to use SourceResolver instead of java.net.URL to resolve paths.
Revision ChangesPath
1.2 +48 -38cocoon-2.1/src/java/org/apache/cocoon/xml/XMLBaseSupport.java
bruno 2003/06/07 14:19:36
Modified:src/java/org/apache/cocoon/components/source/impl
SitemapSourceFactory.java ContextSourceFactory.java
Log:
Implemented URIAbsolutizer interface
Revision ChangesPath
1.2 +9 -3
cocoon-2.1/src/java/org
bruno 2003/06/07 14:20:14
Modified:src/webapp/samples/xinclude samples.xml sitemap.xmap
Added: src/webapp/samples/xinclude/content xmlbase.xml
Log:
Added xml:base sample.
Revision ChangesPath
1.2 +1 -0 cocoon-2.1/src/webapp/samples/xinclude
with xalan.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
, you'll never now why (when using the TemplatesHandler like
we do). If you apply the following patch against xalan you should see
the original exception:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20114
--
Bruno Dumon http://outerthought.org/
Outerthought - Open
-not-found
fallbacks?
The above would still not cover the needs of Fernando. I think we would
rather need a concept of metabundles which are the combination of
multiple bundles that are searched in the order as described by
Fernando.
--
Bruno Dumon http://outerthought.org
bruno 2003/06/04 12:29:07
Modified:src/java/org/apache/cocoon Main.java
Log:
CocoonBean = Constants, build was failing on this
Revision ChangesPath
1.4 +2 -2 cocoon-2.1/src/java/org/apache/cocoon/Main.java
Index: Main.java
bruno 2003/06/04 12:36:43
Modified:lib jars.xml
.status.xml
Added: lib/endorsed xalan-2.5.1.jar
Removed: lib/endorsed xalan-20030506.jar
Log:
Upgraded to Xalan 2.5.1
Revision ChangesPath
1.1 cocoon-2.1/lib
the htmlserializer, but it provides some features that can be
useful in some cases (mainly validation and beautifying).
FWIW, I'm +1 on adding the tidyserializer.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL
On Tue, 2003-06-03 at 15:28, Torsten Knodt wrote:
On Tuesday 03 June 2003 09:38, Bruno Dumon wrote:
BD TK We have a current problem, that cocoon is not useable in many cases,
BD TK because it's nearly impossible to create valid (x)html.
BD And again I'm wondering why? Of the tree reasons
should lower it to warn instead?
(there are other components also logging deprecation warnings not
visible by default)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED
did. If you integrate this in a test
system you can validate your pages automatically.
The above two reasons still make it valuable, even if only for debugging
purposes? I think that if we make this purpose clear in the
documentation, then there's no problem.
--
Bruno Dumon
On Tue, 2003-06-03 at 22:19, Torsten Knodt wrote:
On Tuesday 03 June 2003 21:46, Bruno Dumon wrote:
BD yeah yeah, I agree with that, and for that purpose the tidyserializer is
BD very valuable. I was only wondering if there were any blocking bugs in
BD the normal htmlserializer that make
damn i-mode browsers won't take code that isn't aligned to the
left (aargh?!).
Bruno?
You expect me to give my blessing or so? I don't really care that much
about it all. Arguments 2 and 3 are reasonable, and certainly have their
uses.
What I wanted to avoid though is that problems
this a false comparison (we don't control webpages, but
we do control what we generate in our pipelines), please understand that
I'm not opposed to a tidyserializer. I'm just figuring out why I would
use it.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source
bruno 2003/06/03 00:50:34
Modified:.status.xml
Log:
mention fixing of bug 14327
Revision ChangesPath
1.49 +5 -0 cocoon-2.1/status.xml
Index: status.xml
===
RCS file: /home/cvs
bruno 2003/06/03 00:53:31
Modified:.changes.xml
Log:
mention fixing of bug 14327
Revision ChangesPath
1.17 +6 -1 cocoon-2.0/changes.xml
Index: changes.xml
===
RCS file: /home/cvs
On Mon, 2003-06-02 at 12:57, Arjé Cahn wrote:
Bruno says:
What exactly is the purpose of a tidy serializer again?
I was fiddling around with Tidy and noticed that I couldn't get the
textarea/ problem solved with it.
[The textarea/ problem: an empty textarea (formtextarea//div
bruno 2003/05/30 08:28:43
Modified:src/java/org/apache/cocoon/components/jsp JSPEngineImpl.java
Log:
cleanup
Revision ChangesPath
1.4 +2 -4
cocoon-2.0/src/java/org/apache/cocoon/components/jsp/JSPEngineImpl.java
Index: JSPEngineImpl.java
bruno 2003/05/30 08:31:58
Modified:src/blocks/jsp/java/org/apache/cocoon/components/jsp
JSPEngineImpl.java
Log:
cleanup
Revision ChangesPath
1.4 +2 -4
cocoon-2.1/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImpl.java
, this does not make us avalon
committers and does not give us voting rights. We are also not supposed
to touch things we have no business with.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED
.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
document.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
On Wed, 2003-04-02 at 05:32, ivelin wrote:
Bruno,
It is funny enough that it's April 1, but your email reminds me about the
one Torsten sent out about a year ago, not on April 1 ;)
http://www.mail-archive.com/[EMAIL PROTECTED]/msg14370.html
Maybe in spirit, but not in concrete ideas (see
-term plan is to migrate to JSF,
which has its own validation system, and doesn't have the concept of
form beans.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL
are as of yet only ideas, there's no code yet, but once it
gets this far I'd like to add it as a block to Cocoon CVS.
Thoughts?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED
On Tue, 2003-04-01 at 16:34, Andrew Savory wrote:
Hi Bruno,
On Tue, 1 Apr 2003, Bruno Dumon wrote:
It should be possible to create a form just by describing its structure
in an XML file (lets call this a form description). I don't like the
fact that for XMLForm/Struts the user needs
seperate issues for me, so that's
not really a problem.
But maybe we can steel at least some
ideas for something new?!
Yep, I'll certainly take a more detailed look into it.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence
to the rest tomorrow ...]
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
of the chaperon parser?
AFAIU wikis don't have a concept of invalid syntax so parsing should
never fail.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
admin -kkv thefile
cvs update -A thefile
and on non-unix platforms, possibly correct and recommit the file.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
not using Jdk14Logger (average over 1000 requests:
28 ms vs 81 ms).
I've submitted a patch to commons bugzilla (nr 18184) to address this.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED
are straightforward to port.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
On Tue, 2003-03-18 at 16:25, Unico Hommes wrote:
[...]
For
instance the method setContentHandler seems to have been removed
completely.
re-added in CVS (both 2.0 and 2.1).
Thanks for reporting, and don't hesitate to report any further problems
you may have.
--
Bruno Dumon
in DOMStreamer so you can
get on with your work, just disable the following lines:
String pr1 = pr.equals() ? xmlns : pr;
String qn = pr.equals() ? xmlns : xmlns: + pr;
newAttrs.addAttribute(, pr1, qn, CDATA, ns);
--
Bruno Dumon http://outerthought.org/
Outerthought - Open
that
the decoding also uses UTF-8 by default.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
On Tue, 2003-03-11 at 09:15, Jeff Turner wrote:
On Tue, Mar 11, 2003 at 08:14:21AM +0100, Bruno Dumon wrote:
On Tue, 2003-03-11 at 07:37, Jeff Turner wrote:
Probably a question for Bruno..
The NamespaceNormalizingDOMStreamer doesn't support DOM 1 nodes, which
means that any code
Stefano's
experiments, this does not seem to work with the xhtml serializer)
* in the web.xml: set container-encoding to ISO-8859-1 (don't know why
its configurable because it should be ISO-8859-1 per spec), and set
form-encoding to the same encoding of the serializer.
--
Bruno Dumon
now? Thanks
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
On Tue, 2003-03-11 at 07:37, Jeff Turner wrote:
Probably a question for Bruno..
The NamespaceNormalizingDOMStreamer doesn't support DOM 1 nodes, which
means that any code using, say, 'setAttribute' instead of
'setAttributeNS' causes cryptic errors like:
Ah, didn't know that. I thought
On Fri, 2003-02-28 at 09:12, Carsten Ziegeler wrote:
Bruno Dumon wrote:
On Thu, 2003-02-27 at 22:14, Miles Egan wrote:
After updating cvs and rebuilding I get this error when using the
HTMLGenerator:
[NamespaceNormalizingDOMStreamer] Encountered a DOM Element without
bruno 2003/02/27 14:25:19
Modified:src/blocks/html/java/org/apache/cocoon/generation
HTMLGenerator.java
Log:
disable namespace normalization on DOMStreamer
Revision ChangesPath
1.5 +2 -1
xml-cocoon2/src/blocks/html/java/org/apache
bruno 2003/02/27 14:39:05
Modified:src/documentation/xdocs who.xml
Log:
Added myself (bruno) to active committers.
Revision ChangesPath
1.38 +1 -0 xml-cocoon2/src/documentation/xdocs/who.xml
Index: who.xml
the easiest solution for now is to use the default DOM streamer
in the HTMLGenerator. I'll fix that in a moment...
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED]
On Wed, 2003-02-26 at 08:07, Carsten Ziegeler wrote:
Great, Bruno!
This was exactly what I was thinking about after your comments
from monday - but you beat me :)
:-P
Now, what do you think of not creating an own streamer but
integrating it into the usual DOMStreamer - this would
for the positive votes.
--
Bruno
On Wed, 2003-02-26 at 16:58, Morrison, John wrote:
[...]
You're welcome. Will give this till tomorrow morning to let
other people express any opinions, then I'll email [EMAIL PROTECTED]
(anyone else?) and get you a username. Is bruno ok?
yes, that's fine.
--
Bruno Dumon
[EMAIL PROTECTED] ;-)
Thanks for the warning :-)
Then I'd take just bdu (though I still prefer bruno).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED]
logic in Xalan's serializer would be unnecessary
overhead for cases where it's not needed. Maybe we could make an
equivalent of the normalizeDocument method that works on a dom level 2
document and call that before serializing the document?
--
Bruno Dumon http
On Mon, 2003-02-24 at 13:01, Carsten Ziegeler wrote:
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: Monday, February 24, 2003 12:47 PM
To: [EMAIL PROTECTED]
Subject: RE: XML/HTML serializers buffering everything and using
threads.
On Mon, 2003-02-24
the namespace prefixes
from the qNames in startElement.
Sylvain (on ski vacation ;-)
leave some snow for me (it's my turn next week) ;-)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED]
in practical use,
this is not the case).
* finally (or better first of all), lets look if the serializer problems
cannot be solved in xalan.
Thoughts?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED]
, there's only one line added.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED]
Index: MirrorRecorder.java
===
RCS file: /home
of catalogues because then the catalogues are centrally managed, which
makes it more transparent from an administration point-of-view.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED
/
/map:transform
All this will cause some backward-incompatible changes (though maybe it
would be possible to support the old-style and new-style configuration
concurrently).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support
On Thu, 2003-02-13 at 12:53, Konstantin Piroumian wrote:
From: Bruno Dumon [EMAIL PROTECTED]
[...]
or maybe use namespaces:
input name=Submit value=dynamic i18n:attr=mybundle:name
other:value?
I think this will cause confusion with namespaced attributes.
How about this:
input
, and it would check them one by one until the value is
found.
A possible alternative would be that the bundle to be used is specified
explicitely when retrieving the key, e.g.
i18n:text bundle=mybundlekey/i18n:text
(and we'd also need a syntax for attributes)
Thoughts?
--
Bruno Dumon
On Wed, 2003-02-05 at 14:11, Ugo Cei wrote:
Bruno Dumon wrote:
Based on some code from the xReporter project, I created a new
transformer for Cocoon that can do grouping and summary calculation of
table-like data (such as the data that comes out of the SQLTransformer).
The grouping
. This
transformer works independent from xReporter.
Details and downloads are available here:
http://xreporter.cocoondev.org/subprojects/groupingtransformer.html
The transformer itself and the xReporter code on which it depends are
all released under Apache style licenses.
Enjoy,
Bruno
--
Bruno Dumon
On Wed, 2003-02-05 at 17:17, Hunsberger, Peter wrote:
Bruno Dumon wrote:
Based on some code from the xReporter project, I created a new
transformer for Cocoon that can do grouping and summary calculation
of table-like data (such as the data that comes out of the
SQLTransformer
:-)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email
once as a patch by
Bruno: http://outerthought.net/captor.html
well, there's a difference though. Captor is very useful in itself for
people wanting to understand pipelines, though its completely un-useful
if you're writing your own SAX-transformer which (during development)
might be quite buggy
.) ?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email
thought that only works inside the request-handling
thread, and I would need access to a SourceResolver for that)
- Does anyone see conceptual problems with making the Cocoon object (or
in fact the Processor interface) publicly available?
Thanks for any comments about this,
Bruno
--
Bruno Dumon
could do that. I'll check it out.
Thanks,
Bruno
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED]
-
To unsubscribe, e-mail
Hi,
attached you'll find a patch for the sitemapv05.rng grammar fixing the
following:
- map:select should be able to have map:parameter's
- map:action component declaration should allow any xml as content
Regards,
Bruno
--
Bruno Dumon http://outerthought.org
its own DOM impl.
Saxon can only work with its own dom implementation. Even if you set
xerces as parser, saxon will still build its own optimized dom tree
(but will use xerces as sax parser).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java
On Wed, 2002-11-27 at 22:10, Robert Koberg wrote:
Hi,
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 27, 2002 1:04 PM
It just means if you use Saxon, Saxon will use Aelfred (which is
bundled in the
Saxon jar) by default
, a reference to the cocoon
SourceResolver is passed, so I'm obliged here to use the deprecated
Source class.
Is this a known fact, a bug or am I missing something?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL
On Fri, 2002-08-30 at 16:45, William Brogden wrote:
On 30 Aug 2002, Bruno Dumon wrote:
Captor is a tool that lets you see the XML being produced by each
transformer in a Cocoon pipeline. Currently it only works
with Cocoon
2.03, and not yet with 2.1. Implementation-wise captor
1 - 100 of 115 matches
Mail list logo
