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/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/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/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/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/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: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 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 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 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: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: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: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: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: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: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: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: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: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: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: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: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
in a single 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]
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
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
will look into improving it (but have some patience -- it will
likely not be before 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 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 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: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
gt; > without using a regexp.
> > 2/ if not, use 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 thi
vent to generate malicious events.
I think the problems you 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://out
ent (or
maybe a sticky cvs tag) ?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
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/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: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: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: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 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
raw: 'xhtml:div']
> endElement [uri: '', localName: 'xhtml:div', raw: 'xhtml:div']
>
In a namespace-aware environment, this certainly isn't allowed either.
For more background see also
http://www.saxproject.org/?selected=namespaces
If you put the loggingtransformer right behind the xslt transformer,
then these are problems with xalan.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
l approach for key-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
fails to compile the
stylesheet, 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://outer
purpose is not
to replace 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 &
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/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
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 no
ake 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 http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
ault. Maybe we 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
[
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 a
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/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
HTMLGenerator using jtidy
> and noone says, we wait for the web pages to have valid (X)HTML.
While I do find 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&#x
it in a non-machine-readable
> state.
> For example; we're running CHTML pages (i-mode) live from Cocoon, and
> those 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
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
> problem solved with it.
>
> [The problem: an empty textarea ()
> is
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 PROTE
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/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
On Fri, 2003-04-04 at 16:56, Stefano Mazzocchi wrote:
[...]
>
> I really don't understand why some of you are so emotionally attached to
> something like
>
>
>
Bad example, you can as well write:
But your point still stands of course.
--
Bruno Dumon
e form with data from the XML document,
and once the submit-until-everything's-valid cycle is over, apply the
changes back to the XML document.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
-project collaboration and will ease the migration of users between
> the various Apache frameworks. And this can only be good for Cocoon.
I completely agree on the reuse and joining forces, as long as it fits
with what we're looking for.
I'm also wondering how struts (and related t
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, bu
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]
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
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
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
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
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
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]
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
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]
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.
-
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
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]
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
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 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
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]
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/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
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
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]
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]
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'
John, and all of you for the positive votes.
--
Bruno
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
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 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
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
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
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
, 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
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
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
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
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]
-
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
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
thouth corresponding endElement etc.) ?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
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
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]
---
1 - 100 of 124 matches
Mail list logo
