DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Am Di, den 16.03.2004 schrieb Carsten Ziegeler um 07:58:
Hi Stephan, could you please revert your changes? Joerg already
asked you to do so and I think we should either revert or change
the current behaviour. It's really annoying to have all this Dismiss
messages. There are hundreds of them
Stephan Michels wrote:
Am Di, den 16.03.2004 schrieb Carsten Ziegeler um 07:58:
Hi Stephan, could you please revert your changes? Joerg
already asked
you to do so and I think we should either revert or change
the current
behaviour. It's really annoying to have all this Dismiss
Vadim Gritsenko wrote:
Upayavira wrote:
It seems that Cocoon's I18N code is more geared towards
internationalisation of 'webapps' rather than static sites.
It deals with menu items, etc, taking the various translations from
catalog files, as necessary.
However, when you want to build a
Hunsberger, Peter wrote:
Hmm, not sure. Work flow has been around well over 10 years and pretty
well defined for all that time.
That may be true for the term in general (although I'm not so sure about
it as almost each time I hear somebody mentioning that term it's in a
different context and I
In SQLTransformer.java
public SQLTransformer() {
// FIXME (CZ) We have to get the correct encoding from
// somewhere else (XML Serializer?)
this.format = new Properties();
this.format.put(OutputKeys.METHOD, text);
this.format.put(OutputKeys.ENCODING,
I'm glad to see a healthy discussion about workflow. Here are my responses
to multiple posts.
Scope
-
I still think the scope of the project is the first thing that must be
decided upon before discussing which solution is the best. There are lots
of options here and covering them all is
-Original Message-
From: Alex Romayev [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 5:13 PM
To: [EMAIL PROTECTED]
Subject: [portal] Browser back button
It seems that clicking the back button on the browser causes
portal to behave incorrectly.
For example, in the
Good idea. I just committed the changes. You can now set the
encoding in the component configuration and as a sitemap parameter.
Thanks
Carsten
-Original Message-
From: roy huang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 16, 2004 11:14 AM
To: [EMAIL PROTECTED]
Subject:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
Geoff Howard wrote:
Modified:.status.xml
tools/targets webapp-build.xml
Log:
action dev=CZ type=fix fixes-bug=27217 due-to=Andreas
Hartmann due-to-email=[EMAIL PROTECTED]
Build System: Apply filtering to
Geoff Howard
Knowing that properties are already replaced, do you see a
purpose for this still?
Yes, filtering :) Just use a @loglevel@ in a patch file for the
logging configuration, and without the patch it doesn't work.
Now, if I understand it correctly now (I have to sort out the
Carsten Ziegeler wrote:
Geoff Howard
Knowing that properties are already replaced, do you see a
purpose for this still?
Yes, filtering :) Just use a @loglevel@ in a patch file for the
logging configuration, and without the patch it doesn't work.
Now, if I understand it correctly now (I
Upayavira wrote:
Carsten Ziegeler wrote:
Geoff Howard
Knowing that properties are already replaced, do you see a purpose
for this still?
Yes, filtering :) Just use a @loglevel@ in a patch file for the
logging configuration, and without the patch it doesn't work.
Now, if I understand it
Geoff Howard wrote:
Exactly. Although I didn't quite understand the bit about
adding a loglevel property for build.webapp.loglevel - it
already is a property isn't it?
Yes, but with a long and not so intuitiv name. That's why I
suggested the shorter form.
And that's the benefit of
I asked over a cocoon-user. Up til now 100% of them are saying remove
it *now*. (about 17 users responded) It was clearly stated the vast
amount of options lead more to confusion than they are helpful. ...as
we already know :)
If noone objects I'll remove both blocks either tonight or
Carsten Ziegeler wrote:
Geoff Howard wrote:
Exactly. Although I didn't quite understand the bit about
adding a loglevel property for build.webapp.loglevel - it
already is a property isn't it?
Yes, but with a long and not so intuitiv name. That's why I
suggested the shorter form.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27217.
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://issues.apache.org/bugzilla/show_bug.cgi?id=27518.
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://issues.apache.org/bugzilla/show_bug.cgi?id=27518.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Johan Stuyts wrote:
I'm glad to see a healthy discussion about workflow. Here are my
responses to multiple posts.
Scope
-
I still think the scope of the project is the first thing that must be
decided upon before discussing which solution is the best. There are
lots of options here and
Michael Wechner wrote:
Johan Stuyts wrote:
Conclusion
--
IMHO there should be more consensus about what is needed and what is
feasible in a relatively short time, e.g. half a year to a year.
I think building a generalized workflow based on a standard is too
ambitious. Leaving out
Torsten Curdt wrote:
I asked over a cocoon-user. Up til now 100% of them are saying
remove it *now*. (about 17 users responded) It was clearly stated
the vast amount of options lead more to confusion than they are
helpful. ...as we already know :)
If noone objects I'll remove both blocks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27709.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I asked over a cocoon-user. Up til now 100% of them are saying
remove it *now*. (about 17 users responded) It was clearly stated
the vast amount of options lead more to confusion than they are
helpful. ...as we already know :)
If noone objects I'll remove both blocks either tonight or
Michael Wechner wrote:
Johan Stuyts wrote:
Conclusion
--
IMHO there should be more consensus about what is needed and what is
feasible in a relatively short time, e.g. half a year to a year.
I think building a generalized workflow based on a standard is too
ambitious. Leaving out some
Torsten Curdt wrote:
I asked over a cocoon-user. Up til now 100% of them are saying
remove it *now*. (about 17 users responded) It was clearly stated
the vast amount of options lead more to confusion than they are
helpful. ...as we already know :)
If noone objects I'll remove both blocks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27518.
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://issues.apache.org/bugzilla/show_bug.cgi?id=27709.
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://issues.apache.org/bugzilla/show_bug.cgi?id=26924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Reinhard Ptz reinhard at apache.org writes:
Please don't forget to mention it our step in the documents.
You mean adding a removed since 2.1.5 to the wiki docu?
And IIRC there is official documentation available too. I think of a
warning box at the top.
I would prefer a real clean up
Joerg Heinicke wrote:
Reinhard Ptz reinhard at apache.org writes:
Please don't forget to mention it our step in the documents.
You mean adding a removed since 2.1.5 to the wiki docu?
And IIRC there is official documentation available too. I think of a
warning box at the top.
I would prefer a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
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://issues.apache.org/bugzilla/show_bug.cgi?id=27709.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg,
BTW, this would be a good use case for
@importance/@impact in status.xml. Was there any action on this after the
discussion about it?
Propose a vote, There was not any action after that :-)
I found this writeup about continuations and what state they should and
should not save. I am posting it here because it explains the concepts
and tradeoffs so clearly:
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=trueentry=3240140310
--Tim Larson
In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
Should this:
// 'wid' is a javascript wrapper of the Cocoon Form widget.
//
// Its subwidgets can be accessed by id.
be changed to this:
// 'wid' is a javascript wrapper of the Cocoon Form widget.
//
// The
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
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://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Today I got stuck using JXTG in what I thought would have been a quite
common use case. I have to generate a cforms definition file (a
selection list, actually) which is dynamically built from a bean that
returns a Map.
This beans (which, BTW, is an Avalon component) resides in the session,
Gianugo Rabellino wrote:
Today I got stuck using JXTG in what I thought would have been a quite
common use case. I have to generate a cforms definition file (a
selection list, actually) which is dynamically built from a bean that
returns a Map.
This beans (which, BTW, is an Avalon component)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I am trying to migrate to the v2 Form.js, but I am having trouble
understanding how the onValidate handling works. From reading to code
it looks to me like it would not work correctly, but the sample form
work properly. Could somebody explain how the interaction of the
regular validation, the
Guido Casper wrote:
Michael Wechner wrote:
Johan Stuyts wrote:
Conclusion
--
IMHO there should be more consensus about what is needed and what is
feasible in a relatively short time, e.g. half a year to a year.
I think building a generalized workflow based on a standard is too
On Tue, Mar 16, 2004 at 09:16:38PM +, Tim Larson wrote:
I am trying to migrate to the v2 Form.js, but I am having trouble
understanding how the onValidate handling works. From reading to code
it looks to me like it would not work correctly, but the sample form
work properly. Could
Stefano Mazzocchi wrote:
The existing code base might not satisfy everybody, but at least it's
something
concrete to start with, even if it will be totally modified resp.
refactored in the end.
100% agreement.
Doing design without a codebase takes forever on a open community
because it's
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25100.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi
Is there a version of lenay that is J2EE 1.3 compatible?
Regards
Joe
Joe Lozina wrote:
Hi
Is there a version of lenay that is J2EE 1.3 compatible?
no, only 1.4.x
Michi
Regards
Joe
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
[EMAIL PROTECTED]
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
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://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
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://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
On 17.02.2004 14:19, Derek Hohls wrote:
2. The map:parameter name=constraint-set value={2} /
entry in the sitemap should be
map:parameter name=validate-set value={2} /
(which I think is confusing, considering the tag is called
constraint-set, but
Joerg Heinicke wrote:
On 15.03.2004 17:57, [EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=27600
syntax for unique rows in repeater binding
--- Additional Comments From [EMAIL PROTECTED] 2004-03-15 16:57 ---
More and more I doubt that this might be the way
Joerg Heinicke wrote:
On 15.03.2004 19:37, [EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=27678
AbstractXMLProducer.setConsumer implementation is incorrect
The implementation of
org.apache.cocoon.xml.AbstractXMLProducer.setConsumer does
not match its Javadoc.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Does anybody know who made the excalibur-logger 1.1 source
distributions? They don't contain the source.
Ralph
I may be wrong, but it seems the current implementation of woody2.js
flowscript has a problem when using custom validation together with the
woody's built-in validation.
The following is the current fragment in question:
// Additional flow-level validation
if (finished
Hello Cocoon dev-dudes,
Believe it or not, people may sometimes still want or need to do some
client-side Javascript stuff... :-)
I set a window.onload handler in some client-side Javascript, but it
got stomped by the
body onload=forms_onload
added by the forms stylesheet.
I worked around by
On 17.02.2004 14:19, Derek Hohls wrote:
2. The map:parameter name=constraint-set value={2} /
entry in the sitemap should be
map:parameter name=validate-set value={2} /
(which I think is confusing, considering the tag is called
constraint-set, but anyway)
I have fixed
60 matches
Mail list logo
