Hi,
I startedthis thread before without success, here i try to describe it
better : i still can't use the upload widget in a cachingURI coplet of
the portal. (I'm in 2.1.6Release)
When i submit the form i get back with the same form and loose my
inputs. I seems to me there is a problem
David Crossley wrote:
Reinhard Poetz wrote:
David Crossley wrote:
[snip]
Perhaps we should step back a bit and assess the situation. It seems
a cumbersome process to double-handle all of the source docs, just to
add some specially-generated docs. Would it help to put these special
docs into a
This has been discussed on users@ already [1], just wanted to note it
here FYI.
Specifically, flowscript code such as
var shapeId = cocoon.request
switch (shapeId){
case square:
// dosomething
did not dosomething anymore when shapeId==square, although it worked
in past
Bertrand Delacretaz wrote:
Le 11 mars 05, à 00:10, Linden H van der (MI) a écrit :
...when I started the
form1.flow sample it gave me a blank page and a stacktrace in the
console about no such method..
I don't see this here, just did svn up and a full build of the
BRANCH_2_1_X, and
Bertrand Delacretaz wrote:
This has been discussed on users@ already [1], just wanted to note it
here FYI.
Specifically, flowscript code such as
var shapeId = cocoon.request
switch (shapeId){
case square:
// dosomething
did not dosomething anymore when shapeId==square,
Le 11 mars 05, à 09:55, Reinhard Poetz a écrit :
...I don't have an idea why switch doesn't work anymore. I was
thinking that it had never worked and in 2.2 the latest Rhino fixed
this bug ... but this seems to be a wrong assumption.
I'm positive that it did work, don't know exactly up to when
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=32491.
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=32491.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Reinhard Poetz wrote:
Upayavira wrote:
Reinhard Poetz wrote:
David Crossley wrote:
Perhaps we should step back a bit and assess the situation. It seems
a cumbersome process to double-handle all of the source docs, just to
add some specially-generated docs. Would it help to put these special
docs
Le 11 mars 05, à 10:58, Upayavira a écrit :
...Basically, I'm proposing we do the same with the generated docs as
we do with the blocks.properties file, generate them at 'change' time,
and commit the generated documents. ..
Sounds good, and being able to easily diff successive versions of these
Hi All
What is the trick for building the docs at the moment in 2.2.0?
I am getting:
BUILD FAILED
/Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/tools/targets/
docs-build.xml:54: DocDir
(/Users/jerm/Development/Checkouts/Apache/Cocoon/trunk/build/cocoon/
documentation/xdocs/userdocs) is
Le 11 mars 05, à 11:38, Jeremy Quinn a écrit :
...What is the trick for building the docs at the moment in 2.2.0?
AFAIK the docs target is temporarily broken, you have to exclude them
in build.properties
I've started collecting info about this at
I don't see this here, just did svn up and a full build of the
BRANCH_2_1_X, and
http://localhost:/samples/blocks/forms/form1.flow works
fine, and
the localized versions look ok as well.
Works for me also. Helma, you should try a build clean webapp, as
NoSuchMethodError
Thanks Bertrand
Do you know if there will continue to be xml docs in the build?
They are used by the Lucene and QueryBean samples as the source to make
a search index from.
regards Jeremy
On 11 Mar 2005, at 10:41, Bertrand Delacretaz wrote:
Le 11 mars 05, à 11:38, Jeremy Quinn a écrit :
...What
Le 11 mars 05, à 11:59, Jeremy Quinn a écrit :
Do you know if there will continue to be xml docs in the build?
AFAIK it's still being discussed, see the recent automatically
generating docs thread.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Bertrand Delacretaz wrote:
Le 11 mars 05, à 11:59, Jeremy Quinn a écrit :
Do you know if there will continue to be xml docs in the build?
AFAIK it's still being discussed, see the recent automatically
generating docs thread.
I would be reluctant to see the online docs go. It would be a shame, as
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 36
Jens Maukisch wrote:
Hi,
Just send the patch to this list - can you do this by the end of this
week as on monday the code freeze starts :)
Yes, I know, so here is the Patch for the I18nCatalogueGenerator.
I deleted the regex stuff and used the IncludeXMLConsumer instead.
Hopefully this
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=33962.
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=33963.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi all,
There are some flowscript use cases where we want to stop the current
flowscript without creating a continuation, as we don't want to the user
to go back to the script.
An example is a login function where the caller function expects this
function to exit only if login is successful,
Sylvain Wallez wrote:
Hi all,
There are some flowscript use cases where we want to stop the current
flowscript without creating a continuation, as we don't want to the user
to go back to the script.
An example is a login function where the caller function expects this
function to exit only if
Hi Cocoon devs,
in the process of moving the Lenya scheduler to Cocoon components,
I played a little bit with the cron block.
At first I tried to invoke a Lenya service from the scheduler by
obtaining the service directly via the ServiceableJob's service manager.
But this way I ended up with
Le 11 mars 05, à 15:18, Sylvain Wallez a écrit :
...This is currently possible using FOM_Cocoon.suicide() which is
what is used internally by cocoon.sendPageAndWait (see fom_system.js),
and I would like to make this more visible by being available as
cocoon.suicide().
It is not cocoon that is
Bertrand Delacretaz wrote:
Le 11 mars 05, à 15:18, Sylvain Wallez a écrit :
...This is currently possible using FOM_Cocoon.suicide() which is
what is used internally by cocoon.sendPageAndWait (see fom_system.js),
and I would like to make this more visible by being available as
cocoon.suicide().
Andreas Hartmann wrote:
Hi Cocoon devs,
in the process of moving the Lenya scheduler to Cocoon components,
I played a little bit with the cron block.
At first I tried to invoke a Lenya service from the scheduler by
obtaining the service directly via the ServiceableJob's service manager.
But this
Bertrand Delacretaz wrote:
Le 11 mars 05, à 15:18, Sylvain Wallez a écrit :
...This is currently possible using FOM_Cocoon.suicide() which is
what is used internally by cocoon.sendPageAndWait (see
fom_system.js), and I would like to make this more visible by being
available as cocoon.suicide().
Sylvain Wallez wrote:
Hi all,
There are some flowscript use cases where we want to stop the current
flowscript without creating a continuation, as we don't want to the user
to go back to the script.
An example is a login function where the caller function expects this
function to exit only if
Le 11 mars 05, à 16:17, Sylvain Wallez a écrit :
...suicide comes from Scheme, where continuations were born, and
therefore may not be obvious to our normal users ;-)
/me is normal then ;-)
...So what about the simple flow.exit()? ..
sounds good
...We could also start providing
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=33963.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 11 mars 05, à 15:18, Sylvain Wallez a écrit :
...This is currently possible using FOM_Cocoon.suicide() which is
what is used internally by cocoon.sendPageAndWait (see
fom_system.js), and I would like to make this more visible by being
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 11 mars 05, à 15:18, Sylvain Wallez a écrit :
...This is currently possible using FOM_Cocoon.suicide() which is
what is used internally by cocoon.sendPageAndWait (see
fom_system.js), and I would like to make this more
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
BTW, concerning what to call the object accessors, what about just
accessor, e.g. RequestAccessor, SessionAccessor etc.
RequestObjectAccessor or SessionObjectAccessor really would be too
verbose, but ObjectAccessor for the general interface
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
BTW, concerning what to call the object accessors, what about just
accessor, e.g. RequestAccessor, SessionAccessor etc.
RequestObjectAccessor or SessionObjectAccessor really would be
too verbose, but ObjectAccessor
Sylvain Wallez wrote:
I can agree that it seem to break some common ideas about good coding
practice. But we have been through the arguments and it seem OK. We
probably find out if it works when we start to implement and
integrate it.
Oh yes, sure. I totally agree with the concept. It's not a
I've noticed strange behavior with switch too (using Cocoon 2.1.5.1)...
for me, I was able to get it to work by making sure the object being
tested is a JavaScript String, as opposed to a Java String, e.g.:
switch (String(shapeId)) {...
I realize that doesn't solve the inconsistency issue
David's notes: see
below
Sylvain WallezThu, 24 Feb 2005
09:07:07 -0800
depub2 wrote:
Well,
what do you guys think? Does 7 days of silence amount to agreement??I'll
be happy to make any mods you suggest and resubmit source to you
forinclusion..
Added. When including your patch, I
At the last GT we agreed that our core should not depend on other
projects, so we wrote our own container and did not use an existing one.
We also said that on the application level, a user can use whatever
container she wants on top of Cocoon.
It seems that this is a good choice, as we don't
Sylvain Wallez wrote:
So what about the simple flow.exit()? I also though about
flow.kill() but it can convey the meaning of killing the current
continuation tree. There's also flow.stop() but it implies a possible
return which is not what we want.
We could also start providing
Hi all,
I encountered some weird things with a flowscript containing strings
with accented characters, saved in UTF-8. This is because the flow
interpreter uses the platform's default encoding to read script files.
And of course this default encoding isn't the same on Windows and Mac...
To
Sylvain Wallez wrote:
Hi all,
I encountered some weird things with a flowscript containing strings
with accented characters, saved in UTF-8. This is because the flow
interpreter uses the platform's default encoding to read script files.
And of course this default encoding isn't the same on
Just one clarification: I want to leave the core as it is, we use our
container and all the code we provide in the core is free of any other
container (apart from the glue code mentioned below)
Carsten
Carsten Ziegeler wrote:
At the last GT we agreed that our core should not depend on other
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I encountered some weird things with a flowscript containing strings
with accented characters, saved in UTF-8. This is because the flow
interpreter uses the platform's default encoding to read script
files. And of course this default
Hi Carsten,
Carsten Ziegeler wrote:
Just one clarification: I want to leave the core as it is, we use our
container and all the code we provide in the core is free of any other
container (apart from the glue code mentioned below)
just a pointer for container-free glue code:
Carsten Ziegeler writes:
Currently I see the need for two additional features:
a) a request listener - I want to be able to act on each request
comming into my sitemap; and in addition I would like to do something
when the request is finished which means *after* the serializer wrote
the
Le 11 mars 05, à 21:42, Sylvain Wallez a écrit :
Or even a more javadoc-like
// @encoding UTF-8...
Looks good.
Note that IIUC the same problem exists for java source files: unless
the -encoding switch is used for javac, the default platform encoding
is used to compile. Should we add it to
Carsten Ziegeler wrote:
At the last GT we agreed that our core should not depend on other
projects, so we wrote our own container and did not use an existing one.
We also said that on the application level, a user can use whatever
container she wants on top of Cocoon.
It seems that this is a good
Le 11 mars 05, à 19:45, Carsten Ziegeler a écrit :
...Now, I think we should help users in doing this. I'm currently
thinking
about directly supporting DCC on the application level and therefore
creating support for an application container (We can later on
decide if we support both, or just one
Le 11 mars 05, à 17:36, [EMAIL PROTECTED] a écrit :
...URL: http://svn.apache.org/viewcvs?view=revrev=157107
Log:
remove duplicate entry
(changes made to 2.1.7 *and* 2.2 are reflected in 2.1.7 section)...
Sorry about that - do you mean that changes made to both 2.1.x and 2.2
must be added only to
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I encountered some weird things with a flowscript containing strings
with accented characters, saved in UTF-8. This is because the flow
interpreter uses the platform's default encoding to read script files.
And of course this default
Marc Portier wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Hi all,
I encountered some weird things with a flowscript containing strings
with accented characters, saved in UTF-8. This is because the flow
interpreter uses the platform's default encoding to read script
files. And of
Carsten Ziegeler wrote:
At the last GT we agreed that our core should not depend on other
projects, so we wrote our own container and did not use an existing one.
We also said that on the application level, a user can use whatever
container she wants on top of Cocoon.
It seems that this is a good
Stefano Mazzocchi wrote:
how about
//@ encoding = UTF-8
instead? so that we can discriminate between comments and 'metadata
comments'?
had a similar reflex, but from a different angle though:
namely by considering how vim is doing this:
// vim: set fileencoding=iso-8859-1 nu ai:
so: I surely
Does this fix mean that handle-errors now works on internal pipelines as
well?
Ralph
[EMAIL PROTECTED] wrote:
Author: vgritsenko
Date: Fri Mar 11 12:47:16 2005
New Revision: 157153
URL: http://svn.apache.org/viewcvs?view=revrev=157153
Log:
Refactor sitemap error handling:
* Encapsulate error
Ralph Goers wrote:
Does this fix mean that handle-errors now works on internal pipelines as
well?
No, not yet, I need couple of more days. But it means that:
map:pipelines
map:pipeline
...
map:handle-errors/ (1)
/map:pipeline
map:handle-errors/ (2)
/map:pipelines
(2)
Bertrand Delacretaz wrote:
Le 11 mars 05, à 17:36, [EMAIL PROTECTED] a écrit :
...URL: http://svn.apache.org/viewcvs?view=revrev=157107
Log:
remove duplicate entry
(changes made to 2.1.7 *and* 2.2 are reflected in 2.1.7 section)...
Sorry about that - do you mean that changes made to both 2.1.x
Le 12 mars 05, à 03:28, Vadim Gritsenko a écrit :
...Changes made to both branch and tag, reflected both in branch
status.xml, and a trunk status.xml, *but* in the appropriate
section:..
Got it now, thanks!
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
57 matches
Mail list logo
