Joerg Heinicke wrote:
Ok, let me clarify. I think I do nothing unusual. Yes, I have a form
with a simple dynamic selection list. And I do the binding against a bean.
This is what I do all the time.
There are two known ways to set the selection list dynamically:
setSelectionList(String uri) and
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=26792.
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=27188.
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=27598.
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=25110.
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=27599.
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=25110.
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=27600.
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=25110.
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=27601.
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=25110.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
On 09.03.2004 13:43, Vadim Gritsenko wrote:
Yes, I see your objection - and asked for them already in the bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25934 ;)
So what are the practical use cases this might occure? Maybe it's
only a theoretical problem depending
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
As discussed recently, our internal redirects don't work the way one
would usually suspect. If you do an internal
redirect, like:
map:redirect-to uri=cocoon://some-pipeline/
and the called pipeline has an error, then the error handler
of the
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
...
I'd prefer not to pollute
request parameters with internal cocoon stuff. This reminds
me of recently fixed header action which was iterating over
sitemap parameters. Similarly, users may rely in theirs code
on request parameters and
Vadim Gritsenko wrote:
So, we have three choices to change this:
a) Make an internal redirect a real forward (This is an
incompatible change)
b) Make it configurable on the uri, like map:redirect-to
uri=cocoon://some-pipeline?cocoon:forward=true/
c) Make it configurable on
Joerg Heinicke wrote:
http://wiki.apache.org/cocoon/FAQs:
The list at the beginning is broken. The numbering of the sections is
also strange in the file: 1. 1. Meta-FAQ instead of 1. Meta-FAQ.
Fixed. I strip 1. from a title if I find it, as Moin adds it back.
Steven Noels wrote:
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=27602.
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=27602.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 09 Mar 2004, at 22:48, Brendan Eich wrote:
(some parts snipped - just trying to bring this to a solution
suggestion)
But I don't like this, of course. It wasn't our intention to fork,
we just ended up using a fork written by a Cocoon committer outside
the Cocoon project.
Forks are bad
Ugo Cei u.cei at cbim.it writes:
Ok, let me clarify. I think I do nothing unusual. Yes, I have a form
with a simple dynamic selection list. And I do the binding against a bean.
This is what I do all the time.
I thought so too :)
There are two known ways to set the selection list
Vadim Gritsenko wrote:
snip/
Why (a), (b), or (c) ? There is always option of (d):
d) Make it configurable on handle-errors element of the called
pipeline. This way, behavior of redirect-to does not need to be
changed, and this feature is more useful in general - especially in
portlets. Or
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=27604.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
Do you have a solution for the 'non-value' entry in the items collection? I use
the selection list as filter for the list pages. And I want to provide an option
to do no filtering by this selection list.
I usually do the following:
var collection =
Ugo Cei u.cei at cbim.it writes:
Do you have a solution for the 'non-value' entry in the items collection? I
use the selection list as filter for the list pages. And I want to provide an
option to do no filtering by this selection list.
I usually do the following:
var collection
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=27604.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
some samples require the ExtendedResourceExistsAction. Where went
this action?
Marged with ResourceExistsAction?
Thanks, Stephan.
Stephan Michels stephan at apache.org writes:
Hi,
some samples require the ExtendedResourceExistsAction. Where went
this action?
Marged with ResourceExistsAction?
I would assume this from the commit message:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/scratchpad/
[EMAIL PROTECTED] wrote:
Modified:tools/src blocks-build.xsl
Log:
Apply all xconf file in one shoot.
Ehm, are you sure that this works? The xconf's from the different
blocks have to be applied in the correct order (in the order
of their dependencies). If you all apply at once
Am Do, den 11.03.2004 schrieb Carsten Ziegeler um 16:48:
[EMAIL PROTECTED] wrote:
Modified:tools/src blocks-build.xsl
Log:
Apply all xconf file in one shoot.
Ehm, are you sure that this works? The xconf's from the different
blocks have to be applied in the correct order
Joerg Heinicke wrote:
On 05.03.2004 17:45, Marc Portier wrote:
Yes, I only see that wb:unique-row (grouped by type: unique or not
unique) is
outside of wb:on-bind (grouped by event: on-bind, on-insert,
on-delete) though
it is executed also at on-bind event.
yes, but do you find that
Hi,
I just updated my projects from woody to cocoon forms (absolutely
painless, BTW). Unfortunately now most of my projects are broken
anyhow, because they use XSP (ESQL), and I was not aware of the XSP
refactoring going on :(
Was it just a bad moment for CVS-update or does the move of XSP to
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=26753.
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=26753.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
leo leonid wrote:
Hi,
I just updated my projects from woody to cocoon forms (absolutely
painless, BTW).
How did you do the upgrade?
--
Reinhard
Am Do, den 11.03.2004 schrieb leo leonid um 18:24:
Hi,
I just updated my projects from woody to cocoon forms (absolutely
painless, BTW).
I see it similar, a simple s/woody/forms/g, and most of the work is
done. I doesn't see a real need to keep the woody block, but anyway...
Am Mi, den 10.03.2004 schrieb Unico Hommes um 19:24:
There remain a few issues that need resolving.
- InputModuleAction had to move along with xsp because it has a
dependency on some xsp helper class. This is unfortunate and maybe
unnecessary. Perhaps someone with more knowledge about this
On 11.03.2004 16:38, [EMAIL PROTECTED] wrote:
sylvain 2004/03/11 07:38:31
Modified:src/blocks/cron/java/org/apache/cocoon/components/cron
QuartzJobScheduler.java TestCronJob.java
QuartzJobExecutor.java
On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote:
leo leonid wrote:
Hi,
I just updated my projects from woody to cocoon forms (absolutely
painless, BTW).
How did you do the upgrade?
I used your ant task ($COCOON_HOME/build.sh
woody2CocoonForms-renaming). It did the job quite perfectly.
Joerg Heinicke wrote:
On 11.03.2004 20:18, [EMAIL PROTECTED] wrote:
Modified:src/blocks/forms/samples/resources
forms-field-styling.xsl
Log:
add text attribute (any reason why it is missing?)
I guess not, it's just the default.
Joerg
Okay, I added it because I want to use it to be
leo leonid wrote:
On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote:
leo leonid wrote:
Hi,
I just updated my projects from woody to cocoon forms (absolutely
painless, BTW).
How did you do the upgrade?
I used your ant task ($COCOON_HOME/build.sh
woody2CocoonForms-renaming). It did the job
On 11.03.2004 13:23, Vadim Gritsenko wrote:
startElement a
character 'key'
startElement b
character 'word'
Will become keyword instead of key word. No, this won't work, again :-)
Addition of
startElement:
if (flag)
x.append(' ');
flag = false;
Should fix it, shouldn't it?
This
On Mar 11, 2004, at 8:35 PM, Reinhard Pötz wrote:
leo leonid wrote:
On Mar 11, 2004, at 6:50 PM, Reinhard Pötz wrote:
leo leonid wrote:
Hi,
I just updated my projects from woody to cocoon forms (absolutely
painless, BTW).
How did you do the upgrade?
I used your ant task
[EMAIL PROTECTED] wrote:
joerg 2004/03/11 11:42:32
Modified:tools/targets upgrade-build.xml
Log:
a little mistake
Revision ChangesPath
1.4 +1 -1 cocoon-2.1/tools/targets/upgrade-build.xml
Index: upgrade-build.xml
Joerg Heinicke wrote:
On 11.03.2004 16:38, [EMAIL PROTECTED] wrote:
sylvain 2004/03/11 07:38:31
Modified:src/blocks/cron/java/org/apache/cocoon/components/cron
QuartzJobScheduler.java TestCronJob.java
QuartzJobExecutor.java
On 10 Mar 2004, at 19:51, Steven Noels wrote:
(OT for the non-ASF folks:) You seem to suggest that inclusion of
non-ASL-licensed library dependencies inside ASF distributions should
be deprecated, favoring a CPAN or FreeBSD ports -like mechanism
instead. This will definitely lower the ease of
On 11.03.2004 22:57, Sylvain Wallez wrote:
quoting Eclipse: The private field QuartzJobScheduler.jobEnvironment
is never read locally.
Is it needed?
Well, if Eclipse says no, I guess it's right ;-)
Seriously, this refactoring went through several iterations and the
location of the environment
Joerg Heinicke wrote:
On 11.03.2004 13:23, Vadim Gritsenko wrote:
startElement a
character 'key'
startElement b
character 'word'
Will become keyword instead of key word. No, this won't work,
again :-)
Addition of
startElement:
if (flag)
x.append(' ');
flag = false;
On 11.03.2004 20:50, Joerg Heinicke wrote:
Replace the startElements in your sample with endElements and it won't
work. But adding if(flag) like above additionally to endElement should
fix this. Did we get it now? :)
I have it done like the following
characters
flag = true
endElement
On 12.03.2004 00:18, Vadim Gritsenko wrote:
Yes, note that I wrote addition above - in addition to your suggestion:
Sorry, missed that obviously.
Joerg
On 11.03.2004 17:31, Marc Portier wrote:
All together we are at:
fb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath
fb:identity
fb:value id=myId1 path=myId1/
fb:value id=myId2 path=myId2/
/fb:identity
fb:on-bind
fb:value id=field1 path=field1/
fb:value id=field2
Le Jeudi, 11 mars 2004, à 23:06 Europe/Zurich, Paul Russell a écrit :
On 10 Mar 2004, at 19:51, Steven Noels wrote:
(OT for the non-ASF folks:) You seem to suggest that inclusion of
non-ASL-licensed library dependencies inside ASF distributions should
be deprecated, favoring a CPAN or FreeBSD
Bertrand Delacretaz wrote:
Le Jeudi, 11 mars 2004, à 23:06 Europe/Zurich, Paul Russell a écrit :
On 10 Mar 2004, at 19:51, Steven Noels wrote:
(OT for the non-ASF folks:) You seem to suggest that inclusion of
non-ASL-licensed library dependencies inside ASF distributions
should be deprecated,
Stephan Michels wrote
Ehm, are you sure that this works? The xconf's from the different
blocks have to be applied in the correct order (in the
order of their
dependencies). If you all apply at once this is imho not
guarenteed,
right?
Now it should work. I rewrote the XConfTask.
53 matches
Mail list logo
