[EMAIL PROTECTED] wrote:
joerg 2003/07/01 16:44:47
Modified:lib jars.xml
Log:
replace POI 1.7-dev with 1.10-dev
Revision ChangesPath
1.55 +2 -2 cocoon-2.1/lib/jars.xml
Is it possible to fix this "changed lines"-counter? :-)
Index: jars.xml
==
[EMAIL PROTECTED] wrote:
upayavira2003/07/01 05:37:48
Modified:src/documentation/xdocs/userdocs/concepts persistence.xml
Log:
Fixing broken link in CVS, reported as Bug 21218 by cgaffga at triplemind.com.
Does the site now need to be rebuilt?
To have the change online: yes. But
Bertrand Delacretaz wrote:
Le Vendredi, 27 juin 2003, à 15:52 Europe/Zurich, Geoff Howard a écrit :
Joerg, David and I are discussing alternatives to the current
build file entities for the sub-targets. One that's on the
table now is to use ANTModule from http://www.ct42.de/en/ch02.html.
See belo
Geoff Howard wrote:
To David's question:
I don't have an ant reference, but I don't think there's
a way to do that and still do the entity include. That's
why the resource Joerg pointed to exists I'd guess. You
can't have entities point to the children of the root node
by some magic I'm not aware
May I point to http://www.ct42.de/en/ch02.html?
Joerg
David Crossley wrote:
On 2003-03-30, Geoff Howard wrote:
Is there any strategy for making the xml fragments in
src/targets well-formed so editors don't barf on them?
That sounds like a good idea and makes me itch.
What do you think needs t
[EMAIL PROTECTED] wrote:
joerg 2003/06/26 17:46:41
Modified:src/documentation/xdocs/userdocs/generators
directory-generator.xml
Log:
as promised the update on the documentation of the DirectoryGenerator
Revision ChangesPath
1.2 +113 -114 c
Bruno Dumon wrote:
> 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?
Hello Bruno,
back to these bugs - we stumbled over them in our company, where we use
Cocoon 2.0.4 and updated Xalan to 2.4.1.
The pipe:
Pier Fumagalli wrote:
SetAttribute vs Well-formedness:
Briefly, I wanted to check with you people if a functionality like the XSLT
setattribute is required, or the non-well-formedness of Garbage is better
(see previous messages on this thread)... Both approaces have
Jeff Turner wrote:
Vote 1: Cocoon committers automatically become Forrest committers
+1
Vote 2: Forrest should become a subproject of Cocoon
(http://cocoon.apache.org/forrest)
+1
Joerg
Stefano Mazzocchi wrote:
Technically, all Lenya people have Cocoon CVS commit karma if I read the
avail file correctly.
Hmmm, if this is the case, that even Forrest committers has to have this
kind of right.
[RT] Why Forrest is not/does not become a subproject of Cocoon while
it's so heavily base
[EMAIL PROTECTED] wrote:
Ok, what happen:
Calling a Cocoon Source "cocoon://." the Pipeline inside the Sitemap is
called twice. The reason is the following code inside the
SitemapSourceFactory
public void release( Source source ) {
if ( null != source ) {
if ( this.getLogger().isDeb
David Crossley wrote:
I propose Reinhard Pötz to be a Cocoon committer.
+1 of course
On Sat, Jun 21, 2003 at 06:12:15PM -0400, Vadim Gritsenko wrote:
Geoff Howard wrote:
Can we do something more drastic to the xml-cocoon2 repository that would
prevent people from making this innocent mistake? What about removing
everything except a README.TXT or something?
I hope you really mean:
Thanks, David, but you don't need to for 2.1: I already planned to do
it, but wanted to finish the Java stuff first (caching in 2.1,
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105620309928135&w=2).
And at least Sunday is my Cocoon free day :-) So I will do the rest next
week.
Joerg
Davi
Hello Sylvain,
you implemented the caching for the DirectoryGenerator in Cocoon 2.1.
For the key generation you simply concatenated the string
representations of all parameters. But SimpleDateFormat and RE don't
have implemented the toString() method and so strings like
"[EMAIL PROTECTED]" are
Pier Fumagalli wrote:
"Jelly could have a surface syntax that looks similar to Velocity. i.e.
someone could make a parser of Jelly that had a look-and-feel of Velocity for
common directives and expressions."
Now, what do I mean by "simpler" sintax? Imagine, for example a "foreach"
statement:
In
Stefano Mazzocchi wrote:
The vote clearly indicates the community wants the "small -> big"
approach. Chris has also removed his concerns. This gives us green light
to go ahead and finish the FOM design as we proposed it.
Does this mean this vote overrules the other one on releasing Cocoon 2.1
or w
Do you mean each map:part in an aggregation? Where do you take this from
(debug?)?
Joerg
Klaus Bertram wrote:
Hi all,
the treeprocessor call an map:part src twice at one request.
The first generated map:part are used from the browser
(both Mozilla and IE6.0)
The sitemap log file show both gener
I guess a bug, they should be created in dependency on the properties
(not excluded blocks).
Joerg
Klaus Bertram wrote:
Hi all,
is it an bug or an feature that the whole javadocs for the block classes
are not created by an build??
cvs checkout form 1/2 hour before
I had a look at the build fi
Already fixed on May, 21th, the same day of, but after the 2.1m2 release:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/databases/java/org/apache/cocoon/acting/DatabaseAuthenticatorAction.java.diff?r1=1.3&r2=1.4&diff_format=h
But thanks for your effort,
Joerg
Sune Simonsen wrote:
I do
> 2) small to big
+1 from me
Ricardo Rocha wrote:
Stefano Mazzocchi wrote:
1) big to small -> give users all possible freedom and restrict that
freedom once we understand potentially problematic usages.
2) small to big -> give users the least possible freedom based on some
required functional
Hello Brian,
I tested the current Cocoon 2.1m3 CVS. I removed jakarta-poi.jar after
building Cocoon. Now requesting a page serialized to Excel file format I
get the following exception logged:
14:57:48.875 WARN!! Error for /samples/poi/hello.xls
java.lang.NoClassDefFoundError:
org/apache/poi/p
Mark Miller wrote:
How come I have to remove the xalan jar file from the 2.1 cocoon lib
directory if the build is setup for java 1.4.1?
Hello Mark,
I know there are many problems with the Xalan integration in JDK 1.4.x,
but why want you to remove it completely? Maybe reading this helps:
http://
Joerg Heinicke wrote:
[+0.5] Release Cocoon 2.1 /immediately/.
[+0.5] Release Cocoon 2.1 beta 1 /immediately/.
[-0.9] Release further milestones while implementing the FOM. Cocoon 2.1
will be released subsequently.
[+1] Release Cocoon 2.0.5 as soon as possible.
Joerg
Hello,
since nearly 9 months (!) we have been speaking about a Cocoon 2.1
release:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103286944631116&w=2
If we agree, we could make an alpha release very soon, fix the
bugs, move the not finished components into scratchpad, make
a beta - let's say
al Message-----
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 7:41 PM
To: [EMAIL PROTECTED]
Subject: Re: sitemap.xls - XSLTFactoryLoader flaw?
Hello Derek,
can you please make sure, that the correct Xalan version is used? You
can follow the instruction
Updated the rest. LiveHTTPHeaders is really a nice tool. I love Mozilla
more and more :-) Imagine you have to do this work using wget ...
Joerg
Steven Noels wrote:
On 6/06/2003 19:13 Joerg Heinicke wrote:
Do you believe me, that it is a Cocoon application ;-) it's possible
that the
With or without beta release?
Joerg
Steven Noels wrote:
On 13/06/2003 21:18 Joerg Heinicke wrote:
If the FOM implementer themselves are of this opinion, let's go ahead
and release Cocoon 2.1 as soon as possible.
Does it need a vote?
It normally does, would you mind starting it?
If the FOM implementer themselves are of this opinion, let's go ahead
and release Cocoon 2.1 as soon as possible.
Does it need a vote?
Joerg
Christopher Oliver wrote:
I agree with you that 2.1 should not be delayed for changes to FOM. That
can come later.
Stephan Michels wrote:
On Fri, 13 Ju
After this:
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=105537399821420&w=2
is it possible to remove XSPUtil.include() in 2.0 too?
Joerg
ocoon 2.0: http://server:port/pathToCocoon/welcome
Cocoon 2.1: http://server:port/pathToCocoon/samples/
Joerg
Derek Guardiola
Elsevier Science
-Original Message-----
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 3:56 PM
To: [EMAIL PROTECTED]
Subject:
Is there any reason for catching all exceptions instead of catching
SQLExc., IOExc. and ComponentExc. separately?
Joerg
[EMAIL PROTECTED] wrote:
joerg 2003/06/10 17:28:31
Modified:src/blocks/databases/java/org/apache/cocoon/transformation
SQLTransformer.java
Hmm, I never I had any problems with the sitemap in such a simple case
with nearly all Cocoon versions 2.0.4 and below. In current 2.0 CVS and
in 2.1 the sitemap.xsl (=> compiled sitemap) is no longer used as
default, but the interpreted sitemap, which as a lot faster.
What's the Cocoon version
Hello Christian,
applying to your commit message and in comparison to the second example
shouldn't it be
return (result[0] == null? null : result);
Otherwise it seems to make no sense.
Joerg
[EMAIL PROTECTED] wrote:
Make sure to return null instead of { null }
...
Object[] resul
Hello Bruno,
Bruno Dumon wrote:
startElement[
uri: '', localName:'xhtml:div', raw:'xhtml:div']
endElement[
uri:'http://www.w3.org/1999/xhtml', localName:'div', raw:'xhtml:div']
if these are corresponding start and end element events, then this is
obviously wrong.
Yes, these are :-(
And using XSLT
Carsten Ziegeler wrote:
But there is another reason for this mail: Now with the current XSLTC we
can switch to it as default processor in 2.0 too, can't we?
I'm currently -1 on this because imho xsltc has not proven to be 100%
working and I think we should at least in 2.0.x have a fully working
xs
[EMAIL PROTECTED] wrote:
stevenn 2003/06/06 08:10:59
Modified:src/documentation/xdocs/link livesites.xml
Log:
while I was at it: deleted some host-not-founds and indicated some reservations
Revision ChangesPath
1.4 +8 -9 cocoon-2.1/src/documentation/xdocs/lin
The SAX events startElement, endElement, startPrefixMapping,
endPrefixMapping in Xalan:
startPrefix [prefix: '', uri: ''
startElement[uri: '', localName: 'html', raw: 'html'
startPrefix [prefix: '', uri: ''
startElement[uri: '', localName: 'head', raw: 'head'
startPrefix [prefix: '', uri: ''
star
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20508
Hello Thorsten,
I applied your patch on my system and tested it. But it's even worse
than without the patch :-( It's not your problem, it's because of
extreme hacks I guess.
My test stylesheet:
Test
http://www.w3
Thanks for fixing it.
Joerg
Geoff Howard wrote:
oops! obviously I needed to test _twice_ before committing.
should be fixed now. I'm testing it but have to run out and
the first build isn't finished.
Geoff
Tried a "build webapp" (without clean). The build fails in target
"patch-conf":
---
Processing: D:\cocoon-2.1\src\blocks\session-fw\conf\session.xconf
Writing: D:\cocoon-2.1\build\webapp\WEB-INF\cocoon.xconf
Processing:
D:\cocoon-2.1\src\blocks\authentication-fw\conf\aut
Isn't it already the default ? The TreeProcessor has now been around
for more than a year...
Yep. I checked and the TreeProcessor _is_ the default engine.
searched for "tree" in 2.0 cocoon.xconf and didn't find it. after a
closer look I found it.
Joerg
Sylvain Wallez wrote:
Actually, ParanoidCocoonServlet can be used to run *any* servlet. So
I'll commit the changes in the 2.0 CVS also, so that we can point users
to this page.
Nice to hear ...
But there is another reason for this mail: Now with the current XSLTC
we can switch to it as default
Hello Sam,
what was your Xalan version before the update, so what was the working
version? Do you have multiple step includes (stylesheet1 includes
stylesheet2, that includes stylesheet3)? We already have a bug related
to this: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20308.
You can s
Though we will get again "endorsed lib problem" questions on the users
list, I updated the XML lib jars to their latest releases as in Cocoon
2.1. I hope nobody has something against this. At least we have a good
explanation and solution for these issues now
(http://wiki.cocoondev.org/Wiki.jsp?
Bruno Dumon wrote:
On Wed, 2003-06-04 at 21:09, Joerg Heinicke wrote:
In conclusion:
1. We need a patch for the HTMLSerializer for the namespace issue.
2. A validation transformer seems to be really welcome.
3. For human readability we do not need really a new serializer. What
about the indent
set it to true, but this only adds
line breaks AFAIK and does not indent the code. Maybe we simply need a
patch too?
Joerg
Torsten Knodt wrote:
On Tuesday 03 June 2003 23:46, Joerg Heinicke wrote:
JH> For debug output I normalize-space every text node and simply indent
JH> them by counti
Bruno Dumon wrote:
I guess, legacy support won't be readded, so this is a WONTFIX?
yes, I agree. A bit of a problem though is that upon encountering the
old namespace, the I18nTransformer nicely logs a warning, however the
log level is error by default. Maybe we should lower it to warn instead?
(th
Torsten Knodt wrote:
On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote:
JH> 1: A solution for the HTMLSerializer was discussed
JH> (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer
JH> provides a better solution, but I guess this can be adapted too.
>
A little m
I guess, legacy support won't be readded, so this is a WONTFIX?
Joerg
[EMAIL PROTECTED] wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20445
i18n transformer does not recognize 2.0 namespace
Summary: i18n transformer does not recognize 2.0 namespace
Product: Coc
AC> 1) As a fix for the "the namespace problem"
AC> 2) When human-readable HTML output is needed
AC> 3) To validate the output to a dtd
Hmm, all 3 reasons are not strong enough for adding a further serializer
with almost the same functionality IMHO.
1: A solution for the HTMLSerializer was discus
I think this is plain simple - as long as noone of the committers has
time for it and has fun in doing so, nothing will happen. This is
open source development and this means, things are not done because
someone "forces" you to do them. Work is done because someone has fun
in doing so.
I don't want
I fail to see how ownership by a person would help in applying patches
more consistently. Having a 'sponsoring committer' might help to get
patches applied. Then again, I think you are looking at the symptom, not
the cause. The fact no sponsoring committers exist for certain
patches might tell
Hello,
I updated POI in Cocoon 2.0 from 1.5.0-dev to the latest release 1.5.1.
But what's with Cocoon 2.1? There the unreleased 1.7-dev is used. We
can't upgrade to a more current dev version e.g. for international
character support
(http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=105410838
Torsten Knodt wrote:
CT> Also, is XPathDirectoryGenerator cachable?
Code looks like DirectoryGenerators are cacheable. The documentations says no.
I'm not yet an expert there in.
Hello Thorsten,
this feature is only two weeks old:
http://marc.theaimsgroup.com/?t=10528587111&r=1&w=2.
Regards
Vadim Gritsenko wrote:
Joerg Heinicke wrote:
Hello Cocooners,
I updated my local copy of Cocoon 2.1 with the current Fop release
0.20.5rc2.
There is lib/local folder for the local libs. Local is not (should not
be) checked against jars.xml.
But this would not solve my problem, would it?
I
Hello Cocooners,
I updated my local copy of Cocoon 2.1 with the current Fop release
0.20.5rc2. I updated the entry in jars.xml, but a CVS update always
brings back the fop-0.20.4.jar. When building I get the following
*warning*, which leads to *build failed* at the end, because of
. Must the bu
Had the same yesterday. You simply must delete one of the ancestor
directories of the file and update again.
Joerg
Sylvain Wallez wrote:
Folks,
I'm experiencing problems while updating cocoon-2.1 (cocoon-2.0 is
fine). I get the following messages and then CVS seems to hang :
cvs update: Dropp
There are at least two parts that might not work:
b) configuring the fopserializer with a custom config file
Why shouldn't this work? This is exactly the resolving you fixed today
morning. I didn't test your version, but the version I made yesterday was
not very different and worked, i.e. the co
It's a browser selector, not an accepts-selector ;-)
I guess, the User-Agent header of Nokia 9000 has any specific part, so
you can change the browser selector string to your needs. We for example
use it to differ between different versions of Mozilla.
Joerg
Niclas Hedhman wrote:
FYI,
It look
Not exactly, but the JDK 1.4 comes with older versions of Xalan, Xerces
and so on and there seem to be some incompatibilities. And normally JDK
classes are loaded first => the well-known endorsed problem.
Joerg
Christopher Oliver wrote:
Yes, adding xsltc-X.jar to common/endorsed fixed that
Hello Sam,
it's the well-known endorsed lib problem. If Cocoon 2.0.4 works, I guess
you copied the xalan-xx.jar, xercesImpl-xx.jar and xml-apis.jar from the
Cocoon 2.0.4 lib dirctory to %JAVA_HOME%/jre/lib/endorsed or to
%TOMCAT_HOME%/common/endorsed. Now the problem is, that with Cocoon 2.1
y
A question to the Cocoon developers/committers:
Is it possible to especially catch this exception and give a hint "what
to do" in the logging output?
Joerg
Joerg Heinicke wrote:
Hello Ignacio,
it's the old Xalan problem. Copy xalan-xx.jar, xercesImpl-xx.jar and
xml-apis.jar
Hello Ignacio,
it's the old Xalan problem. Copy xalan-xx.jar, xercesImpl-xx.jar and
xml-apis.jar used in Cocoon into Tomcat's common/endorsed/ directory.
Regards,
Joerg
Ignacio J. Ortega wrote:
Hola a todos:
Using w2k, jdk14, tc 4.1.X HEAD ,cocoon2 HEAD, just built everything
myself, coocon i
Hello Tim, hello Peter,
I still think it's not a bug, it's only a clarification or rectification
of the behaviour of Cocoon. There is now a for
client side redirects and a for internal
redirects. The documentation
(http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html) states
this une
Hello Tim,
map:redirect-to *is* a client side redirect and no bug.
http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
Regards,
Joerg
Timothy Larson wrote:
In Cocoon-2.0.4 is this redirect supposed to work?
I get an error from IE that seems to indicate th
Hello,
I get hundreds of compile errors, when building Cocoon 2.1 from CVS. I
use Java 1.4.1 and Win 2000, the command line call was
"build webapp -Dinclude.webapp.libs=yes". The reason is the new mail web
client. After deleting the directory
/xml-cocoon2/src/scratchpad/src/org/apache/cocoon/ma
http://wiki.cocoondev.org/Search.jsp?query=struts&ok=Find%21
Joerg
eklavya jain wrote:
Hello Sir ,
This is Eklavya .Have been using tomcat for a couple of months and have
recently have just gone through the sub projects of Jakarta and have
found them very intresting .
I needed some basic help
Until now not even an alpha exists, but it was planned for the beginning
of december. So it may take still some time til beta or release.
Joerg
Robert Kromkamp wrote:
Hello,
I've a question about the link below:
http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html
This H
But isn't it obviously a Saxon bug, if namespace declarations appear in
text output? I think it's not possible to fix the code for every
processor release, even if this seems to be a little fix. If you want to
use this Saxon version, is it not enough to change it in your local version?
Joerg
T
comments inline.)
Ovidiu Predescu wrote:
Hi Joerg,
[Oddly enough, I couldn't find the message you're quoting.]
It seems that it does not arrive at the mailing list.
On Saturday, Dec 14, 2002, at 06:09 US/Pacific, Joerg Heinicke wrote:
1. The differences between Cocoon and command l
your system.
Joerg
Suhail M Ahmed wrote:
Hi Joerg
I copied the following jars;
xalan-2.4.1.jar
xercesImpl-2.1.0.jar
xml-api.jar and
xsltc.jar
cheer
suhail
On Saturday, December 14, 2002, at 01:59 PM, Joerg Heinicke wrote:
Hello Suhail,
it's the typical error for problems with the jars
And as last step the solution for XSLTC:
mode="compile"/>
instead of
mode="compile"/>
So you can at least get it to run with the current Xalan/XSLTC.
Regards,
Joerg
Joerg Heinicke wrote:
1. The differences between Cocoon and command line result from the usa
is only a repetition
of the description below.
3. But if you use Xalan (not XSLTC) and the changed key declaration, it
works ;-)
Regards,
Joerg
Joerg Heinicke wrote:
It's not a problem with complex expressions, but a general problem with
the use Muenchian grouping mechanism. I compare
Hello Suhail,
it's the typical error for problems with the jars. You say you already
copied them to the endorsed directory, but I think something still is
wrong there. Which files did you copy where?
Joerg
Suhail M Ahmed wrote:
Hi,
I checked out the latest Cocoon version from the CVS, build i
The documentation (both on the homepage of Cocoon and coming with the
release) shell relate always to the latest release (at the moment
2.0.4). Otherwise it's a bug.
Joerg
Miles Elam wrote:
Would it be possible to mark the documentation at points with version
info? I wasted a few hours the ot
We have the same problem with Cocoon 2.0.1. Do you have a current
version? First tests with 2.0.3 were okay, even if the code, you
mention, has not changed. But maybe the tests only were okay by accident?
Maybe. AFAIK the dependency on the correct content length
for displaying PDF is a IEx speci
BTW, I know "Tisch" which means "table", but what does "Stamm" mean ?
http://dict.tu-chemnitz.de/dings.cgi?lang=de&noframes=0&query=stammtisch&service=&optword=1&optcase=1&opterrors=0&optpro=0&self=1
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
[EMAIL P
We have the same problem with Cocoon 2.0.1. Do you have a current
version? First tests with 2.0.3 were okay, even if the code, you
mention, has not changed. But maybe the tests only were okay by accident?
Joerg
Lars Steiger wrote:
hi everybody
i had problems getting a pdf (as file) through the
In case you didn't realize, XSLT is definately *not* a turing-complete
language :) [you need internal scripting or extensions to turn it into one]
http://www.google.de/search?hl=de&ie=UTF-8&oe=UTF-8&q=turing+completeness+XSLT&btnG=Google-Suche&meta=
http://www.unidex.com/turing/utm.htm
http://w
Hi Unico,
the patch will got lost on the list. Add a bug in bugzilla and mark it
as patch. Look at http://xml.apache.org/cocoon/howto/index.html
"Contribution" for further information.
Joerg
Unico Hommes wrote:
Hi,
I noticed that although the following declaration appears in cocoon.xconf:
--
Hong Gia Dinh wrote:
Hi all,
I used ' '
is not known in XML, it's a HTML entity. Use instead.
and
You must declare the namespace for the namespace prefix o. It shell look
like: xmlns:o="http://www..com";.
Regards,
Joerg
-
The most important bug seems to be the broken documentation
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12396), but I can't
produce the bug on my system. There are now at least 3 people with the
problem.
Joerg
Carsten Ziegeler wrote:
Hi Team,
as I posted days ago, I would propose the 4
What's different? ;-)
Joerg
Tom Amiro wrote:
Hi,
The html produced by Xalan vs XSLTC are so different, it is hard to know
where to begin.
It definitely looks like an XSLTC bug.
Below are snippets from the top showing that things get out of synch
really fast.
It would help in debugging this,
Antonio Gallardo Rivera wrote:
What about the missed features that still are not working as:
, cocoon protocol with request params and similars.
Anyway I think will be fine to write a little doc about what is not working in
the alpha release. Many newbies will like to try this new features and
Hello Cocoon developers,
I asked Nicola according the frequency of the patch queue mails (see
below). Is it really needed so often?
Joerg
From: Nicola Ken Barozzi <[EMAIL PROTECTED]>
> Joerg Heinicke wrote:
>> Hello Nicola,
>>
>> isnt' this patch queue to often
Sylvain Wallez wrote:
>>> You may puke (if you still can ;-), but what about considering
>>> sitemap-defined namespaces as internal to the sitemap, and thus
>>> prefix them with a "#", that we all know as being used for internal
>>> links in web pages ?
>>>
>>> This would lead to (adapted from
Torsten Curdt wrote:
> On Thursday 10 October 2002 04:24, Joerg Heinicke wrote:
>
>>>>We already have XPath. Why use it? Because its like all computer related
>>>>thing teached us for years. Everybody know that ".." means parent.
>>>
>>>
>>We already have XPath. Why use it? Because its like all computer related thing
>>teached us for years. Everybody know that ".." means parent.
>
>
> but the question is - what means child?
>
> "../" is well known in xpath as well as in filesystems for being "one
> level up". So what would be
Hello Thorsten,
in my opinion the syntax {/1} is really poor. Maybe it's only
because of my knowledge to XPath and file systems or protocols, but a
syntax like 1 is not known anywhere. It's logical to use /1 to get
the root 1, but never for 1 level back. Who shell explain this to Cocoo
Hello Frédéric,
can you provide the code, either (if it's not too much) on the list
(zipped) or as patch in bugzilla? I'm really interested in some code
better than simple-xml2html.xsl.
Regards,
Joerg
Frédéric Glorieux wrote:
> Hello developpers
>
> I'm essentially a cocoon user (degree
> While this sort of filtering can be done with XSLT, it can't be done
> dynamically, based on an input parameter, because XSLT template patterns must
> be known at 'compile' time, not runtime, much like the sitemap's
matchers. See
> cocoon-users discussion:
> http://marc.theaimsgroup.com/?t
(If you ask such questions on the cocoon-users list, you will get answers
with higher probability.)
What exactly do you want to do or what have you tested until now?
A simple example:
Regards,
Joerg
Francesco Mondora wrote:
> Ciao,
> it is all
Hassan Abolhassani wrote:
> Is there a way to get ride of content-type meta tag inserted by html serializer. One
>that is in output like:
>
>
Is this not a question for the user group?
Why do you want this? If UTF-8 is the wrong character encoding for you,
change the parameter in the sitemap
anugo Rabellino wrote:
> Joerg Heinicke wrote:
>
>> Why should Cocoon choke on parsing an XML file - if it is really one??
>> The parser doesn't know anything about XLink, so I think this can't be
>> the problem. Have a look at the XML. It looks really strange.
Why should Cocoon choke on parsing an XML file - if it is really one?? The
parser doesn't know anything about XLink, so I think this can't be the
problem. Have a look at the XML. It looks really strange.
I downloaded the example SXW from the link you gave, unzipped it and looked
at the content
Morrison wrote:
>>From: Joerg Heinicke [mailto:[EMAIL PROTECTED]]
>>
>>I built my own version using Xerces 2.0.2 and had no problems.
>
>
> Did you need to move/copy into the servlet engine or did you manage
> to make it run solely within the webapp?
>
>
>&
I have the same problems using Win2k, Sun JDK 1.4.0_01, Tomcat 4.0.4 LE,
cvs checkout from HEAD and "build -Dinstall.webapp.libs=yes webapp".
I think it's not the CSS from line 1519, but the complete
element which ends in 1519. Furthermore there is a DEPRECATED warning of
ant 1.5:
[available
I built my own version using Xerces 2.0.2 and had no problems.
What about the current release versions of Lucene 1.2 and Fop 0.20.4?
Joerg
Torsten Curdt wrote:
> Shouldn't we ship with the latest xerces release?
>
> I was desperatly trying to upgrade everything correctly to have it shipped
>
99 matches
Mail list logo
