Jeff Turner wrote:
Hi,
In Cocoon 2.0, the sitemap used this namespace:
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
In 2.1, we changed the sitemap syntax in backwards-incompatible ways, but
the namespace is still the same, rather making a mockery of the '/1.0'.
I think
cziegeler2003/08/26 23:32:08
Modified:src/scratchpad/src/org/apache/cocoon/components/scheduler
readme.txt
Log:
Adding pointer to wiki docs; Thanks Tony!
Revision ChangesPath
1.3 +5 -0
Guido Casper wrote:
Gianugo Rabellino wrote:
This is, however, the case of the current SourceProperty, a
contract
that, as of now, we might not want to break.
I think we have to. For example in:
public SourceProperty(Element property) {
this.namespace =
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13216.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15618.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16825.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13216.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Guido Casper wrote:
Maybe having getValueAsString() not skipping non-text elements
(although I might not understand what the rationale for this behaviour
is) would be enough to support sources without XMLized properties.
Yes, probably. We'll need to discuss that some more, I was hoping that
stephan 2003/08/27 01:33:42
Modified:src/blocks/webdav/java/org/apache/cocoon/transformation
SourcepropsWritingTransformer.java
Log:
Fixed typo.
Revision ChangesPath
1.2 +2 -2
On Tue, 26 Aug 2003, Gianugo Rabellino wrote:
A source property (both in webdav sense and in the SourceProperty
implementation) is made of three part: a local name (String), a
namespace (String) and a value (DOM Element). It's worth noticing that
the property value is actually the *holder
Gianugo Rabellino wrote:
Miles Elam wrote:
If the Abstracts (AbstractGenerator, AbstractTransformer, etc.) were
updated to reflect this, most folks using Cocoon would only have to
do a
recompile. Folks who implemented the interfaces directly (Generator,
Transformer, etc.) would have more
Bruno Dumon said:
The XInclude transformer depends on the setDocumentLocator() SAX
event for getting the base location in case there is no xml:base
attribute. If you simply have a FileGenerator with after that the
XInclude
transformer, everything should work well. But maybe your problem
is
cziegeler2003/08/27 02:08:12
Modified:src/blocks/portal-fw/java/org/apache/cocoon/webapps/portal/components
PortalManager.java
Log:
Fixing classcast
Revision ChangesPath
1.10 +7 -4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21789.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Gianugo Rabellino wrote:
Guido Casper wrote:
Maybe having getValueAsString() not skipping non-text elements
(although I might not understand what the rationale for this
behaviour is) would be enough to support sources without XMLized
properties.
Yes, probably. We'll need to discuss that
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 26.Aug.2003 -- 06:33 PM, Stefano Mazzocchi wrote:
On Monday, Aug 25, 2003, at 11:12 Europe/Rome, Christian Haul wrote:
On 17.Aug.2003 -- 07:00 PM, Stefano Mazzocchi wrote:
Issues that were still unsolved
1) block identification
All blocks (behaviors and implementations) are
Stephan Michels wrote:
On Tue, 26 Aug 2003, Gianugo Rabellino wrote:
Guido Casper wrote:
I'm however cautious about breaking SourceDescriptionGenerator,
more
so that I found that the slide block isn't marked unstable (Is it
too late to change this?).
I guess we should ask Stephen about it,
On 26.Aug.2003 -- 06:43 PM, Stefano Mazzocchi wrote:
On Monday, Aug 25, 2003, at 10:10 Europe/Rome, Christian Haul wrote:
On 23.Aug.2003 -- 03:48 PM, Stefano Mazzocchi wrote:
On Saturday, Aug 23, 2003, at 10:17 Europe/Rome, Christian Haul wrote:
Stefano Mazzocchi wrote:
On Tuesday,
thanks for your advice, i don't understand how the input and
output
pipe
is generated at once and are not affected by each other... can you
tell me
more please
(note that this belongs to the user list rather than here)
Did you study existing transformers?
Have a look at the
Le Mercredi, 27 aoû 2003, à 10:40 Europe/Zurich, Stephan Michels a
écrit :
BTW, it's annoying getting every day 400 sorbig mails.
spamassassin rules here - I'm getting about 20 of these an hour, and
each one of them is cleanly spamassassinated by my mail server ;-)
-Bertrand
Hi:
please check the main site of cocoon. It seems like it is down.
Best Regards,
Antonio Gallardo
Guido Casper wrote:
However concerning interface design I think if you give the following
input to SPWT:
source:props
my:author xmlns:my=myMe, Myself and I/my:author
/source:props
One would expect that
WebdavSource.getSourceProperty(my, author).getValue();
returns:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14450.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
There's a number of things going on:
- the migration of all websites from daedalus - minotaur
- subsequent change of IP addresses and DNS propagation
- apparently, the ASF is also participating with the SW Patents protest
action
I'm pretty sure infrastructure peeps are on the ball, even
Thanks Steven for your prompt answer.
Best Regards,
Antonio Gallardo
Steven Noels dijo:
There's a number of things going on:
- the migration of all websites from daedalus - minotaur
- subsequent change of IP addresses and DNS propagation
- apparently, the ASF is also participating with
Hello Mircea,
This is very interesting!
How do you authenticate the users?
Regards
Sylvain
-Message d'origine-
De: Mircea Toma [mailto:[EMAIL PROTECTED]
Date: mardi, 26. août 2003 20:47
À: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Objet: [oss] cocoon
Hi:
I am trying to build a block with OJB. I have already the component done,
but in order to have a block complete I need to put some classes into
WEB-INF/classes for the examples.
I saw that woody and apples do that.
How can I archieve this?
Best Regards,
Antonio Gallardo
Gianugo Rabellino wrote:
Geoff Howard wrote:
2. There is no transformer yet (even if, agreed, it would be pretty
easy to build one);
True, but that seemed quite a bit less work than the solutions you
have been looking at. (though I was only following the discussion
casually)
Not really, since
Miles Elam wrote:
Gianugo Rabellino wrote:
Miles Elam wrote:
If the Abstracts (AbstractGenerator, AbstractTransformer, etc.) were
updated to reflect this, most folks using Cocoon would only have to
do a
recompile. Folks who implemented the interfaces directly (Generator,
Transformer,
What I would like to see in Cocoon is a build target that is sort of like
the following:
build.bat production
This build would build cocoon according to the local.blocks.properties and
the local.build.properties. However, it would not include any samples,
demos, documentation, API documents,
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Hi Carsten,
I have also a problem with the authentication Administration.
I can't access to the admin pages since I have added a LDAP
transformer inside the authentication pipeline.
Is it for the same reason?
Hard to tell from from
Geoff Howard [EMAIL PROTECTED] writes:
If the Abstracts (AbstractGenerator, AbstractTransformer, etc.)
were updated to reflect this, most folks using Cocoon
would only
have to do a recompile. Folks who implemented the interfaces
directly (Generator, Transformer, etc.) would
Stefano Mazzocchi wrote, On 26/08/2003 18.43:
...
I would like Nicola to update its RT on aspectizing the sitemap after
the introduction of virtual components (which, IMO, solve most of the
issues he outlined).
Actually I already reference the concept:
Hmmm, it also has to do with the named
- Original Message -
From: Robert Simmons
What I would like to see in Cocoon is a build target that is sort of like
the following:
build.bat production
This build would build cocoon according to the local.blocks.properties and
the local.build.properties. However, it would not
Antonio Gallardo wrote:
Hi:
I am trying to build a block with OJB. I have already the component done,
but in order to have a block complete I need to put some classes into
WEB-INF/classes for the examples.
I saw that woody and apples do that.
I'm not sure what you are refering to Antonio,
Miles Elam [EMAIL PROTECTED] asks:
Okay, here's a wonky thought: why not make all components cacheable?
snip/
So am I off my rocker for proposing this?
No, I don't think so. I've basically suggested that in the long term
this would make sense, I hadn't thought of doing it with the current
I didn't notice that there are virus mails coming through the mailing
list before reading your mail.
I just saw that there are many Apache-Mails in my Virusalert folder,
where all alerts from my university's mail server (which uses AMAVIS
BTW) are automatically sorted in.
Such tools are really
I just noticed on another project of mine that if you can avoid forking for
the JUnit tests, you can increate the performance of the tests by a large
margin. I did that change and the time it took to run my tests was cut in
half.
--
They that give up essential liberty to obtain a little
Hunsberger, Peter wrote:
Geoff Howard [EMAIL PROTECTED] writes:
Again, no change to the impact on the cache. Just less Cocoon code:
everything is considered for caching, no key or no validity, no caching.
Same as today; but currently it's possible not to be even asked for a
key or validity.
Geoff Howard wrote:
This is definitely an interesting idea, but I can't believe that this
sort of backwards-incompatibility would fly. One option would be to
put a null validity implementation in the Abstract* so subclasses
don't have to do anything, but I can't see that happening in a 2.1
Geoff Howard [EMAIL PROTECTED] writes:
Umm why? You can still invalidate the validity in any
manner you see
appropriate, or for that matter, you can still manage the cache of
actual data in any way you see fit...
I may have been jumping to conclusions, but my assumption
based on
Hi peeps,
my colleagues are just back from the live demonstration in front of the EU
offices. Several hundreds of people where effectively there, and while we
will never know whether such actions have any effect, I was proud to be
able to tell them that all ASF sites were participating with the
upayavira2003/08/27 12:18:18
Modified:src/java/org/apache/cocoon Main.java
src/java/org/apache/cocoon/bean CocoonBean.java
CocoonWrapper.java
Added: src/java/org/apache/cocoon/bean Target.java
Log:
Moved Target into a separate class
Switching from Forrest-dev...
Jeff Turner wrote (on forrest-dev):
On Wed, Aug 27, 2003 at 10:42:36AM +0100, Upayavira wrote:
Jeff Turner wrote:
On Tue, Aug 26, 2003 at 06:27:08PM +1000, David Crossley wrote:
I rebuilt my local Forrest doco today but i get all these strange
error
Greetings,
One thing that I would like to see is Cocoon supporting the XForms 1.0 standard
as described on W3C.
http://www.w3.org/MarkUp/Forms/
There is currently a product in the open source community called Chiba that
accomplishes a good portion of this integration. This could be built upon
On Wed, 27 Aug 2003, Robert Simmons wrote:
Greetings,
Is there a manual that describes all of what each block in cocoon 2.1
does ? Perhaps I missed it.
Nope, it isn't there. Don't forget to have a look at
http://cocoon.apache.org/2.1/plan/index.html,
48 matches
Mail list logo
