Re: call a function not in global object in map:call
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 (or just like what dojo does).
Agreed.
Here's a patch you can try. I couldn't figure out how to do it the
real way, so... this way feels kind of sleazy, but it works :-)
Index:
src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_JavaScriptInterpreter.java
===
---
src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_JavaScriptInterpreter.java(revision 472699)
+++
src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_JavaScriptInterpreter.java(working copy)
@@ -69,6 +69,7 @@
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.PushbackInputStream;
+import java.io.StringReader;
import java.io.Reader;
import java.util.ArrayList;
import java.util.HashMap;
@@ -744,9 +745,15 @@
}
cocoon.setParameters(parameters);
-Object fun =
ScriptableObject.getProperty(thrScope, funName);
-if (fun == Scriptable.NOT_FOUND) {
-throw new ResourceNotFoundException(Function
\javascript: + funName + ()\ not found);
+try {
+final Object fun =
+context.compileReader (
+thrScope, new StringReader
(funName), null, 1, null
+).exec (context, thrScope);
+} catch (EcmaError ee) {
+ throw new ResourceNotFoundException (
+Function \javascript: + funName + ()\
not found
+);
}
If some other Cocoon developers think this is not too lame :-), then I
will make it official and fire up a JIRA issue.
There are more javascript codes than java codes in our project, so
goruping them in different naming spaces is needed. Cocoon itself is a
good environment for easily javascript coding at the server side with
its flowscript and continuation.
Yes :-)
However, it seems not that care about naming space at javascript code
itself. Maybe some ideas from dojo can be borrowed here. Like dojo has
dojo naming space, cocoon has cocoon naming space, and within cocoon,
there are cocoon.flow, cocoon.flow.continuation,...
I agree, Cocoon's own Javascript style is kind of flat that way.
—ml—
Re: svn commit: r473974 - in /cocoon/trunk/blocks: cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/ cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/coc
Hi All On 12 Nov 2006, at 15:28, [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?view=revrev=473974 Log: Adding support for Dojo's IframeIO to CForms. This allows forms with file-upload fields to be submitted as a background AJAX process. Currently this is turned off for Safari where is is not working. I have added support for Dojo's IframeIO AJAX Transport to CForms in BRANCH_2_1_X. This is to allow forms with file upload fields to be able to be submitted via AJAX. This is implemented only for cforms that use JXMacro rendering pipelines. I have tested this under Firefox, MSIE and Safari, AFAICS all samples that worked before the change still work. It is currently disabled in Safari as it does not work in the release version, however it does work in the nightly builds of Webkit, so hopefully it will work in Safari soon. IframeIO and XMLHttp Transports do have some differences . XMLHttp is completely asynchronous, IframeIO is not. Submit events in IframeIO get queued by Dojo as it can only handle one submit and response at a time, as it uses a hidden iFrame for the form. I had a great deal of trouble getting BrowserUpdate to work reliably across platform and browser. I eventually had to resort to placing the update content inside a textarea and parsing it on the client. It looks and sounds clunky but it was the only technique I could get to work reliably. While reworking the CFormsForm Widget (etc.) I was able to remove some functions from the CForms Libs and use functions that come with Dojo instead that have the same behaviour. Another change I have made is to disable the form-control that submits the form, re-enabling it when the Request returns, to try to avoid double submits etc. These changes need more testing Please test Ajax and non-Ajax cforms, forms that use FormsTransformer as well as JXMacros. Please look out for form controls that do not get re-enabled after the Request has returned. enjoy regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Shielded classloading
Vadim Gritsenko wrote: Carsten Ziegeler wrote: So I propose that we move WEB-INF/classes to WEB-INF/shielded-classes and WEB-INF/libs to WEB-INF/shielded-libs. Looks OK to me. Wouldn't WEB-INF/shielded/classes and WEB-INF/shielded/libs be slightly better? Anyway, +1. Yepp - I just changed the code according to your suggestion. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-1949) [PATCH] load flowscript from file into specified Rhino context object
[ http://issues.apache.org/jira/browse/COCOON-1949?page=comments#action_12449191 ] Mark Lundquist commented on COCOON-1949: Thanks :-) —ml— [PATCH] load flowscript from file into specified Rhino context object - Key: COCOON-1949 URL: http://issues.apache.org/jira/browse/COCOON-1949 Project: Cocoon Issue Type: Improvement Components: - Flowscript Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Mark Lundquist Priority: Minor Attachments: 1949.patch.BRANCH_2_1_X, 1949.patch.trunk I have a use case for a flowscript load function to work as described here: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113049426018570w=2 This patch adds a loadInScope() function to the Cocoon FOM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r473974 - in /cocoon/trunk/blocks: cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/ cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/coc
Hi Jeremy,
Nice work. Please look into the small issues below:
[EMAIL PROTECTED] escribió:
Author: jeremy
Date: Sun Nov 12 07:28:08 2006
New Revision: 473974
URL: http://svn.apache.org/viewvc?view=revrev=473974
Log:
Adding support for Dojo's IframeIO to CForms.
This allows forms with file-upload fields to be submitted as a background AJAX
process. Currently this is turned off for Safari where is is not working.
Added:
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/IframeTransport-bu-styling.xsl
Modified:
cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/BUHandler.js
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/js/CFormsForm.js
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/js/common.js
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/sitemap.xmap
Modified:
cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/BUHandler.js
URL:
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/BUHandler.js?view=diffrev=473974r1=473973r2=473974
==
---
cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/BUHandler.js
(original)
+++
cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/ajax/resources/js/BUHandler.js
Sun Nov 12 07:28:08 2006
@@ -38,66 +38,71 @@
dojo.lang.extend(cocoon.ajax.BUHandler, {
// Default highlight effect
-highlight: null,
+ highlight: null,
-processResponse: function(doc, request) {
- var nodes = doc.documentElement.childNodes;
- for (var i = 0; i nodes.length; i++) {
- var node = nodes[i];
- if (node.nodeType == dojo.dom.ELEMENT_NODE) {
- var handler;
- if (node.localName) {
- handler = node.localName;
- } else {
- // No DOM2 support (IE6)
- handler = node.nodeName.replace(/.*:/, );
- }
- var handlerFunc = this.handlers[handler];
- if (handlerFunc) {
- handlerFunc(node);
- } else {
- this.handleError(No handler found for element +
handler, request);
- }
- }
- }
+ processResponse: function(doc, request) {
+ var base = doc.documentElement;
+
+ var nodes = [];
+ if (base.nodeName.toLowerCase() == bu:document) {
+ nodes = base.childNodes;
+ dojo.debug(got response using: XMLHTTPTransport);
+ } else {
+ nodes = dojo.byId(browser-update, doc).childNodes;
+ dojo.debug(got response using: IframeTransport);
+ }
+ for (var i = 0; i nodes.length; i++) {
+ var node = nodes[i];
+ if (node.nodeType == dojo.dom.ELEMENT_NODE) {
+ var handler = node.nodeName.replace(/.*:/,
).toLowerCase();
+ if (handler == textarea) handler =
node.getAttribute(name);
+ var handlerFunc = this.handlers[handler];
+ if (handlerFunc) {
+ handlerFunc(node);
+ } else {
+ this.handleError(No handler found for
element + handler, request);
+ }
+ }
+ }
},
We use 4 spaces for tabs.
Modified:
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/js/CFormsForm.js
URL:
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/js/CFormsForm.js?view=diffrev=473974r1=473973r2=473974
==
---
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/js/CFormsForm.js
(original)
+++
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/js/CFormsForm.js
Sun Nov 12 07:28:08 2006
@@ -1,4 +1,4 @@
-/*
+/*
Encoding typo? Please review your subversion settings.
Re: call a function not in global object in map:call
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 works... :-/
===
---
src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_JavaScriptInterpreter.java(revision 472699)
+++
src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_JavaScriptInterpreter.java(working copy)
@@ -69,6 +69,7 @@
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.PushbackInputStream;
+import java.io.StringReader;
import java.io.Reader;
import java.util.ArrayList;
import java.util.HashMap;
@@ -744,9 +745,17 @@
}
cocoon.setParameters(parameters);
-Object fun =
ScriptableObject.getProperty(thrScope, funName);
-if (fun == Scriptable.NOT_FOUND) {
-throw new ResourceNotFoundException(Function
\javascript: + funName + ()\ not found);
+// Resolve function name
+//
+Object fun;
+try {
+fun = context.compileReader (
+thrScope, new StringReader
(funName), null, 1, null
+).exec (context, thrScope);
+} catch (EcmaError ee) {
+ throw new ResourceNotFoundException (
+Function \javascript: + funName + ()\
not found
+);
}
Cheers,
—ml—
[jira] Commented: (COCOON-1879) Make fd:field whitespace trimming behavior configurable
[ http://issues.apache.org/jira/browse/COCOON-1879?page=comments#action_12449230 ] Jason Johnston commented on COCOON-1879: I incorporated the suggestions from Bruno and Simone (thanks!) and committed at revision 474132. The fd:field documentation page has been updated in Daisy. Make fd:field whitespace trimming behavior configurable --- Key: COCOON-1879 URL: http://issues.apache.org/jira/browse/COCOON-1879 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Jason Johnston Attachments: COCOON-1879.diff Currently fd:field widgets always trim leading and trailing whitespace from the user's input. Sometimes this behavior is not desired, so it should be configurable. See this thread for discussion: http://marc.theaimsgroup.com/?t=11496023148r=1w=2 Patch forthcoming. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1879) Make fd:field whitespace trimming behavior configurable
[ http://issues.apache.org/jira/browse/COCOON-1879?page=all ] Jason Johnston closed COCOON-1879. -- Resolution: Fixed Make fd:field whitespace trimming behavior configurable --- Key: COCOON-1879 URL: http://issues.apache.org/jira/browse/COCOON-1879 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Jason Johnston Attachments: COCOON-1879.diff Currently fd:field widgets always trim leading and trailing whitespace from the user's input. Sometimes this behavior is not desired, so it should be configurable. See this thread for discussion: http://marc.theaimsgroup.com/?t=11496023148r=1w=2 Patch forthcoming. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Submitting patches in JIRA
Mark Lundquist wrote: Back in the day, with Bugzilla, I remember we had the convention that the issue title started with '[PATCH]'. If there was no patch available when the issue was created, you just edited the issue title and inserted '[PATCH]'. I see that with JIRA, there is this little a patch is available with this issue checkbox on the issue creation page. Funny, I never noticed that before... :-). Ah, now it all clicks... I guess that's where that open-with-patch report comes from :-) And I guess the old convention of starting with '[PATCH]' is superfluous now, right? That's good, because there doesn't seem to be any way to edit the title... maybe I don't have the right karma/mojo/whatever. All I have to do is check the little box... but wait! There's no little box anymore once the issue's been created. And there's no this is a patch checkbox on the Attach File form... SooOOOooo... if I create an issue w/ no patch, then decide to submit a patch later, how do I indicate it? Create a new issue referencing the first? Or just attach the file and don't worry about it? :-) Use the Edit this issue link on the left-hand panel when you are viewing an issue. -David
