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
bruno 2003/06/07 13:49:24
Modified:src/java/org/apache/cocoon/components/source/impl
SitemapSource.java
Log:
Make sure that the variable "systemIdForCaching" always gets initialised,
otherwise getURI() could return null. This could happen in
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
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
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.j
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
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:17:36
Modified:src/java/org/apache/cocoon/transformation
XIncludeTransformer.java
Log:
various fixes
Revision ChangesPath
1.5 +30 -29
cocoon-2.1/src/java/org/apache/cocoon/transformation/XIncludeTransformer.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
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
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
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 06:40:28
Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
Repeater.java
Log:
appropriately add or remove rows on repeater submit as required.
Revision ChangesPath
1.5 +11 -4
cocoon-2.1/src/blocks/woody
bruno 2003/06/26 08:32:34
Modified:src/blocks/woody/java/org/apache/cocoon/woody/datatype/typeimpl
AbstractDatatype.java
Log:
corrected message
Revision ChangesPath
1.2 +1 -1
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody
bruno 2003/06/26 08:33:11
Added: src/blocks/woody/java/org/apache/cocoon/woody/datatype
DynamicSelectionList.java
Log:
initial commit
Revision ChangesPath
1.1
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype
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/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/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
. So maybe we
> should start on an limititions-enforcable programming
> language LEPL ;-)
>
For business logic, I find java quite a good language, no need for a LEPL
for me :)
> > What we could do to support user adoption is
> > provide plenty of
> > already implemente
me mails regarding a reworking of resource management,
this can maybe meanwhile be fixed?
Thanks
--
Bruno Dumon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
able. In fact,
> it doesn't honor any of the avalon related interfaces except for
> Contextualizable and Loggable.
>
> Since I've seen some mails regarding a reworking of resource
> management,
> this can maybe meanwhile be fixed?
>
> Thanks
>
> --
> B
t.org/cocoon/resources/cocoon2/
(webhosting kindly provided by Steven Noels, it runs on - of course -
Cocoon2)
Looking forward to your feedback,
Bruno Dumon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
> Great work! I was expecting something like that someday.
> Just a few comments and suggestions:
> - in my opinion, the tree view is too colored, although
> every color has
> its meaning. Maybe in future it would be better to use some
> icons to show
> the type of the node?
after a while
> Wow,
>
> realy great work. It is very cool!
>
> Dumon, do you think we could add it to the cocoon2 project?
My firstname is actually Bruno, so it should be "Mr. Dumon" or just "Bruno"
:-)
I don't have a problem with adding it to the cocoon2 project, b
.g. most parts of the cocoon sitemap, ant build files, ...).
My plans are to keep working on it next week (if nothing comes in between),
clean-up, write some javadoc and some design notes, and then post a new
version.
Bruno Dumon.
-
make sure
> > the
> > tools stay in sync with Cocoon (which may be more difficult
> if they are
> > on
> > SF).
> >
> > Also - the developers would probably be the same as those currently
> > working
> > on Cocoon (or come from the same groups) - At
mentation can be found on http://www.oasis-open.org/committees/relax-ng/
Bruno
Dumon
-Original Message-From: Jeffrey Ricker NG
[mailto:[EMAIL PROTECTED]]Sent: dinsdag 17 juli 2001
16:22To: [EMAIL PROTECTED]Subject: DTD for
returns null, the method is
>
It depends on which version of Cocooon they are using. The test 'null !=
sourceLocator' is not yet present in 2.02, it was only added on May 7.
--
Bruno Dumon
-
To unsubscribe, e-mail
will use the same HashTable anyway.
Since it is just a matter of removing the word 'static', I guess it would be
overkill to supply a patch.
--
Bruno Dumon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
ou'll have to make a generator that streams the domtree to sax events.
A completely other solutions, less nice and performant, but easier to
implement is to use an XSLT that generates some HTML with some javascript in
the onload event that will do the redirection.
--
Bruno Dumon
>
oon.xconf. Just make the default one
xalan.
By the way, has anyone tried out Resin's (www.caucho.com) xslt processor?
Some first tests on my stylesheets show that it's 4 times as fast as saxon
or xalan.
--
Bruno Dumon
-
with xsltc you can keep using xalan for those. See
the TraxTransformer javadoc for more information.
I didn't try all this with xsltc though, I just wanted to point out that it
isn't required that xsltc works with sitemap.xsl.
--
Bruno
> -Original Message-
> From:
g:
("http://apache.org/cocoon/sitemap/1.0":call) and
("http://apache.org/cocoon/sitemap/1.0":call){0-UNBOUNDED} (or elements
from their substitution group) violate "Unique Particle Attribution".
[Error] sitem
, it stores the SAX-events that came out of each
transformer.
For more information and download, see:
http://outerthought.net/captor.html
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTE
On Fri, 2002-08-30 at 14:51, Stephan Michels 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
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
> > &g
erface, 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 Compete
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://outert
point to Xerces.
>
> But, it is not optimal. Saxon would work much faster using 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).
--
Brun
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
&g
On Thu, 2002-11-28 at 10:52, David Crossley wrote:
> Thanks Bruno, i left your patch until after getting Colin's
> RNG/Schematron stuff in.
>
> However, i do not understand the purpose of your patch.
> Would you please explain in a little more detail.
Of course.
One part of
col, but I 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
--
B
ss() on that object.
>
Ah, didn't know I 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]
---
ral transformation steps and see what happened.
>
> sounds very similar to captor which has been posted 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 pipelin
thouth corresponding endElement etc.) ?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
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 SQL
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
h I still need to look
in how it could be done using XSLT).
Ah well, we can continue this discussion forever :-)
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]
-
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.
key
(and we'd also need a syntax for attributes)
Thoughts?
--
Bruno Dumon http://outerthough
is the name that
would be used on the i18n tags:
...
On the component instance level, I thought of only allowing to override
the default bundle (and not specifying additional bundles):
All this will cause some backward-incompatible changes (though maybe it
would be poss
On Thu, 2003-02-13 at 12:53, Konstantin Piroumian wrote:
> From: "Bruno Dumon" <[EMAIL PROTECTED]>
[...]
> > > or maybe use namespaces:
> > > ?
> >
> > I think this will cause confusion with namespaced attributes.
> > How about this:
> &g
, 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 fi
referencing
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 Cente
r most XSL's I've seen 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 &am
alizeDocumentAlgo
Putting this extra 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?
--
Bru
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 ev
also based on the identity
transformer). Otherwise we would have to derive 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://outerthough
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 DOM
John, and all of you 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'
u don't want to see
> [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]
DOM-streamer.
I think 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 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:
> > >
> > > [Namespa
w
> cocoon-2.1 (co cocoon-2.1) and the old xml-cocoon2 module)
>
Sorry, my fault. Should be fixed now, could you try again (on
cocoon-2.1, not yet applied on cocoon-2.0) and let me know if it's all
ok 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 error
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'
On Mon, 2003-03-03 at 23:00, Jeremy Quinn wrote:
[...]
> I have got it. This was answered on the users list a while back, sorry
> guys.
>
> Answer, use the SetCharacterEncodingAction in the Pipeline.
>
> Works with InputModules too.
(a bit late to jump into this thread)
Are you sure that it wa
g to the same encoding of the serializer.
>
> Lets put the config in, it will make it easier for other to see what to
> change. We work exclusively in UTF-8 for instance.
+1
Since the serializers are using UTF-8 by default, it's only logical 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]
attributes.
If you want to quickly disable this behaviour 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.addAttrib
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.
-
being split in SAXParser and DOMParser, changes in
SourceResolving, ...) but most of them are straightforward to port.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
n 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
[E
I think this should do it:
cvs 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]
7; somewhere else (or for that
matter, __ or [ or whatever). Is this something that can be fixed or is
it an inherent limitation of the chaperon parser?
AFAIU wikis don't have a concept of invalid syntax so parsing should
never fail.
--
Bruno Dumon
able together with flowscript, but using flowscript
should not be a requirement
* ...
All the above 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 h
On Tue, 2003-04-01 at 16:50, Bertrand Delacretaz wrote:
> Le Mardi, 1 avr 2003, à 16:18 Europe/Zurich, Bruno Dumon a écrit :
>
> > ...It should be possible to create a form just by describing its
> > structure
> > in an XML file (lets call this a "form description
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 t
st NYI.
>
> Especially database mapping is still an issue. And it has
> no flow support yet.
Database mapping and flow seem like 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 certai
and I want to migrate our presentation
> semantics to XMLForm in future versions of what we are doing...
I meant the XMLForm framework from Cocoon, not so much the W3C XForms
specification.
[... I'll reply to the rest tomorrow ...]
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
1 - 100 of 124 matches
Mail list logo