On Jan 13, 2007, at 11:58 PM, Rice Yeh wrote:
Then, should I report this problem to JIRA. Or there is other concern
not to include this function in trunk?
I'll do it, 'cause I can supply my svn diff as a patch... :-)
—ml—
Hi,
Do you have an example about how to pass the namespace object? I use it
like the following:
map:call function=xs.party.use
map:parameter name=flowpath value={0}/
/map:call
, but it does not work.
Regards,
Rice
On 1/11/07, Mark Lundquist
On Jan 13, 2007, at 2:21 AM, Rice Yeh wrote:
Do you have an example about how to pass the namespace object? I use
it like the following:
map:call function=xs.party.use
map:parameter name=flowpath value={0}/
/map:call
, but it does not
The fun is not gotten by the code at line 591 in
FOM_JavaScriptInterpreter.java
Object fun = ScriptableObject.getProperty(thrScope, funName);
, so ResourceNotFoundException is thrown at its following code.
if (fun == Scriptable.NOT_FOUND) {
throw
On Jan 13, 2007, at 11:11 AM, Rice Yeh wrote:
By studying the source code, I do not think call a function not in
global object in map:call is supported in trunk because function
is still gotten in thrScope. Am I right?
I don't think so. What scope do you think it should compile in?
—ml—
I just tested like this:
var flowTest =
{
foo: {}
}
flowTest.foo.bar =
function() {
print (Hello from flowTest());
};
...and like this...
map:call
On Jan 13, 2007, at 1:41 PM, Mark Lundquist wrote:
I just tested like this:
[...snip..]
and it worked fine...
Note, actually I tested in 2.1.11(dev), not trunk, because that was
more convenient ATM... but it's the exact same code in
FOM_JavascriptInterpreter.
cheers,
—ml—
On Jan 13, 2007, at 11:11 AM, Rice Yeh wrote:
The fun is not gotten by the code at line 591 in
FOM_JavaScriptInterpreter.java
Object fun = ScriptableObject.getProperty(thrScope, funName);
hold on, I did not read the above very carefully the first time,
sorry... :-/
By studying the
I am sure my code is from trunk. It is at version revision 494774. Please
have a look at
https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-flowscript/cocoon-flowscript-impl/src/main/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java
.
Is the code you
And have a check at
https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java
.
It is sured that this function is not in trunk.
Rice
On 1/14/07, Rice Yeh [EMAIL PROTECTED] wrote:
I am sure my code is
On Jan 13, 2007, at 8:02 PM, Rice Yeh wrote:
It is sured that this function is not in trunk.
Bah, you are right, sorry, my bad... so I guess it is in BRANCH_2_1_X
but not in trunk yet. It turns out that I had this file checked out in
trunk and was looking at my own checked-out version.
Then, should I report this problem to JIRA. Or there is other concern not to
include this function in trunk?
Regards,
Rice
On 1/14/07, Mark Lundquist [EMAIL PROTECTED] wrote:
On Jan 13, 2007, at 8:02 PM, Rice Yeh wrote:
It is sured that this function is not in trunk.
Bah, you are right,
Hi,
Does anyone know whether the function mentioned in
http://www.mail-archive.com/dev@cocoon.apache.org/msg47930.html works now?
Rice
On Jan 11, 2007, at 1:36 AM, Rice Yeh wrote:
Does anyone know whether the function mentioned in
http://www.mail-archive.com/dev@cocoon.apache.org/msg47930.html works
now?
phooey... I forgot to submit this patch to JIRA :-(. Doing it now...
—ml—
On Jan 11, 2007, at 6:08 AM, Mark Lundquist wrote:
On Jan 11, 2007, at 1:36 AM, Rice Yeh wrote:
Does anyone know whether the function mentioned in
http://www.mail-archive.com/dev@cocoon.apache.org/msg47930.html works
now?
phooey... I forgot to submit this patch to JIRA :-(. Doing it
Hi Guys
I am trying this patch in 2_1_10-dev and it does not compile :
compile-core:
Compiling 1 source file to /Users/Shared/Development/Checkouts/Apache/
Cocoon/Cocoon_2_1_X/build/cocoon/classes
/Users/Shared/Development/Checkouts/Apache/Cocoon/Cocoon_2_1_X/src/
On Nov 19, 2006, at 7:11 AM, Jeremy Quinn wrote:
Hi Guys
I am trying this patch in 2_1_10-dev and it does not compile :
Jeremy, thanks for trying the patch. Sorry for the bad code, I need to
get up on the learning curve of building trunk :-/ Anyway, see
below...
compile-core:
Hi Mark
Many thanks for getting back to me so quickly.
It compiled fine, and it seems to work with both namespaced and non-
namespaced JavaScript.
regards Jeremy
On 13 Nov 2006, at 03:14, Mark Lundquist wrote:
On Nov 12, 2006, at 1:31 AM, I wrote:
[...snip] Here's a patch you can try.
On Nov 19, 2006, at 10:38 AM, Jeremy Quinn wrote:
Hi Mark
Many thanks for getting back to me so quickly.
You're welcome :-).
Normally I don't do this on Sunday... but today I ditched church to
work on my med school applications, so I am home.
So, why am I fooling around with Cocoon,
On 19 Nov 2006, at 18:45, Mark Lundquist wrote:
On Nov 19, 2006, at 10:38 AM, Jeremy Quinn wrote:
Hi Mark
Many thanks for getting back to me so quickly.
You're welcome :-).
Normally I don't do this on Sunday... but today I ditched church to
work on my med school applications, so I am
On Nov 13, 2006, at 10:14 PM, Rice Yeh wrote:
Thank you. Will this patch go into the trunk eventually?
It's up to the committers. I'm sure they will take a look at it and
decide if they think it's a good way.
But if you want to try a trunk version, here it is. I couldn't get
trunk to
Mark Lundquist wrote:
On Nov 13, 2006, at 10:14 PM, Rice Yeh wrote:
Thank you. Will this patch go into the trunk eventually?
It's up to the committers. I'm sure they will take a look at it and
decide if they think it's a good way.
I can't vouch for the patch, but I'll definitely give my
Thank you. Will this patch go into the trunk eventually?RiceOn 11/13/06, Mark Lundquist [EMAIL PROTECTED]
wrote:On Nov 12, 2006, at 1:31 AM, I wrote: [...snip] Here's a patch you can try.[...snip]
Do'h. my bad!I didn't realize when I sent you that diff that I was inthe middle of changing the code
On Nov 11, 2006, at 9:16 AM, Rice Yeh wrote:
Hi,
It seems for now the function attribute in map:call must be a
function in the global object. I think it might be better if this
function could be within a scope object because our project groups all
javascript objects like java packages
On Nov 12, 2006, at 1:31 AM, I wrote:
[...snip] Here's a patch you can try. [...snip]
Do'h. my bad! I didn't realize when I sent you that diff that I was in
the middle of changing the code from its first working form. Sorry
for going off half cocked; here's a version that actually
Hi, It seems for now the function attribute in map:call must be a function in the global object. I think it might be better if this function could be within a scope object because our project groups all _javascript_ objects like java packages (or just like what dojo does). There are more
26 matches
Mail list logo
