I am working on a webapp using Cocoon 2.1.11 with Tomcat 7.0. I recently began
using the Cocoon Flow Debugger to help debugging our flowscript. To get it
working correctly, I needed to run the Tomcat7.exe program, instead of the
Tomcat service we had previously been using, with the debugger
that uses flow scripts. Almost all web server socket
listener threads at this time shows the point listed below:
Thread [SocketListener0-24] (Suspended)
FOM_JavaScriptInterpreter.setupContext(Redirector, Context,
FOM_JavaScriptInterpreter$ThreadScope) line: 571
Is this a bug or is aggregation of flow-content a bad idea?
Best regards,
Sebastian Kruse
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[
https://issues.apache.org/jira/browse/COCOON-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Lundquist updated COCOON-1384:
---
Attachment: (was: patch)
[PATCH] flow redirector should allow explicit 'cocoon
/flow/java/test/FlowTest.java
cocoon/branches/BRANCH_2_1_X/src/blocks/javaflow/test/org/apache/cocoon/components/flow/java/test/InheritanceFlowTest.java
Sorry for the oversight and thanks for the fix.
Joerg
On 01.04.2008 02:21, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Mon Mar 31 23:21:53 2008
New Revision: 643295
URL: http://svn.apache.org/viewvc?rev=643295view=rev
Log:
Fix synchronization issues in ContinuationsManager implementation.
Refactored version for 2.2 will follow this week ...
On Apr 1, 2008, at 2:17 AM, [EMAIL PROTECTED] wrote:
fix threading issue (DateFormat is not thread-safe)
public String getLastAccessTime() {
-return formatter.format(new Date(wc.getLastAccessTime()));
+synchronized (this.formatter) {
+return formatter.format(new
On 01.04.2008 08:02, Vadim Gritsenko wrote:
fix threading issue (DateFormat is not thread-safe)
public String getLastAccessTime() {
-return formatter.format(new Date(wc.getLastAccessTime()));
+synchronized (this.formatter) {
+return formatter.format(new
On 30.03.2008 22:19, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Sun Mar 30 19:19:41 2008
New Revision: 642855
URL: http://svn.apache.org/viewvc?rev=642855view=rev
Log:
fix synchronization
Can you please review this [1]? It's too easy to mess this up ... I hope
I did not introduce any
Hi Vadim
Is there any special reason to mount this block sample not like all others at
/cocoon-{block}-sample but at
/samples/chaperon?
Thanks
Felix
bean name=org.apache.cocoon.chaperon.sample.servlet
class=org.apache.cocoon.sitemap.SitemapServlet
-servlet:context
Felix Knecht wrote:
Hi Vadim
Is there any special reason to mount this block sample not like all others at
/cocoon-{block}-sample but at
/samples/chaperon?
Yes! It makes more sense! :) If you have not noticed, it is not the only block
mounted under /samples - it is just one more joining the
Retrieving mimeType returned by pipeline executed from Flow
---
Key: COCOON-2100
URL: https://issues.apache.org/jira/browse/COCOON-2100
Project: Cocoon
Issue Type: Improvement
mimeType returned by pipeline executed from Flow
---
Key: COCOON-2100
URL: https://issues.apache.org/jira/browse/COCOON-2100
Project: Cocoon
Issue Type: Improvement
Components
[
https://issues.apache.org/jira/browse/COCOON-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nils Kaiser updated COCOON-2100:
Other Info: [Patch available]
Retrieving mimeType returned by pipeline executed from Flow
to SitemapSource.
Retrieving mimeType returned by pipeline executed from Flow
---
Key: COCOON-2100
URL: https://issues.apache.org/jira/browse/COCOON-2100
Project: Cocoon
Issue Type
Jeff Schmitz said the following on 8/6/07 22:10:
There is an error in the flowscript tutorial.
http://cocoon.apache.org/2.1/userdocs/flow/tutor.html
The game.js code shows the following call:
cocoon.sendPageAndWait(guess.jxt, { random : random, hint : hint
There is an error in the flowscript tutorial.
http://cocoon.apache.org/2.1/userdocs/flow/tutor.html
The game.js code shows the following call:
cocoon.sendPageAndWait(guess.jxt, { random : random,
hint : hint,
guesses : guesses} );
I think
Hello devs,
I have been using flow to control my pipelines for some kind of cms. I
use flow to control the pipelines by invoking the PipelineUtil class to
execute pipelines to an outputstream, which I then send to the client
via another pipeline and a reader.
In some cases, the called
Mark Lundquist wrote:
I think I remember some discussion about map:script being able to
scan a directory and load any scripts it finds... can somebody refresh
my memory?
If you use just map:script in your sitemap, the sitemap loads all
scripts from an optional sub directory named flow
I think I remember some discussion about map:script being able to
scan a directory and load any scripts it finds... can somebody refresh
my memory?
thx,
—ml—
Carsten Ziegeler wrote:
In 2.2, the new Settings object is our central configuration bean.
I would like to make the settings object available in flow through the
Cocoon object, so a simple cocoon.settings.workingDirectory for example
gives me the current working directory.
Anyone against
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
In 2.2, the new Settings object is our central configuration bean.
I would like to make the settings object available in flow through the
Cocoon object, so a simple cocoon.settings.workingDirectory for example
gives me the current working
In 2.2, the new Settings object is our central configuration bean.
I would like to make the settings object available in flow through the
Cocoon object, so a simple cocoon.settings.workingDirectory for example
gives me the current working directory.
Anyone against this?
Carsten
[
https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned COCOON-1979:
Assignee: Carsten Ziegeler
[PATCH] Flow 2.1.0 reload-script = true does
a
compiledScript = entry.getScript(cx, this.scope, reloadScripts,
this);
doesn't do the job as well. The getScript method compares already the
timestamps for reloading.
[PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via
cocoon.load
(entry.getCompileTime() + checkTime System.currentTimeMillis());
is needed to comply to the specifcation of the check-time parameter in the
configuration of java script flow interpreter in the cocoon.xconf. The check
time is the time in miliseconds between the checks for the last
-dev (Current SVN)
Oh, yes - you're right of course.
Your patch is applied - please cross check
[PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via
cocoon.load
--
Key
))
(was: 2.2-dev (Current SVN))
[PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via
cocoon.load
--
Key: COCOON-1979
URL: https://issues.apache.org/jira/browse
[PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via
cocoon.load
--
Key: COCOON-1979
URL: https://issues.apache.org/jira/browse/COCOON-1979
[
https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Berens updated COCOON-1979:
---
Attachment: patch-2.txt
[PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via
[
https://issues.apache.org/jira/browse/COCOON-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Berens updated COCOON-1979:
---
Attachment: patch-1.txt
[PATCH] Flow 2.1.0 reload-script = true does not reload scripts loaded via
[ http://issues.apache.org/jira/browse/COCOON-1811?page=all ]
Jörg Heinicke updated COCOON-1811:
--
Attachment: (was: FOM_JavaScriptInterpreter.txt)
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope is locked
[ http://issues.apache.org/jira/browse/COCOON-1811?page=all ]
Jörg Heinicke reassigned COCOON-1811:
-
Assignee: Jörg Heinicke
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope is locked
to prevent variables to be
put into global scope, isn't there a possibility to check for it directly
instead of !(value instanceof NativeJavaClass) !(value instanceof
Function)?
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope is locked
] Automatic loading of flow scripts in flow/ must not load directories
--
Key: COCOON-1933
URL: http://issues.apache.org/jira/browse/COCOON-1933
Project: Cocoon
[
http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441964
]
Alexander Klimetschek commented on COCOON-1933:
---
Why don't use Excalibur Sources for retrieving the contents?
[Patch] Automatic loading of flow
?
[Patch] Automatic loading of flow scripts in flow/ must not load directories
--
Key: COCOON-1933
URL: http://issues.apache.org/jira/browse/COCOON-1933
Project: Cocoon
[Patch] Automatic loading of flow scripts in flow/ must not load directories
--
Key: COCOON-1933
URL: http://issues.apache.org/jira/browse/COCOON-1933
Project: Cocoon
[ http://issues.apache.org/jira/browse/COCOON-1933?page=all ]
Alexander Klimetschek updated COCOON-1933:
--
Attachment: cocoon-flow-only-files.patch
This patches makes the FlowNodeBuilder only load files directly under flow/.
[Patch] Automatic
Created a jira issue including a patch that only takes files directly
under flow/ into account.
http://issues.apache.org/jira/browse/COCOON-1933
Alex
Alexander Klimetschek schrieb:
I just run into a problem with the automatic loading of all files inside
flow/: if there is a subversion
the real
input stream is fetched from the Source in the end. And that would probably use
too much resources at the early read-in phase!?
What kind of resources must be supported apart from file systems, jars or wars?
Will directories under flow/ be deployed into a war?
[Patch] Automatic loading
depend on the
used interpreter and it is no guarantee that there isn't a directory hello.js
in the flow directory.
So I think we have to find another solution :(
[Patch] Automatic loading of flow scripts in flow/ must not load directories
that we are currently only able to run expanded as the
path matcher we use in other places is not working unexpanded.
[Patch] Automatic loading of flow scripts in flow/ must not load directories
--
Key
http://www.apache.org/dev/svn-eol-style.txt
However this won't work for files you already added. For those you
just do
something like svn propset svn:eol-style native yourfile.java and
commit.
It's all described in detail here http://svnbook.red-bean.com/en/1.1/
ch07s02.html
Jorg
On
On 08.10.2006 14:02, Jorg Heymans wrote:
http://www.apache.org/dev/svn-eol-style.txt
However this won't work for files you already added. For those you just do
something like svn propset svn:eol-style native yourfile.java and commit.
It's all described in detail here
wonder if you need the FlowHelper at all when not using flow script,
i.e. why it is in core? On the other hand javaflow block needs
flowscript block. Everything kind of strange, isn't it?
The FlowHelper is used in a number of places in cocoon-core and doesn't
(after the removal of unwrap) contain
On 06.10.2006 00:32, [EMAIL PROTECTED] wrote:
action dev=AG type=update
Deprecate method
org.apache.cocoon.components.flow.FlowHelper.unwrap(Object). This method
will be removed in 2.2 release. Use
org.apache.cocoon.components.flow.util.PipelineUtil.unwrap(Object) instead.
/action
Why
Joerg Heinicke escribió:
On 06.10.2006 00:32, [EMAIL PROTECTED] wrote:
action dev=AG type=update
Deprecate method
org.apache.cocoon.components.flow.FlowHelper.unwrap(Object). This method
will be removed in 2.2 release. Use
org.apache.cocoon.components.flow.util.PipelineUtil.unwrap(Object)
the FlowHelper at all when not using flow script,
i.e. why it is in core? On the other hand javaflow block needs
flowscript block. Everything kind of strange, isn't it?
Jörg
I now implemented this convention stuff - all files located in the
flow directory relative to the current sitemap are added to the flow
interpreter - regardless of the file name suffix and the used
interpreter (javascript, javaflow etc). The directory is of course optional.
By this we show a best
Leszek Gawron escribió:
If user wants to make JXTG automatically cacheable he/she must
explicitly state it in configuration:
map:generator src=org.apache.cocoon.template.JXTemplateGenerator
automatic-cache-key
use-sitemap-parameterstrue/use-sitemap-parameters
On 29.09.2006 09:19, Carsten Ziegeler wrote:
Now what about the other directories we currently have:
config/spring, config/xconf and config/properties?
Should we leave them where they are or move them one directory up?
I'd prefer the flat variant, i.e. without config subdir.
Jörg
Leszek Gawron escribió:
If user wants to make JXTG automatically cacheable he/she must
explicitly state it in configuration:
map:generator src=org.apache.cocoon.template.JXTemplateGenerator
automatic-cache-key
use-sitemap-parameterstrue/use-sitemap-parameters
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Is anyone against make using flow a little bit easier in trunk?
I really hate to specify all my flow scripts in the sitemap - so what
about using some convention over configuration stuff and include by
default all *.js files which are located
Carsten Ziegeler said the following on 29/9/06 09:19:
If noone objects I will add the stuff in the next days.
I like the feature but not the location as flowscripts are not configuration
files. What about ./flow only?
Ok, it seems that everyone here is in favour of using just flow
without
hepabolu wrote:
How much extra effort would it take to allow overriding the location in
e.g. the sitemap? E.g. as an attribute in map:flow
map:flow location=my/own/path/to/flow/
That shouldn't be difficult - but then the question is if this is
overriding the
default location
Carsten Ziegeler wrote:
hepabolu wrote:
How much extra effort would it take to allow overriding the location in
e.g. the sitemap? E.g. as an attribute in map:flow
map:flow location=my/own/path/to/flow/
That shouldn't be difficult - but then the question is if this is
overriding the
default
Reinhard Poetz said the following on 29/9/06 11:14:
Carsten Ziegeler wrote:
hepabolu wrote:
How much extra effort would it take to allow overriding the location
in e.g. the sitemap? E.g. as an attribute in map:flow
map:flow location=my/own/path/to/flow/
That shouldn't be difficult
hepabolu wrote:
Agree, but since it's more part of the application like Bertrand pointed
out, I favor a way to override the default location. So:
- default = all *.js in ./flow
- some specification somewhere = all *.js in my/own/path/to/flow
- different locations = use map:flow/ (which
Is anyone against make using flow a little bit easier in trunk?
I really hate to specify all my flow scripts in the sitemap - so what
about using some convention over configuration stuff and include by
default all *.js files which are located in the config/flow
directory (relative to the current
Carsten Ziegeler wrote:
Is anyone against make using flow a little bit easier in trunk?
I really hate to specify all my flow scripts in the sitemap - so what
about using some convention over configuration stuff and include by
default all *.js files which are located in the config/flow
directory
On 9/28/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Is anyone against make using flow a little bit easier in trunk?
I really hate to specify all my flow scripts in the sitemap - so what
about using some convention over configuration stuff and include by
default all *.js files which are located
Carsten Ziegeler wrote:
Is anyone against make using flow a little bit easier in trunk?
I really hate to specify all my flow scripts in the sitemap - so what
about using some convention over configuration stuff and include by
default all *.js files which are located in the config/flow
directory
Leszek Gawron wrote:
Niels van Kampenhout wrote:
Leszek Gawron wrote:
The only thing that's missing from HippoJXTemplateGenerator.java
functionality is the ability to exclude some parameters from cache
key. Anyway this looks like FS from the start:
What do you mean by FS? False Security?
Thorsten Scherler wrote:
On Mon, 2006-09-18 at 11:39 +0200, Leszek Gawron wrote:
Hmm, maybe the documentation is outdated but
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html state When
used inside flow, JXTemplate has access to Java and can therefore
evaluate expressions like
Leszek Gawron wrote:
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2
...
Now, the cached jx would depend on these three parameters.
Very easy to use, and less error prone than the flow part.
If somebody is interested in the code
On Sun, 2006-09-17 at 13:48 +0200, Leszek Gawron wrote:
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2
...
Now, the cached jx would depend on these three parameters.
Very easy to use, and less error prone than the flow
Niels van Kampenhout wrote:
Leszek Gawron wrote:
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2
...
Now, the cached jx would depend on these three parameters.
Very easy to use, and less error prone than the flow part
, and less error prone than the flow part.
If somebody is interested in the code I will hear
Yes very interested.
http://svn.apache.org/viewvc?view=revrev=446701
https://issues.apache.org/jira/browse/FOR-931
Can you attach a patch to this issue or commit it to cocoon directly?
Would
Thorsten Scherler wrote:
map:match pattern=foo
map:generate src=foobar.jx
that is the normal file generator which is indeed cacheable. I am
talking about map:generate type=jx src=foobar.jx which is not
cacheable (if not changed since the last update of the cocoon in
forrest).
I am sorry -
the flow part.
If somebody is interested in the code I will hear
Yes very interested.
http://svn.apache.org/viewvc?view=revrev=446701
https://issues.apache.org/jira/browse/FOR-931
Can you attach a patch to this issue or commit it to cocoon directly?
Would be awesome.
Do I get it right:
you want
.
Very easy to use, and less error prone than the flow part.
If somebody is interested in the code I will hear
Yes very interested.
http://svn.apache.org/viewvc?view=revrev=446701
https://issues.apache.org/jira/browse/FOR-931
Can you attach a patch to this issue or commit it to cocoon
Niels van Kampenhout wrote:
We could probably add this class to cocoon-template block and provide
some samples. Still - nothing needs to be changed.
I must admit that I don't know much about JXTG from a developer's
p.o.v., but from a user's p.o.v. (building web sites) our
Leszek Gawron wrote:
Please update your cocoon checkout to the latest trunk. Then build
cocoon-webapp, run it and point your browser to:
http://localhost:/blocks/cocoon-template-sample/view/caching3
The template header is:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
Niels van Kampenhout wrote:
Leszek Gawron wrote:
Please update your cocoon checkout to the latest trunk. Then build
cocoon-webapp, run it and point your browser to:
http://localhost:/blocks/cocoon-template-sample/view/caching3
The template header is:
page
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2
...
Now, the cached jx would depend on these three parameters.
Very easy to use, and less error prone than the flow part.
If somebody is interested in the code I will hear
Yes
,
—ml—
Begin forwarded message:
From: Mark Lundquist [EMAIL PROTECTED]
On Aug 1, 2006, at 1:46 PM, [EMAIL PROTECTED] wrote:
You're saying that flow calls in concurrently received requests
within
a session are processed serially, not in parallel threads? Is that
right?
That's pretty much
On Aug 8, 2006, at 7:49 AM, Sylvain Wallez wrote:
Reinhard Poetz wrote:
I guess that's right, see the code of the FOM_JavascriptInterpreter
line 563 (in trunk):
ThreadScope thrScope = getSessionScope();
synchronized (thrScope) {
ClassLoader savedClassLoader =
Lundquist [EMAIL PROTECTED]
On Aug 1, 2006, at 1:46 PM, [EMAIL PROTECTED] wrote:
You're saying that flow calls in concurrently received requests
within
a session are processed serially, not in parallel threads? Is that
right?
That's pretty much it in a nutshell, yes.
wow
message:
From: Mark Lundquist [EMAIL PROTECTED]
On Aug 1, 2006, at 1:46 PM, [EMAIL PROTECTED] wrote:
You're saying that flow calls in concurrently received requests within
a session are processed serially, not in parallel threads? Is that
right?
That's pretty much it in a nutshell, yes.
wow
On 7/6/06, Peter Hunsberger [EMAIL PROTECTED] wrote:
On 7/6/06, Peter Hunsberger [EMAIL PROTECTED] wrote:
I'm attempting to migrate some more of our code from sitemap based
action handlers to flow. Cocoon is at 2.1.8 and I'm seeing problems
invalidating sessions from flow.
Found
I'm attempting to migrate some more of our code from sitemap based
action handlers to flow. Cocoon is at 2.1.8 and I'm seeing problems
invalidating sessions from flow.
Essentially, we are using Javascript flow to invoke a Java class as follows:
var handler
On 7/6/06, Peter Hunsberger [EMAIL PROTECTED] wrote:
I'm attempting to migrate some more of our code from sitemap based
action handlers to flow. Cocoon is at 2.1.8 and I'm seeing problems
invalidating sessions from flow.
Just discovered that we're still on Cocoon 2.1.6. Anyone know
capabilities would be.
Ciao
Giacomo
On Mon, 3 Jul 2006, Ard Schrijvers wrote:
Date: Mon, 3 Jul 2006 19:13:31 +0200
From: Ard Schrijvers [EMAIL PROTECTED]
Reply-To: users@cocoon.apache.org
To: users@cocoon.apache.org
Subject: RE: Caching jx with flow (WAS: Is use-store needed when using XSLTC
with flow (WAS: Is use-store needed when
using XSLTC
?)
Hmmm, I hoped my mails would be so clear that it is not needed anymore
:-) But your right, I probably should, but it takes a lot of time and
effort to write it down really well
Anyway, are there people interested in a document
, Cocoon 2.1.8, and the Jetty AppServer.
I can use this class in a stand alone mode and get mail sent out (this
is true whether I'm running as myself or as the cocoon user).
When I try to use the same class within Flow I get nothing at all.
There isn't even an error in the log. The status
Guys,
please help, I have no clue what's wrong, so if anyone has additional
idea, please let me know. Here it goes:
I build my forms using the jx:template and flowscript. I have a few
pipelines that handle the forms and their results. I have several forms
that work fine this way.
Now I've
Hi Helma,
It's weird. At the same time. Too few info in the mail to test. ;-)
Try to do a full build and before restarting make sure you also clean up
the ehcache temporary directory. Also make sure you clean up your
browser cache.
BTW, wich cocon version are you using?
HTH,
Best Regards,
Antonio Gallardo wrote:
With all due respect: I don't think this is the best way to have a
better 2.2.
I don't have the time to fix the bug myself. I filled a bug report. Sorry, I
can't be more helpful ATM.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software
Reinhard Poetz escribió:
Antonio Gallardo wrote:
With all due respect: I don't think this is the best way to have a
better 2.2.
I don't have the time to fix the bug myself. I filled a bug report.
Sorry, I can't be more helpful ATM.
Thank you. I will take a look at this. I think there is
-INF/flow/jxcalc/screens/getNumberA.xml
Modified:
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
URL:
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main
the latest download of cocoon 2.1.9?
regards
Andrew
Javascript FOM_SCOPE issue when using Java as the flow engine -
ReferenceError: cocoon is not defined
---
Key: COCOON-1804
)
using the patch here attached.
- Checkiung out 2.1.X (2.1.10 dev) from SVN
- Downloading a 2.1.X snapshot from here
http://svn.apache.org/snapshots/cocoon-BRANCH_2_1_X/
Javascript FOM_SCOPE issue when using Java as the flow engine -
ReferenceError: cocoon is not defined
[ http://issues.apache.org/jira/browse/COCOON-1804?page=all ]
Simone Gianni closed COCOON-1804:
-
Fix Version: 2.1.10-dev (current SVN)
Resolution: Fixed
Committed the patch
Javascript FOM_SCOPE issue when using Java as the flow engine
-cocoon-forms-1811. Please
use the latter.
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope is locked
--
Key: COCOON-1811
URL: http://issues.apache.org/jira
[ http://issues.apache.org/jira/browse/COCOON-1811?page=all ]
Rob Berens updated COCOON-1811:
---
Attachment: 20060409-cocoon-forms-1811
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope is locked
without problem.
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope is locked
--
Key: COCOON-1811
URL: http://issues.apache.org/jira/browse/COCOON-1811
.
Alternatively:
main2.js:
function someMethod() {
cocoon.load(myScript1); // when called from here exception is thrown
}.
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope is locked
not into the top-level scope but instead into
the scope from which it is called? So in the original example the myObject
class would only be defined within the scope of the loadScript() function. This
seems cleaner to me.
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope
it is also allowed to be created in
the global scope at any moment.
[PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when
scope is locked
--
Key: COCOON-1811
URL
1 - 100 of 1064 matches
Mail list logo
