[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8 12:25:12 2005
New Revision: 169150
URL: http://svn.apache.org/viewcvs?rev=169150view=rev
Log:
share root rhino scope
Modified:
cocoon/trunk/src/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java
Modified:
FYI it is not thread-safe to use a static rhino scope. Instead the
caller of the template should should pass this from his own session. I
think this same bug also exists in the CForms implemenation but I'm not
sure.
Regards,
Chris
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May 8
through the prototype link.
HTH,
Chris
Christopher Oliver wrote:
FYI it is not thread-safe to use a static rhino scope. Instead the
caller of the template should should pass this from his own session. I
think this same bug also exists in the CForms implemenation but I'm not
sure.
LOL. I based my
You know what? I'm fed up with this discussion, and will start writing a
new implementation of the JS flowscript engine. People will have the
choice. And Chris will stop popping up as soon as someone touches his code.
Sylvain
Very nice display of community leadership...
I have no problem with
Christopher Oliver wrote:
Sorry to pick on Sylvain again, but he consistently exhibits a common
behavior of Java programmers with respect to JavaScript. Because JS
syntax is so similar to Java they seem to feel a JS API is somehow
better the more it resembles what it would look like
Christopher Oliver wrote:
At any rate, I fail to understand how a massively non-backward
compatible change can be made which was not even relevant to the subject
voted on.
yes please, can we discuss this again (with a final vote) as I'm not really
convinced about the pros of this change.
As I
This is a tradeoff: by combining properties you get easer access to
commonly used properties, but however at the cost of overloading the
identifiers at times. Note that it's always possible to provide an
escape mechanism to disambiguate such cases, even if DOM didn't do
that in this case.
Christopher Oliver wrote:
snip/
Mmmh... you're right, there _wasn't_ such a property before my
changes. This explains the lengthy wrapping code that was in
FOM_Request that exposed only functions and no properties except the
request parameters (or attributes for session and context).
Now
Sorry to pick on Sylvain again, but he consistently exhibits a common
behavior of Java programmers with respect to JavaScript. Because JS
syntax is so similar to Java they seem to feel a JS API is somehow
better the more it resembles what it would look like if it was written
in Java.
The
Oh, really? The license on my code is (and always was) MIT (i.e. more
lenient than Apache) . If there is a problem with that then you also
have a problem with Torsten's project (which is obviously based on my code).
I don't see any reason why you shouldn't remove it in favor of Torsten's
If you ask me, this is mainly a semantic problem, not a technical one.
If a template is not called from a (Javascript) flowscript, there is no
FOM, and therefore no FOM variables are available in JXTG. For the case
where it _is_ called from a flowscript, then the FOM is and IMO should
be
Christopher Oliver wrote:
snip/
Let's face it: your code is dense as a neutron star and dense of
comments and tests as the the outter space around one.
For what it's worth I do like _your_ writing style above.
snip
Your respect/care for the complexity of the social dynamics
Christopher Oliver wrote: It's not personal, Bertrand. If someone
does good work or makes a valid point I will give them proper
respect. If not, well, I'm not teaching grade school and it's not my
job to sugar coat it.
Really? Wasn't that you that disliked the way Pierpaolo and myself
I recently took a look at this mailing list after I happened to talk to
Stefano in person (he was in LA) and noticed a _few_ posts about
refactoring JXTemplateGenerator.
Of course you can do what you like, but just so you know, here is my
point of view:
Obviously it would have been easy to
Le 10 déc. 04, à 17:29, Christopher Oliver a écrit : ...The funniest
post of all was this
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110210971210386w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110210971210386w=2.
I mean, give me break. That is just plain silly
Sorry
I'm no longer particpating in Cocoon development. Please post any
questions regarding Cocoon to the dev mailing list.
Thanks,
Chris
[EMAIL PROTECTED] wrote:
Hello,
sorry to bother you in private, but you're my last hope of finding the
solution to my problem. I've posted my problems on the
Ugo Cei wrote:
Il giorno 24/apr/04, alle 23:35, [EMAIL PROTECTED] ha scritto:
coliver 2004/04/24 14:35:35
Modified:src/java/org/apache/cocoon/generation
JXTemplateGenerator.java
Log:
Allow a nodeset to be returned as the result of xpath evaluation
Before
Bruno Dumon wrote:
I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more
I've checked in a fix for this. The next event after a /jx:parameter
was being ignored. The bug was unnoticeable in many cases however
because in such cases that event was just whitespace. Thanks for
reporting the problem.
Chris
Bruno Dumon wrote:
While using the template.jx macros for
This is due to the behavior of JXPath. If you want to process a node set
you need forEach:
?xml version=1.0 encoding=utf-8?
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
content
jx:forEach select=#{document/root/path/fileset}/
#{.}
/jx:forEach
Tony Collen wrote:
Leszek Gawron wrote:
Say you have this DOM you pass to a template:
?xml version=1.0?
root
property file=user.properties /
path id=all.cp
pathelement location=${build.classes} /
fileset dir=${cocoon.lib}
include name=*.jar/
/fileset
fileset
Leszek Gawron wrote:
Sorry to bother you privately but I did not get the answer on cocoon group and
I see you're the main JXTG developer.
My question is: Is there any real reason that jx:attribute is not implemented?
Something that would work as xsl:attribute or xsp:attribute to allow
generation
There's not enough information in that bug report to determine the
problem. Can you try to debug why a URLSource (with exists() == true) is
being returned by the source resolver for the (presumably nonexistent)
resource org.java?
I had no luck debugging this since I can't recreate the problem
Leszek Gawron wrote:
Am I wrong or there is no way to handle iterators in JXTG? One can use forEach
for collections but I sometimes would like to pass and iterator to a view to
process larger result sets.
In Hibernate you can:
var list = session.createQuery(from LargeTable).list() which creates
Ive just committed a fix for this.
Regards,
Chris
Leszek Gawron wrote:
On Wed, Apr 21, 2004 at 12:45:46PM -0700, Christopher Oliver wrote:
Leszek Gawron wrote:
Am I wrong or there is no way to handle iterators in JXTG? One can use
forEach
for collections but I sometimes would like
Reinhard Poetz wrote:
snip
I already said in several mails that we should reduce the recommended
options:
1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take
(In my opinion
Ugo Cei wrote:
Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
I think you can use a combination of session attributes and jx macros
to get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute(stringToSAX, toSAX);
So
No. That won't work. With the current implementation of JXTG XPath
evaluation of absolute paths with a forEach only works if the
expression passed to forEach is an XPath expression. Does this work:
jx:forEach var=something items=#{myList}
#{//foo/bar}
/jx:forEach
Chris
Stephan Coboos
Sylvain Wallez wrote:
Christopher Oliver wrote:
I can't say that I fully understand your problem, but I just looked
at o.a.c.f.util.JavascriptHelper, and that appears to have some major
bugs. If it isn't called from a flow script it uses a static
JavaScript object as the top level scope
I think you can use a combination of session attributes and jx macros to
get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute(stringToSAX, toSAX);
function myPage() {
...
sendPage(page.html, {...});
}
// template
jx:macro
I can't say that I fully understand your problem, but I just looked at
o.a.c.f.util.JavascriptHelper, and that appears to have some major bugs.
If it isn't called from a flow script it uses a static JavaScript object
as the top level scope (where JS global variables are created), but does
not
I just committed a fix to ScriptableWidget to allow you to pass a null
validation error.
HTH,
Chris
Mark Lundquist wrote:
On Apr 14, 2004, at 12:55 PM, Joerg Heinicke wrote:
On 14.04.2004 21:48, Mark Lundquist wrote:
As I wrote before I'm nearly sure it works for me with woody2.js.
How are
Leszek Gawron wrote:
snip
none of these is strictly connected to the form (the only one is the rowset
displayed as the form controls invoke actions that change this part of view).
In v2 I have to do something like this:
form = new Form( definition );
form[ globalAppContext ] =
Tim Larson wrote:
On Tue, Apr 06, 2004 at 12:30:03PM +0200, Leszek Gawron wrote:
In v2 I have to do something like this:
form = new Form( definition );
form[ globalAppContext ] = getGlobalAppContext();
form[ user ] = getLoggedInUser();
form[ userContext ] = getContextForUser(
Bruno Dumon wrote:
On Mon, 2004-04-05 at 13:28, Sylvain Wallez wrote:
snip/
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
- move to a generator approach.
WDYT?
For the generator-approach, a good starting point would be to commit
Bruno Dumon wrote:
On Tue, 2004-04-06 at 18:19, Christopher Oliver wrote:
Bruno Dumon wrote:
snip
For the generator-approach, a good starting point would be to commit it
to CVS and add or change an example to show how it works.
I've done this for the V2 flowscript sample
will again unwind the current JVM
stack, but this time there's no need to capture it.
Chris
Christopher Oliver wrote:
Stephan Michels wrote:
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 4:42:
The current implementation needs some work to qualify as
generalized Java continuations
Stephan Michels wrote:
First, I'm glad to hear more input ;-) Your mail took some time
to parse it.
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 18:47:
OK, IIUC there are three modes of execution of the instrumented code:
1) isCapturing
During this mode the JVM call stack is unwound
Uh, thanks. But Leszek is talking about the JS function
handleContinuation() defined in fom_system.js - not the Java method that
you point out. That method is not accessible to flowscripts.
Chris
Tony Collen wrote:
Tony Collen wrote:
Christopher Oliver wrote:
Leszek Gawron wrote
Leszek Gawron wrote:
On Sat, Apr 03, 2004 at 01:58:51PM -0800, Christopher Oliver wrote:
These ContinuationsManager API should _not_ be used in a flowscript. Use
the sitemap to invoke your continuation, please.
Is it possible to solve your problem by using a helper function to send
the page
Stefano Mazzocchi wrote:
Antonio Gallardo wrote:
Hi:
Hi:
Some of us wanted to see Groovy support in Cocoon. Now we can play a
little with Groovy using the recently added support for Groovy script
generator under the BSF block. More info about how to use it is here:
for generalized Java continuations rather than hack it into
the language.
-Brian
On Apr 4, 2004, at 2:32 PM, Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Antonio Gallardo wrote:
Hi:
Hi:
Some of us wanted to see Groovy support in Cocoon. Now we can
play a
little with Groovy using the recently
These ContinuationsManager API should _not_ be used in a flowscript. Use
the sitemap to invoke your continuation, please.
Is it possible to solve your problem by using a helper function to send
the page:
function sendPageAndWait(uri, biz, ttl) {
cocoon.response.setHeader( Expires, -1 );
Sylvain Wallez wrote:
Christopher Oliver wrote:
These ContinuationsManager API should _not_ be used in a flowscript.
Use the sitemap to invoke your continuation, please.
Although I found this hacky, is there any technical reasons that
prevents this to work?
Sylvain
Yes, the FOM_Cocoon
Stephan Coboos wrote:
Is it a bug? Should I post it in the bugtracker?
It's a bug. The ServiceManager isn't initialized when you run
JXTemplateGenerator as a transformer. I'll commit a fix shortly.
Chris
http://marc.theaimsgroup.com/?t=107083319900025r=1w=2
Carsten Ziegeler wrote:
Just curious, I just noticed that the JXTemplateGenerator stores
FOM objects in the context that can then be addressed by the expressions,
like this:
cocoon.put(request,
Sylvain Wallez wrote:
Bruno Dumon wrote:
I found the possibility to add arbitrairy attributes to widgets, made
possible in the v2 forms flowscript integration, to be a quite nice
feature. However, that feature only exists in the javascript model. This
is a problem when one wants to pass back the
Sounds like a bug. Can you post the stack trace?
Thanks,
Chris
Stephan Coboos wrote:
Hello,
the element jx:import uri=.../ doesnt work in
JXTemplateTransformer. If I'am using this element I got a
java.lang.NullPointerException. In the JXTemplateGenerator instead it
works fine. Is it a bug?
Torsten Curdt wrote:
Dear friends and folks,
as already announce on the PMC list we now
have another flow implementation for java!
Stephan completed my proof-of-concept and
replaced the Brakes stuff by an own
implementation. So we are now fully in
ASL land.
Cool.
We would like to commit this
Will the new block system allow plugging in a block's documentation? One
of the things I find most annoying about adding code to the Cocoon Forms
block is that there seems to be no reasonable place to put documentation
- or am I missing something?
Chris
-Original Message-
From: Stefano
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Why is there a need to have a different API for widgets when used
from JS than when used from Java? IMO, this is arbitrarily
limiting the features available in flowscript.
But isn't this our design approach? If I remember
Sylvain Wallez wrote:
Christopher Oliver wrote:
Tim Larson wrote:
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
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
Tim Larson wrote:
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
The problem (I think) is that he is trying to use JXTG in a pipeline
called from the Form constructor, e.g.
var form = new Form(cocoon:/whatever);
However, the cocoon variable in JXTG is only set up when the pipeline
is called from a Flowscript via cocoon.sendPage*().
Vadim raised this issue
Tim Larson wrote:
On Thu, Mar 18, 2004 at 02:33:51PM +, Tim Larson wrote:
On Wed, Mar 17, 2004 at 02:31:53PM -0800, Christopher Oliver wrote:
Tim Larson wrote:
On Wed, Mar 17, 2004 at 11:18:35AM -0800, Christopher Oliver wrote:
Tim Larson wrote:
On Tue, Mar
Tim Larson wrote:
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
Tim Larson wrote:
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.
//
Tim Larson wrote:
On Wed, Mar 17, 2004 at 11:18:35AM -0800, Christopher Oliver wrote:
Tim Larson wrote:
On Tue, Mar 16, 2004 at 09:16:38PM +, Tim Larson wrote:
One of the specific questions is in this code:
var wk = cocoon.sendPageAndWait(uri, this.formWidget_, fun, ttl);
var
Steven Noels wrote:
On 08 Mar 2004, at 23:09, Stefano Mazzocchi wrote:
unless donated by the well-known friendly-neightbor-organization
directly, that is.
I took the plunge and started talking. See my other mail.
/Steven
Hopefully that will lead to something productive. However, it still
In order to allow the use of Flowscript on the BEA Weblogic and IBM
Websphere application servers (and possibly in other environments) I
propose that we rename the Rhino packages from org.mozilla to
org.cocoondev. The Rhino codebase used in Cocoon is currently hosted on
cocoondev.org
Can we also get rid of the original Woody flowscript API as part of this
process (and replace it with the v2 version)? The original was clearly
not ready for prime time.
--
Chris
Reinhard Pötz wrote:
In the next few days I'm going to rename Woody to Cocoon Forms. So
please don't commit into
can be called from the macro.
Chris
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Can we also get rid of the original Woody flowscript API as part of
this process (and replace it with the v2 version)? The original was
clearly not ready for prime time.
This new API, does it allow creation
You could use the JXTemplate generator to do this without Java
programming:
jx:macro name=iterate
jx:parameter name=times/
jx:forEach start=1 end=${times}
jx:evalBody/
/jx:forEach
/jx:macro
--
Chris
-Original Message-
From: Stephan Coboos [mailto:[EMAIL PROTECTED]
Sent:
Stephan Coboos wrote:
Christopher Oliver wrote:
You could use the JXTemplate generator to do this without Java
programming:
jx:macro name=iterate
jx:parameter name=times/
jx:forEach start=1 end=${times}
jx:evalBody/
/jx:forEach
/jx:macro
--
Chris
Thank you, Chris. But I need to write my
Can you try reverting the rhino jar to a previous version and see if
that fixes the problem? I may have introduced a regression.
Thanks,
Chris
Jeremy Quinn wrote:
Hi All
I just upgraded my copy of Cocoon to today's CVS version.
A (previously working) site that uses a lot of FlowScript has
I'm unable to recreate this problem. Can you provide more information?
--
Chris
Mark Lundquist wrote:
Hi,
(I'm using Cocoon 2.1.3...)
I have something like this in a JXTemplate:
jx:formatDate value=${theDate} /
and it barfs:
Cannot format given Object as a Date
But if I change the template
What error did you get with repository? It is not a JS keyword.
Chris
[EMAIL PROTECTED] wrote:
unico 2004/02/25 01:48:35
Modified:src/blocks/slide/samples flow.js
Log:
rhino seems to barf on 'repository' keyword
Revision ChangesPath
1.12 +1 -2
Stephan Coboos wrote:
Hello,
in some discussions I'd heard that actions and XSP should be more and
more replaced by flowscript. I think, this is a good idea because
flowscript is a good way to integrate logic parts into an application.
But with one thing I cant agree. Why shouldn't it be
I'm not sure how this got broken in 2.1.4 but one way to fix it is to simply remove the flow-interpreters line from components:
map:components
map:generators default=file
!-- in this example we use JXTemplateGenerator to insert
Flow variables in page content --
map:generator
Bertrand Delacretaz wrote:
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be slower
than interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level), but was significantly
Christopher Oliver wrote:
Bertrand Delacretaz wrote:
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a
écrit :
...I did some informal tests and it appears to actually be slower
than interpreted Rhino (not sure exactly why, perhaps because Rhino
bytecodes are higher level
I recently took a look at joeq (http://joeq.sourceforge.net/) which is a
Java virtual machine written in Java. Included is a reflective Java
interpreter that can run on top of an existing Java virtual machine
(e.g. Sun JRE). It can interpret class files, but can also delegate some
(or all)
What do you think of renaming the Rhino packages in the cocoondev.org
version of Rhino used by Cocoon? It appears both Weblogic and Websphere
ship their own versions of Rhino that are exposed to the class loader
used by Cocoon. This prevents using flowscript out-of-the-box or at
all with these
Vadim Gritsenko wrote:
Hi all,
Documentation [1] states that JXTemplate generator has cocoon.request
/ cocoon.session / etc variables declared to access
request/session/etc. And, that it has request / session / etc
variables that also provide access to the similar objects.
Now, the issue is
:
Gianugo Rabellino wrote:
Christopher Oliver wrote:
That is a problem with JXPath. I may be wrong, but if IIRC it
doesn't support namespaces properly or at all.
Bad bad news. Actually it seems to do selections just fine, but
insertions are flawed. OK, time for tricks then :-/
AFAIK, even
I noticed the Petstore and Linotype samples were both broken _after_ the
release. I'm not sure what caused this but it'd probably be a good idea
to test all the samples before releasing next time. BTW Linotype is
still broken.
Regards,
Chris
That is a problem with JXPath. I may be wrong, but if IIRC it doesn't
support namespaces properly or at all.
Gianugo Rabellino wrote:
... I still consider myself quite a newbie on Woody, but I'm facing a
tough issue. I need to bind a woody form to some namespaced XML (a
IIRC, 2.1.2 contains a Rhino regression (I introduced) that breaks flow
completely.
Bertrand Delacretaz wrote:
Did I miss something, or is there a good reason why 2.1.2 is not
available for download anymore on our mirrors?
-Bertrand
Saw this on lenya-dev:
De: Gregor J. Rothfuss [EMAIL
Ugo Cei wrote:
Dear friends,
I'm experiencing a memory leak in an application we are currently
testing, which uses Flowscript and Woody. Since continuations store a
reference to local variables, and the memory leak does not manifest
itself if I don't create any continuation, I'm starting to
Do you have global variables in your scripts?
Ugo Cei wrote:
Christopher Oliver wrote:
Ugo Cei wrote:
I'm experiencing a memory leak in an application we are currently
testing, which uses Flowscript and Woody. Since continuations store
a reference to local variables, and the memory leak does
Ugo Cei wrote:
Christopher Oliver wrote:
Ugo Cei wrote:
I'm experiencing a memory leak in an application we are currently
testing, which uses Flowscript and Woody. Since continuations store
a reference to local variables, and the memory leak does not
manifest itself if I don't create any
Vadim Gritsenko wrote:
Antonio Gallardo wrote:
jxforms are deprecated. if you are starting avoid using jxform.
Actually, only xmlform block is officially deprecated (see
block.properties).
Now, if you think that it should be deprecated, you can start
discussion in this thread :-)
Vadim
I don't think Rhino supports overloading of jsFunction_xxx(). The two
jsFunction_setSelectionList() functions need to be merged into one method.
HTH,
Chris
Steven Noels wrote:
Hi,
I have an interesting issue that I'd like to see confirmed, since we
suspect Rhino behaves differently under
Sylvain Wallez wrote:
snip
I made no answer to your recent addition to Woody because of lack of
time, but will do it very soon (it contains very interesting stuff).
Ok. No pressure.
I do think, however, that the flowscript integration should just be an
/integration/ and not an extension. By
From your description, sounds like someone extended a class provided by
the container which is declared final in Tomcat but not in Jetty. Can
you set a breakpoint on VerifyError and find out which class it is?
Hunsberger, Peter wrote:
Christopher Oliver [EMAIL PROTECTED] writes:
sendPage
{
InputStream is = src.getInputStream();
if (is == null) {
return null;
}
...
Hunsberger, Peter wrote:
Christopher Oliver [EMAIL PROTECTED] writes:
From your description, sounds like someone extended a class
provided by
the container which
Hunsberger, Peter wrote:
Christopher Oliver [EMAIL PROTECTED] asks:
sendPage*() is not reentrant in 2.1.3. I believe this has
been fixed in
2.1.4-dev. Can you try it?
Ok, now have 2.1.4-dev from last night working. It only runs as an
expanded EAR file (we deploy Cocoon in an EAR
Hunsberger, Peter wrote:
Christopher Oliver [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Christopher Oliver [EMAIL PROTECTED] asks:
sendPage*() is not reentrant in 2.1.3. I believe this has
been fixed in
2.1.4-dev. Can you try it?
Ok, now have 2.1.4-dev
Feel free to add it..
Tony Collen wrote:
Antonio Gallardo wrote:
Christopher Oliver dijo:
Antonio, that wasn't a typo. It is supposed to indicate one or more.
Sorry. I understand now. The + was written in the sense of lex
tokens
or regular expressions as grep, perl, etc. To me
Joerg Heinicke wrote:
Christopher Oliver res1cf5x at verizon.net writes:
JS Number is a double according to the specification. ScriptableWidget
provides coercions that allow you to write:
offset.value = 0;
See the sample I recently committed.
Ok, I had a look
Sorry about that. Thanks for fixing.
[EMAIL PROTECTED] wrote:
cziegeler2004/01/30 02:00:12
Modified:src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/v2
ScriptableWidget.java
Log:
Make cocoon compilable again - please cross-check the change
JS Number is a double according to the specification. ScriptableWidget
provides coercions that allow you to write:
offset.value = 0;
See the sample I recently committed.
Regards,
Chris
Joerg Heinicke wrote:
On 28.01.2004 18:21, Carlos Chávez wrote:
i am think this is related with the
Sorry, my bad. Should be fixed now.
Bertrand Delacretaz wrote:
Current CVS does not compile here, looks like the
PageLocalScopeHolder class source code is missing:
src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_Cocoon.java:238: cannot resolve symbol
symbol : class
SISC http://sisc.sourceforge.net
Brian McCallister wrote:
Which scheme implementation was used for the original implementation
of flow, or did somebody create their own?
Is it still available?
Thanks!
-Brian
I've just checked in some experimental improvements to the Woody
Flowscript API and an associated sample. Because the changes are not
backward compatible I've placed the files in a new package.
The idea is to try to remove the duplication present in the current API
in two places:
1) The
Can you provide an example stack trace? AFAIK JXTemplateGenerator wraps
an exception it catches in a SAXParseException. The original exception
should still be available through SAXException.getException().
Upayavira wrote:
We've built a quite large set of Java objects that are handled by flow
Ok, I just committed changes that implement createWebContinuation().
The support for continuation local variables is also included.
Regards,
Chris
Vadim Gritsenko wrote:
Christopher Oliver wrote:
There is a disadvantage to that approach, however, namely that it
creates new WebContinuations
OK. This occurs if you incorrectly call sendPage() more than once in the
same invocation of your flowscript. If I have time, I'll try to put in a
better error message.
Christopher Oliver wrote:
I get the below exception occasionally. Any ideas?
org.apache.cocoon.ProcessingException: Generator
of WebContinuations exactly matches the sequence of pages
(regardless of whether the page redisplayed, as in for example Woody's
validation loop), making back button handling easy.
Regards,
Chris
Sylvain Wallez wrote:
Christopher Oliver wrote:
OK, I got you. What you want is a continuation
Vadim Gritsenko wrote:
Christopher Oliver wrote:
There is a disadvantage to that approach, however, namely that it
creates new WebContinuations when you redisplay the page (i.e. when
sendPageAndWait is called again). The approach I suggested reuses the
same WebContinuation. Reusing the same
1 - 100 of 235 matches
Mail list logo
