Re: module naming
On Jan 15, 2007, at 6:20 PM, Jason Johnston wrote: One possible reason is that the resulting JAR artifacts only contain the artifact name (and version), so having the 'redundant' identifier makes the JAR file more identifiable once everything's flattened into e.g. WEB-INF/lib. I think that's it (I'd been trying to remember from some previous discussion...). A configuration element for the jar plugin would be nice. thx, —ml—
Re: module naming
Mark Lundquist wrote: On Jan 15, 2007, at 3:08 AM, Leszek Gawron wrote: We should come up with some agreement on how to name the modules. That reminds me, I was wondering about the artifactIds / names of module directories in the svn tree... why do they all start w/ "cocoon-"? It seems kinda redundant since the groupId is "org.apache.cocoon". I'm sure there must have been a reason, I'm just curious what it is :-). One possible reason is that the resulting JAR artifacts only contain the artifact name (and version), so having the 'redundant' identifier makes the JAR file more identifiable once everything's flattened into e.g. WEB-INF/lib. Also it occurs to me that "org.apache.cocoon.core" and "org.apache.cocoon.blocks" could be used as groupIds if that were thought to help make things clearer... —ml—
[continuum] BUILD ERROR: Cocoon Blocks Framework Sample Blocks
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/80/buildId/1690 Build statistics: State: Error Previous State: Error Started at: Tue, 16 Jan 2007 00:29:28 + Finished at: Tue, 16 Jan 2007 00:29:30 + Total time: 1s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Blocks Framework Demo Block 1
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/78/buildId/1689 Build statistics: State: Error Previous State: Error Started at: Tue, 16 Jan 2007 00:29:26 + Finished at: Tue, 16 Jan 2007 00:29:28 + Total time: 1s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Blocks Framework Demo Block 2
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/79/buildId/1688 Build statistics: State: Error Previous State: Error Started at: Tue, 16 Jan 2007 00:29:25 + Finished at: Tue, 16 Jan 2007 00:29:26 + Total time: 0s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
Re: trouble w/ cocoon-webapp + Eclipse + Jetty Launcher
On Jan 15, 2007, at 3:04 PM, Daniel Fagerstrom wrote: I don't think they are the same thing. In my Jetty launcher plugin (1.4.1), both of the fields are there and I use the field connected to the "use custom webdefaults config file. ohh... you mean, right there in front of me? :-/ Seriously... this is why I do so much better with command-line tools :-/ java.io.IOException: Jetty configuration problem: java.lang.IllegalStateException: Unknown tag: description Which shows that the "Jetty XML configuration file" field doesn't understand the scheme of an ordinary webapp file. Yes... hence my befuddlement. thx, —ml—
Re: trouble w/ cocoon-webapp + Eclipse + Jetty Launcher
Mark Lundquist skrev: On Jan 15, 2007, at 1:16 PM, Daniel Fagerstrom wrote: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116756809412994&w=2 Thanks, Daniel. I think I must be misunderstanding something, though. When I pull up the Jetty Web configuration panel, it doesn't have "Use custom webdefaults config file" exactly, but I have a box marked "Use a Jetty XML configuration file" and I presume that's the same thing. I don't think they are the same thing. In my Jetty launcher plugin (1.4.1), both of the fields are there and I use the field connected to the "use custom webdefaults config file. IIRC the "Jetty XML configuration file" corresponds to the servlet.xml in Tomcat. When I select that option with "webdefault.xml", it breaks with this: java.io.IOException: Jetty configuration problem: java.lang.IllegalStateException: Unknown tag: description at org.mortbay.jetty.Server.(Server.java:124) at com.iw.plugins.jettyrunner.PluginRunner.launchWithXML(PluginRunner.java:226) at com.iw.plugins.jettyrunner.PluginRunner.launch(PluginRunner.java:91) at com.iw.plugins.jettyrunner.PluginRunner.main(PluginRunner.java:75) ( is the first child of in the webdefault.xml file). Which shows that the "Jetty XML configuration file" field doesn't understand the scheme of an ordinary webapp file. Sorry for being so lame, to atone for it I will add all this to the docs once I have it working :-/ No problem. thx, —ml— P.S. The comment in webdefault.xml seems awfully disparaging about RequestAttributeListeners, whatever those are... I saw that. But after having spent a couple of hours before I found out that they didn't support all of servlet 2.4 by default. I thought that they got their priorities wrong. They have given up their fight against the standard in Jetty 6 and just implements the RequestAttributeListeners without complaining explicitly. /Daniel
Re: trouble w/ cocoon-webapp + Eclipse + Jetty Launcher
On Jan 15, 2007, at 1:16 PM, Daniel Fagerstrom wrote: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116756809412994&w=2 Thanks, Daniel. I think I must be misunderstanding something, though. When I pull up the Jetty Web configuration panel, it doesn't have "Use custom webdefaults config file" exactly, but I have a box marked "Use a Jetty XML configuration file" and I presume that's the same thing. When I select that option with "webdefault.xml", it breaks with this: java.io.IOException: Jetty configuration problem: java.lang.IllegalStateException: Unknown tag: description at org.mortbay.jetty.Server.(Server.java:124) at com.iw.plugins.jettyrunner.PluginRunner.launchWithXML(PluginRunner.java: 226) at com.iw.plugins.jettyrunner.PluginRunner.launch(PluginRunner.java:91) at com.iw.plugins.jettyrunner.PluginRunner.main(PluginRunner.java:75) ( is the first child of in the webdefault.xml file). Sorry for being so lame, to atone for it I will add all this to the docs once I have it working :-/ thx, —ml— P.S. The comment in webdefault.xml seems awfully disparaging about RequestAttributeListeners, whatever those are...
Re: trouble w/ cocoon-webapp + Eclipse + Jetty Launcher
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116756809412994&w=2 /Daniel Mark Lundquist skrev: Hi, When I run cocoon-webapp using "mvn jetty:run", it works fine. When I launch it from Eclipse using the Jetty plugin, I get this: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. I configured the Jetty Launcher like so... webapp root: target/webapp context name: / Any clues? thx, —ml—
trouble w/ cocoon-webapp + Eclipse + Jetty Launcher
Hi, When I run cocoon-webapp using "mvn jetty:run", it works fine. When I launch it from Eclipse using the Jetty plugin, I get this: No thread-bound request found: Are you referring to request attributes outside of an actual web request? If you are actually operating within a web request and still receive this message,your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request. I configured the Jetty Launcher like so... webapp root: target/webapp context name: / Any clues? thx, —ml—
Re: module naming
On Jan 15, 2007, at 3:08 AM, Leszek Gawron wrote: We should come up with some agreement on how to name the modules. That reminds me, I was wondering about the artifactIds / names of module directories in the svn tree... why do they all start w/ "cocoon-"? It seems kinda redundant since the groupId is "org.apache.cocoon". I'm sure there must have been a reason, I'm just curious what it is :-). Also it occurs to me that "org.apache.cocoon.core" and "org.apache.cocoon.blocks" could be used as groupIds if that were thought to help make things clearer... —ml—
[jira] Updated: (COCOON-1981) Allow to call any function
[
https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke updated COCOON-1981:
--
Attachment: (was: 1981.patch)
> Allow to call any function
> -
>
> Key: COCOON-1981
> URL: https://issues.apache.org/jira/browse/COCOON-1981
> Project: Cocoon
> Issue Type: Improvement
> Components: - Flowscript
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Mark Lundquist
>Priority: Minor
> Attachments: 1981.patch
>
>
> Currently, can only call a function that is a property of the
> flowscript global scope itself. This patch allows it to call any function in
> the global scope, e.g. "foo.bar.baz".
> I provided this code change originally to Jeremy Quinn who committed it to
> BRANCH_2_1_X, but it has not yet been incorporated into trunk.
> The only additional thing I would suggest... would it be worth it to test if
> funName.contains ("."), and if so look up the function the old way? Don't
> know if that's significantly faster...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1981) Allow to call any function
[
https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke updated COCOON-1981:
--
Attachment: (was: 1981.patch)
> Allow to call any function
> -
>
> Key: COCOON-1981
> URL: https://issues.apache.org/jira/browse/COCOON-1981
> Project: Cocoon
> Issue Type: Improvement
> Components: - Flowscript
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Mark Lundquist
>Priority: Minor
> Attachments: 1981.patch
>
>
> Currently, can only call a function that is a property of the
> flowscript global scope itself. This patch allows it to call any function in
> the global scope, e.g. "foo.bar.baz".
> I provided this code change originally to Jeremy Quinn who committed it to
> BRANCH_2_1_X, but it has not yet been incorporated into trunk.
> The only additional thing I would suggest... would it be worth it to test if
> funName.contains ("."), and if so look up the function the old way? Don't
> know if that's significantly faster...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Making settings object available in flow
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
[continuum] BUILD ERROR: Cocoon Blocks Framework Sample Blocks
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/80/buildId/1682 Build statistics: State: Error Previous State: Error Started at: Mon, 15 Jan 2007 12:18:21 + Finished at: Mon, 15 Jan 2007 12:18:26 + Total time: 4s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Blocks Framework Demo Block 1
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/78/buildId/1681 Build statistics: State: Error Previous State: Error Started at: Mon, 15 Jan 2007 12:18:18 + Finished at: Mon, 15 Jan 2007 12:18:21 + Total time: 2s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: Cocoon Blocks Framework Demo Block 2
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/79/buildId/1680 Build statistics: State: Error Previous State: Error Started at: Mon, 15 Jan 2007 12:18:13 + Finished at: Mon, 15 Jan 2007 12:18:18 + Total time: 4s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[jira] Commented: (COCOON-1624) reader caching does not consider mime-type
[ https://issues.apache.org/jira/browse/COCOON-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464744 ] Carsten Ziegeler commented on COCOON-1624: -- Yes, you're right and it would make sense to clean the cache when the sitemap changes. Unfortunately, there is no key (or part of the cache key) that identifies a cache entry to belong to a sitemap. So we have to mark cache entries for this. > reader caching does not consider mime-type > -- > > Key: COCOON-1624 > URL: https://issues.apache.org/jira/browse/COCOON-1624 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: other > Platform: Other >Reporter: Jörg Heinicke > Assigned To: Cocoon Developers Team > > Changing the mime type on a reader in a caching pipeline does not invalidate > its > former usage with another mime type. > Sample: > > > > changed to > >mime-type="application/vnd.mozilla.xul+xml"/> > > still results in delivery with text/xml. Carsten already saw it at the > hackathon > when I played around with XUL. > Jörg -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
module naming
We should come up with some agreement on how to name the modules. Right now it's a little bit messy: > [INFO] Apache Cocoon . SUCCESS > [6.734s] > [INFO] Cocoon Core [modules] . SUCCESS > [0.078s] > [INFO] Cocoon Configuration API .. SUCCESS > [11.859s] > [INFO] Cocoon Thread API . SUCCESS > [1.360s] > [INFO] Cocoon Thread Implementation .. SUCCESS > [2.250s] > [INFO] Cocoon Util ... SUCCESS > [2.782s] > [INFO] Cocoon Store Implementation ... SUCCESS > [2.906s] > [INFO] Cocoon XML API SUCCESS > [1.328s] > [INFO] Cocoon XML Implementation . SUCCESS > [7.609s] > [INFO] Cocoon Pipeline API ... SUCCESS > [20.000s] > [INFO] Cocoon Pipeline Implementation SUCCESS > [25.641s] > [INFO] Cocoon Pipeline Components SUCCESS > [40.094s] > [INFO] Cocoon Spring Configurator SUCCESS > [19.937s] > [INFO] Cocoon XML Resolver ... SUCCESS > [10.313s] > [INFO] Cocoon Sitemap API SUCCESS > [9.469s] > [INFO] Cocoon Sitemap Implementation . SUCCESS > [17.250s] > [INFO] Cocoon Sitemap Components . SUCCESS > [8.515s] > [INFO] Cocoon Core ... SUCCESS > [16.156s] > [INFO] Cocoon Blocks [modules] ... SUCCESS > [0.125s] > [INFO] Ajax Block [modules] .. SUCCESS > [0.079s] > [INFO] Ajax Block Implementation . SUCCESS > [15.875s] > [INFO] Ajax Block Sample . SUCCESS > [1.359s] > [INFO] Cocoon Apples Block [modules] . SUCCESS > [0.031s] > [INFO] Apples Block Implementation ... SUCCESS > [3.110s] > [INFO] Flowscript Block [modules] SUCCESS > [0.093s] > [INFO] Flowscript Block .. SUCCESS > [6.469s] > [INFO] Forms Block [modules] . SUCCESS > [0.094s] > [INFO] Forms Block Implementation SUCCESS > [42.265s] > [INFO] Core-samples Block [modules] .. SUCCESS > [0.047s] > [INFO] Core-samples-main Block Samples ... SUCCESS > [8.969s] > [INFO] Template framework [modules] .. SUCCESS > [0.047s] > [INFO] Template framework implementation . SUCCESS > [8.437s] > [INFO] Cocoon samples styles [modules] ... SUCCESS > [0.063s] > [INFO] Cocoon Tools [modules] SUCCESS > [0.047s] > [INFO] Cocoon Deployer [modules] . SUCCESS > [0.031s] > [INFO] Cocoon Deployer - Maven 2 Plugin .. SUCCESS > [9.500s] > [INFO] Cocoon-samples-style-default .. SUCCESS > [2.859s] > [INFO] Apples Block Samples .. SUCCESS > [2.516s] > [INFO] Core-samples-additional Block Samples . SUCCESS > [11.688s] > [INFO] Forms Block Samples ... SUCCESS > [15.312s] > [INFO] Template Block Samples SUCCESS > [0.906s] > [INFO] Cocoon Licenses ... SUCCESS > [8.016s] > [INFO] Cocoon Commons [modules] .. SUCCESS > [0.078s] > [INFO] Cocoon Blocks Framework Implementation SUCCESS > [3.781s] > [INFO] Cocoon Servlet Service Implementation . SUCCESS > [3.672s] > [INFO] Cocoon Servlet Service Sample Blocks .. SUCCESS > [3.250s] > [INFO] Cocoon Webapp . SUCCESS > [17.891s] > [INFO] Cocoon Archetypes [modules] ... SUCCESS > [0.281s] > [INFO] Cocoon 2.2 Block Archetype SUCCESS > [7.344s] > [INFO] Cocoon 2.2 Webapp Archetype ... SUCCESS > [1.890s] > [INFO] Demo of the Cocoon block deployer . SUCCESS > [1.688s] > [INFO] Cocoon Reloading ClassLoader [modules] SUCCESS > [0.031s] > [INFO] Cocoon Reloading ClassLoader - webapp wrapper . SUCCESS > [5.531s] > [INFO] Cocoon Reloading Classloader - Maven 2 Plugin . SUCCESS > [9.438s] > [INFO] Cocoon Maven Skin . SUCCESS > [2.375s] > [INFO] Cocoon Distributions [modules] SUCCESS > [0.187s] -- Leszek GawronCTO at MobileBox Ltd.
Re: Importing Cocoon projects into Eclipse
Mark Lundquist wrote: > > On Jan 11, 2007, at 12:35 PM, Grzegorz Kossakowski wrote: > >> You have to set up variable 'M2_REPO' in Eclipse (in build classpath >> settings somewhere) to point on the directory where your Maven's repo >> sit. >> > > yes... thanks :-) > —ml— > you can also use mvn eclipse:add-maven-repo -Dworkspace=workspaceLocation the plugin will take care of M2_REPO variable. http://maven.apache.org/plugins/maven-eclipse-plugin/add-maven-repo-mojo.html -- Leszek GawronCTO at MobileBox Ltd.
Can't build trunk with a clean maven repository
Hi, Cocoon doesn't seem to build when I clean my local maven repository. I get the following error: Missing: -- 1) org.apache.cocoon:cocoon-pipeline-impl:test-jar:tests:1.0.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.cocoon -DartifactId=cocoon-pipeline-impl \ -Dversion=1.0.0-SNAPSHOT -Dpackaging=test-jar -Dfile=/path/to/file Path to dependency: 1) org.apache.cocoon:cocoon-pipeline-components:jar:1.0.0-SNAPSHOT 2) org.apache.cocoon:cocoon-pipeline-impl:test-jar:tests:1.0.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.cocoon:cocoon-pipeline-components:jar:1.0.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache.snapshot (http://people.apache.org/repo/m2-snapshot-repository), apache-cvs (http://people.apache.org/repo/m1-snapshot-repository) I found this page [1] to report a similair error. It says that this is because of failing tests, but passing -Dmaven.test.skip=true doesn't make any difference. Anybody any idea? Bart. [1] http://mail-archives.apache.org/mod_mbox/cocoon-dev/200605.mbox/%3Ce34i0 [EMAIL PROTECTED]
Re: Importing Cocoon projects into Eclipse
On Jan 11, 2007, at 12:35 PM, Grzegorz Kossakowski wrote: You have to set up variable 'M2_REPO' in Eclipse (in build classpath settings somewhere) to point on the directory where your Maven's repo sit. yes... thanks :-) —ml—
Re: RFC: CForms Roadmap
Jason Johnston schrieb:
Can't you just escape the "."?
#myform\.somefield {...}
I remember CSS selectability was discussed back when the id naming rules
were being proposed, and I thought I remembered this working correctly
in the major browsers.
Here's some thread linkage:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=css+escape+cforms+widget+id&q=b
Thanks, escaping works. Would be cool to have that hint in the CForms
documentation.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
[jira] Commented: (COCOON-1981) Allow to call any function
[
https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464680
]
Mark Lundquist commented on COCOON-1981:
Please delete the first two of the three attached files. The first one was too
big a diff and included unrelated changes to a different file. The second is
identical (botched attempt to correct the first).
The third file is the good patch file.
> Allow to call any function
> -
>
> Key: COCOON-1981
> URL: https://issues.apache.org/jira/browse/COCOON-1981
> Project: Cocoon
> Issue Type: Improvement
> Components: - Flowscript
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Mark Lundquist
>Priority: Minor
> Attachments: 1981.patch, 1981.patch, 1981.patch
>
>
> Currently, can only call a function that is a property of the
> flowscript global scope itself. This patch allows it to call any function in
> the global scope, e.g. "foo.bar.baz".
> I provided this code change originally to Jeremy Quinn who committed it to
> BRANCH_2_1_X, but it has not yet been incorporated into trunk.
> The only additional thing I would suggest... would it be worth it to test if
> funName.contains ("."), and if so look up the function the old way? Don't
> know if that's significantly faster...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1981) Allow to call any function
[
https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Lundquist updated COCOON-1981:
---
Attachment: 1981.patch
> Allow to call any function
> -
>
> Key: COCOON-1981
> URL: https://issues.apache.org/jira/browse/COCOON-1981
> Project: Cocoon
> Issue Type: Improvement
> Components: - Flowscript
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Mark Lundquist
>Priority: Minor
> Attachments: 1981.patch, 1981.patch, 1981.patch
>
>
> Currently, can only call a function that is a property of the
> flowscript global scope itself. This patch allows it to call any function in
> the global scope, e.g. "foo.bar.baz".
> I provided this code change originally to Jeremy Quinn who committed it to
> BRANCH_2_1_X, but it has not yet been incorporated into trunk.
> The only additional thing I would suggest... would it be worth it to test if
> funName.contains ("."), and if so look up the function the old way? Don't
> know if that's significantly faster...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1981) Allow to call any function
[
https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Lundquist updated COCOON-1981:
---
Attachment: 1981.patch
> Allow to call any function
> -
>
> Key: COCOON-1981
> URL: https://issues.apache.org/jira/browse/COCOON-1981
> Project: Cocoon
> Issue Type: Improvement
> Components: - Flowscript
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Mark Lundquist
>Priority: Minor
> Attachments: 1981.patch, 1981.patch
>
>
> Currently, can only call a function that is a property of the
> flowscript global scope itself. This patch allows it to call any function in
> the global scope, e.g. "foo.bar.baz".
> I provided this code change originally to Jeremy Quinn who committed it to
> BRANCH_2_1_X, but it has not yet been incorporated into trunk.
> The only additional thing I would suggest... would it be worth it to test if
> funName.contains ("."), and if so look up the function the old way? Don't
> know if that's significantly faster...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1981) Allow to call any function
[
https://issues.apache.org/jira/browse/COCOON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Lundquist updated COCOON-1981:
---
Attachment: 1981.patch
> Allow to call any function
> -
>
> Key: COCOON-1981
> URL: https://issues.apache.org/jira/browse/COCOON-1981
> Project: Cocoon
> Issue Type: Improvement
> Components: - Flowscript
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Mark Lundquist
>Priority: Minor
> Attachments: 1981.patch
>
>
> Currently, can only call a function that is a property of the
> flowscript global scope itself. This patch allows it to call any function in
> the global scope, e.g. "foo.bar.baz".
> I provided this code change originally to Jeremy Quinn who committed it to
> BRANCH_2_1_X, but it has not yet been incorporated into trunk.
> The only additional thing I would suggest... would it be worth it to test if
> funName.contains ("."), and if so look up the function the old way? Don't
> know if that's significantly faster...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1981) Allow to call any function
Allow to call any function
-
Key: COCOON-1981
URL: https://issues.apache.org/jira/browse/COCOON-1981
Project: Cocoon
Issue Type: Improvement
Components: - Flowscript
Affects Versions: 2.2-dev (Current SVN)
Reporter: Mark Lundquist
Priority: Minor
Currently, can only call a function that is a property of the
flowscript global scope itself. This patch allows it to call any function in
the global scope, e.g. "foo.bar.baz".
I provided this code change originally to Jeremy Quinn who committed it to
BRANCH_2_1_X, but it has not yet been incorporated into trunk.
The only additional thing I would suggest... would it be worth it to test if
funName.contains ("."), and if so look up the function the old way? Don't know
if that's significantly faster...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
