[jira] Updated: (COCOON-1945) Mounting the same subsitemap multiple time, but with different prefixes, causes an error
[
https://issues.apache.org/jira/browse/COCOON-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Gianni updated COCOON-1945:
--
Attachment: patch-1945.diff
The new patch, cause files were moved since when i opened this bug.
> Mounting the same subsitemap multiple time, but with different prefixes,
> causes an error
>
>
> Key: COCOON-1945
> URL: https://issues.apache.org/jira/browse/COCOON-1945
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Simone Gianni
> Attachments: patch-1945.diff
>
>
> Suppose I have a subsitemap that generates XML documents, and then i want to
> mount it with different prefixes. For example :
>
>
>
>
>
>
>
>
> The second call with cocoon:// fails with the cause that
> "/otherprefix/docs/blabla does not start with /originalprefix/".
> This is because in MountNode getProcessor() the TreeProcessors are cached
> based on their source (mysubfolder/sitemap.xmap), but not regarding their
> prefix.
> I "solved" this using also the prefix in the cache key :
> Index:
> src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
> ===
> ---
> src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
> (revision 449416)
> +++
> src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
> (working copy)
> @@ -135,13 +135,13 @@
> private synchronized TreeProcessor getProcessor(String source, String
> prefix)
> throws Exception {
> -TreeProcessor processor = (TreeProcessor) processors.get(source);
> +TreeProcessor processor = (TreeProcessor) processors.get(source +
> "||" + prefix);
> if (processor == null) {
> processor = this.parentProcessor.createChildProcessor(source,
> this.checkReload, prefix);
> // Associate to the original source
> -processors.put(source, processor);
> +processors.put(source + "||" + prefix, processor);
> }
> return processor;
> But this means that two tree processors gets generated to represent the same
> sitemap, with only the prefix changing. I'm sure that there is a best way to
> do it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-1978) JXTemplate often fail a method call without giving any error
JXTemplate often fail a method call without giving any error
Key: COCOON-1978
URL: https://issues.apache.org/jira/browse/COCOON-1978
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Affects Versions: 2.2-dev (Current SVN)
Reporter: Simone Gianni
When calling a method on an instance in JXTemplate, if that method does not
exist (or JX cannot find the proper method based on parameters), it fails
without any error. IMO it should raise an error, or at least should raise it in
dev mode, because not having a debugger it takes hours to figure out why it's
not working.
As an example, take a JX and try to call a method that does not exist :
Any will simply be null. Moreover, even if "any" is then used :
${any.getSomethingElse()}
Again it will fail without any error, resulting simply in an empty string,
making it even harder.
Being a non compiled language already makes it difficult to make sure calls are
correct, having this "silent fail" behavior makes it even harder, and if you
add also the non typized nature it can make it a nightmare.
Anyway, I don't know if there is a way to fix this in cocoon or if it is a Jexl
design problem.
--
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] Closed: (COCOON-1966) XML and Bean binding 'add two contacts' button adds one row
[ http://issues.apache.org/jira/browse/COCOON-1966?page=all ] Simone Gianni closed COCOON-1966. - Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed > XML and Bean binding 'add two contacts' button adds one row > --- > > Key: COCOON-1966 > URL: http://issues.apache.org/jira/browse/COCOON-1966 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.1.10-dev (current SVN) >Reporter: Jeroen Reijn > Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > > Attachments: RepeaterActionDefinition.java.patch, > RepeaterActionDefinitionBuilder.java.patch > > > The XML and Bean binding forms sample has an 'add two contacts' button, but > adds only one row instead of the expected 2 rows. -- 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] Commented: (COCOON-1966) XML and Bean binding 'add two contacts' button adds one row
[ http://issues.apache.org/jira/browse/COCOON-1966?page=comments#action_12456914 ] Simone Gianni commented on COCOON-1966: --- Thank Jeroen, applied. Was my fault :) > XML and Bean binding 'add two contacts' button adds one row > --- > > Key: COCOON-1966 > URL: http://issues.apache.org/jira/browse/COCOON-1966 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.1.10-dev (current SVN) >Reporter: Jeroen Reijn > Attachments: RepeaterActionDefinition.java.patch, > RepeaterActionDefinitionBuilder.java.patch > > > The XML and Bean binding forms sample has an 'add two contacts' button, but > adds only one row instead of the expected 2 rows. -- 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] Commented: (COCOON-1961) Cocoon deployer plugin given null pointer cause of maven limitations on subclassing
[ http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455233 ] Simone Gianni commented on COCOON-1961: --- Uops, forgot the NPE stacktrace : java.lang.NullPointerException at org.apache.maven.plugin.war.AbstractWarMojo.unpack(AbstractWarMojo.java:704) at org.apache.maven.plugin.war.AbstractWarMojo.unpackWarToTempDirectory(AbstractWarMojo.java:680) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:600) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:379) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:182) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:64) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Cocoon deployer plugin given null pointer cause of maven limitations on > subclassing > --- > > Key: COCOON-1961 > URL: http://issues.apache.org/jira/browse/COCOON-1961 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Simone Gianni >Priority: Blocker > > Currently, trying to build (mvn package for example) a dist, throws a null > pointer exception. Stack trace follows. > The problem is that the property archiverManager of AbstractWarMojo is null. > The problem is simply summarized here : > http://www.mail-archive.com/dev@maven.apache.org/msg60770.html , a mojo > should not subclass another mojo cause the super one will not be inited by > maven. > In that mail is written "You'll need to redefine that parameter if you want > to use it in the xdoclet [subclass] plugin". Don't know exactly what this > means, cause redefining a private field will not fill the super one and AFAIK > there is no way to define a maven @parameter not associated to a declared > field. > I've opened an issue on maven jira about subdividing the WAR plugin in > separate goals, so that it will be possible to write plugins that operates on > the WAR directory structure, and stack them in the package lifecycle phase in > an order like "war:prepare, cocoon:deploy, what:else, war:package". This is > http://jira.codehaus.org/browse/MWAR-86 . > I will try to modify the war plugin this way, and test it with a mock plugin. > In case someone manages to have it working, then we could rewrite the cocoon > deployer in a way that does not subclass the war mojo, but only operates on > the war directory structure. -- 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] Commented: (COCOON-1961) Cocoon deployer plugin given null pointer cause of maven limitations on subclassing
[ http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455232 ] Simone Gianni commented on COCOON-1961: --- I submitted a patch for http://jira.codehaus.org/browse/MWAR-86 and tested it locally with a plugin that, as the cocoon-deployer, needs to work on an exploded war before it gets compressed. Please vote for http://jira.codehaus.org/browse/MWAR-86, IMO it's vital to have a cocoon-deployer not directly depending on the WarMojo, so more pluggable and without the NPE. > Cocoon deployer plugin given null pointer cause of maven limitations on > subclassing > --- > > Key: COCOON-1961 > URL: http://issues.apache.org/jira/browse/COCOON-1961 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Simone Gianni >Priority: Blocker > > Currently, trying to build (mvn package for example) a dist, throws a null > pointer exception. Stack trace follows. > The problem is that the property archiverManager of AbstractWarMojo is null. > The problem is simply summarized here : > http://www.mail-archive.com/dev@maven.apache.org/msg60770.html , a mojo > should not subclass another mojo cause the super one will not be inited by > maven. > In that mail is written "You'll need to redefine that parameter if you want > to use it in the xdoclet [subclass] plugin". Don't know exactly what this > means, cause redefining a private field will not fill the super one and AFAIK > there is no way to define a maven @parameter not associated to a declared > field. > I've opened an issue on maven jira about subdividing the WAR plugin in > separate goals, so that it will be possible to write plugins that operates on > the WAR directory structure, and stack them in the package lifecycle phase in > an order like "war:prepare, cocoon:deploy, what:else, war:package". This is > http://jira.codehaus.org/browse/MWAR-86 . > I will try to modify the war plugin this way, and test it with a mock plugin. > In case someone manages to have it working, then we could rewrite the cocoon > deployer in a way that does not subclass the war mojo, but only operates on > the war directory structure. -- 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] Created: (COCOON-1961) Cocoon deployer plugin given null pointer cause of maven limitations on subclassing
Cocoon deployer plugin given null pointer cause of maven limitations on subclassing --- Key: COCOON-1961 URL: http://issues.apache.org/jira/browse/COCOON-1961 Project: Cocoon Issue Type: Bug Components: - Build System: Maven Affects Versions: 2.2-dev (Current SVN) Reporter: Simone Gianni Priority: Blocker Currently, trying to build (mvn package for example) a dist, throws a null pointer exception. Stack trace follows. The problem is that the property archiverManager of AbstractWarMojo is null. The problem is simply summarized here : http://www.mail-archive.com/dev@maven.apache.org/msg60770.html , a mojo should not subclass another mojo cause the super one will not be inited by maven. In that mail is written "You'll need to redefine that parameter if you want to use it in the xdoclet [subclass] plugin". Don't know exactly what this means, cause redefining a private field will not fill the super one and AFAIK there is no way to define a maven @parameter not associated to a declared field. I've opened an issue on maven jira about subdividing the WAR plugin in separate goals, so that it will be possible to write plugins that operates on the WAR directory structure, and stack them in the package lifecycle phase in an order like "war:prepare, cocoon:deploy, what:else, war:package". This is http://jira.codehaus.org/browse/MWAR-86 . I will try to modify the war plugin this way, and test it with a mock plugin. In case someone manages to have it working, then we could rewrite the cocoon deployer in a way that does not subclass the war mojo, but only operates on the war directory structure. -- 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] Commented: (COCOON-1945) Mounting the same subsitemap multiple time, but with different prefixes, causes an error
[
http://issues.apache.org/jira/browse/COCOON-1945?page=comments#action_12455214
]
Simone Gianni commented on COCOON-1945:
---
Also, connected to this one, there is the way the ConcreteTreeProcessor checks
which processor should execute a certain sitemap. I don't understand the
newEnv.getURIPrefix().equals("") thing, because if i have a mount like this :
It then reroutes cocoon:/ inside mysubsitemap to the root one, which is IMO
wrong.
Since there is another way (the way used inthe SitemapSource) to check wether a
cocoon: uri has to go to the root or not, why not use it?
Index:
core/cocoon-core/src/main/java/org/apache/cocoon/components/treeprocessor/ConcreteTreeProcessor.java
===
---
core/cocoon-core/src/main/java/org/apache/cocoon/components/treeprocessor/ConcreteTreeProcessor.java
(revision 449416)
+++
core/cocoon-core/src/main/java/org/apache/cocoon/components/treeprocessor/ConcreteTreeProcessor.java
(working copy)
@@ -299,7 +299,7 @@
// Get the processor that should process this request
ConcreteTreeProcessor processor;
-if (newEnv.getURIPrefix().equals("")) {
+if (info.processFromRoot) {
processor = ((TreeProcessor)getRootProcessor()).concreteProcessor;
} else {
processor = this;
> Mounting the same subsitemap multiple time, but with different prefixes,
> causes an error
>
>
> Key: COCOON-1945
> URL: http://issues.apache.org/jira/browse/COCOON-1945
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Simone Gianni
>
> Suppose I have a subsitemap that generates XML documents, and then i want to
> mount it with different prefixes. For example :
>
>
>
>
>
>
>
>
> The second call with cocoon:// fails with the cause that
> "/otherprefix/docs/blabla does not start with /originalprefix/".
> This is because in MountNode getProcessor() the TreeProcessors are cached
> based on their source (mysubfolder/sitemap.xmap), but not regarding their
> prefix.
> I "solved" this using also the prefix in the cache key :
> Index:
> src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
> ===
> ---
> src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
> (revision 449416)
> +++
> src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
> (working copy)
> @@ -135,13 +135,13 @@
> private synchronized TreeProcessor getProcessor(String source, String
> prefix)
> throws Exception {
> -TreeProcessor processor = (TreeProcessor) processors.get(source);
> +TreeProcessor processor = (TreeProcessor) processors.get(source +
> "||" + prefix);
> if (processor == null) {
> processor = this.parentProcessor.createChildProcessor(source,
> this.checkReload, prefix);
> // Associate to the original source
> -processors.put(source, processor);
> +processors.put(source + "||" + prefix, processor);
> }
> return processor;
> But this means that two tree processors gets generated to represent the same
> sitemap, with only the prefix changing. I'm sure that there is a best way to
> do it.
--
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] Commented: (COCOON-1946) [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates
[
http://issues.apache.org/jira/browse/COCOON-1946?page=comments#action_12446403
]
Simone Gianni commented on COCOON-1946:
---
Tested with file cocoon-javaflow-r470120.diff, works correctly.
> [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and
> showing cform templates
> ---
>
> Key: COCOON-1946
> URL: http://issues.apache.org/jira/browse/COCOON-1946
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Java Flow
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Maurizio Pillitu
> Attachments: cocoon-javaflow-r469213.diff,
> cocoon-javaflow-r470120.diff
>
>
> In order to enable the runtime Javaflow class enhancement, the sitemap must
> provide a map:classloader configuration, defining the class-dir folder to be
> monitored. Since the class-dir may contain also non .class files, the
> BCELTransformer crashes whether the resource to transform is not a .class
> file.
> This patch introduces a JavaflowResourceStore that wraps the Commons
> JavaflowResourceStore and parses the include/exclude elements of the
> map:classloader sitemap configuration.
> Additionally, it fixes some bugs in the sample cforms, related to the
> Continuation references of the form templates:
> the reference #{$continuation/id}.cont must be changed to
> #{$cocoon/continuation/id}
--
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] Commented: (COCOON-1929) [PATCH] Reloading classloader in Cocoon 2.2
[ http://issues.apache.org/jira/browse/COCOON-1929?page=comments#action_12446402 ] Simone Gianni commented on COCOON-1929: --- Tested file cocoon-core-r469213.diff, seems to work correctly. > [PATCH] Reloading classloader in Cocoon 2.2 > --- > > Key: COCOON-1929 > URL: http://issues.apache.org/jira/browse/COCOON-1929 > Project: Cocoon > Issue Type: Task > Components: * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) >Reporter: Maurizio Pillitu > Attachments: cocoon-core-r469213.diff, cocoon-r469167.diff, > cocoon.diff > > > The attached patch provides a first implementation to enable reloading > classloader configuration into the sitemap, using the sitemap syntax used in > blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/sitemap.xmap. > Referring to CocoonGT 2005 Torsten's code, I moved all the JCI listener > configuration into the ReloadingClassLoaderFactory class, that is in charge > to parse the classloader configuration (filled by AvalonUtils class) and > instanciate all the JCI listeners. > The TreeProcessor component is subscribed to the JCI listeners, in order to > reload the component definitions when a file change event is triggered. > The patch provides also a sample : > http://localhost:/blocks/cocoon-core-main-sample/reloading/ > Try to change MyGenerator.java and compile it into > blocks/cocoon-core-sample/cocoon-core-main-sample/target/classes (default > eclipse location); if you need to change the location of the .class folder, > edit the cocoon-core-main-sample sitemap.xmap. > core. > Obviously there are many parts of the code that can be optimized. > The patch has been applied on revision 453682. > NOTE! > 1. I decided to provide the reloading class functionality only for dev mode, > so, in order to get it working, you need to run the cocoon application with > -Dorg.apache.cocoon.mode=dev > 2. The patch depends on a bugfix on Commons JCI > (https://issues.apache.org/jira/browse/SANDBOX-174), so it's necessary to > build jci-core from trunk; the patch will update the cocoon-bootstrap > dependency to jci. -- 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] Created: (COCOON-1945) Mounting the same subsitemap multiple time, but with different prefixes, causes an error
Mounting the same subsitemap multiple time, but with different prefixes, causes
an error
Key: COCOON-1945
URL: http://issues.apache.org/jira/browse/COCOON-1945
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Simone Gianni
Suppose I have a subsitemap that generates XML documents, and then i want to
mount it with different prefixes. For example :
The second call with cocoon:// fails with the cause that
"/otherprefix/docs/blabla does not start with /originalprefix/".
This is because in MountNode getProcessor() the TreeProcessors are cached based
on their source (mysubfolder/sitemap.xmap), but not regarding their prefix.
I "solved" this using also the prefix in the cache key :
Index:
src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
===
---
src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
(revision 449416)
+++
src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
(working copy)
@@ -135,13 +135,13 @@
private synchronized TreeProcessor getProcessor(String source, String
prefix)
throws Exception {
-TreeProcessor processor = (TreeProcessor) processors.get(source);
+TreeProcessor processor = (TreeProcessor) processors.get(source + "||"
+ prefix);
if (processor == null) {
processor = this.parentProcessor.createChildProcessor(source,
this.checkReload, prefix);
// Associate to the original source
-processors.put(source, processor);
+processors.put(source + "||" + prefix, processor);
}
return processor;
But this means that two tree processors gets generated to represent the same
sitemap, with only the prefix changing. I'm sure that there is a best way to do
it.
--
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] Commented: (COCOON-1655) JavaFlow/CForm/select-list crash
[
http://issues.apache.org/jira/browse/COCOON-1655?page=comments#action_12439543
]
Simone Gianni commented on COCOON-1655:
---
I have it tested for javaflow 2.1, don't even know if 2.2 is affected by the
same problem and if this is a good solution for it as well. Should ask Torsten.
Anyway I'll commit the 2.1 fix ASAP.
> JavaFlow/CForm/select-list crash
>
>
> Key: COCOON-1655
> URL: http://issues.apache.org/jira/browse/COCOON-1655
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Java Flow
>Affects Versions: 2.1.7
> Environment: Operating System: other
> Platform: Other
>Reporter: Benoit Deshaies
> Assigned To: Cocoon Developers Team
> Attachments: javaflow-continuationstack.diff
>
>
> I get an error whenever I include an
> where
> both the form and the XYZ pipeline use JavaFlow. The error is:
> No continuation is running
> cause: java.lang.IllegalStateException: No continuation is running
> java.lang.IllegalStateException: No continuation is running
> at
> org.apache.cocoon.components.flow.java.Continuation.suspend(Continuation.java:79)
> at
> org.apache.cocoon.components.flow.java.AbstractContinuable.sendPageAndWait(AbstractContinuable.java:75)
> at
> org.apache.cocoon.forms.flow.java.FormInstance.show(FormInstance.java:181)
> The reason is that when cocoon:/XYZ runs, a continuation is created for the
> same
> thread as the form continuation. The continuationsmap in Continuation class
> gets
> overwritten. When cocoon:/XYZ returns, the map is cleared for the thread,
> leaving no continuation for the form.
> Here's a bit of code from the app to help explain.
> The form contains a selection list defined as:
>
>
>
>
> The sitemap contains:
>
>
>
> Then I have the following JavaFlow
> public void doGenerateUserList() throws Exception {
>Collection userList = databaseManager.getUserList();
>sendPage("user_list", new VarMap().add("list", userList) );
> }
--
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] Commented: (COCOON-1379) [i18n] extending the I18nTransformer
[ http://issues.apache.org/jira/browse/COCOON-1379?page=comments#action_12439250 ] Simone Gianni commented on COCOON-1379: --- Has this ever been fixed? Because i recently committed a modification to i18n transformer to made a couple of method protected instead of private, and has been enought for me to subclass the i18n transformer. > [i18n] extending the I18nTransformer > > > Key: COCOON-1379 > URL: http://issues.apache.org/jira/browse/COCOON-1379 > Project: Cocoon > Issue Type: Improvement > Components: * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: All > Platform: All >Reporter: Christoph Gaffga > Assigned To: Cocoon Developers Team >Priority: Minor > Attachments: AbstractI18nTransformer.java, I18nTransformer.java > > > copy of my mail to dev@cocoon.apache.org: > - > (see source attached) > recently I needed to extend cocoon's I18nTransfomer for loading multiple sets > of catalogues for different pipelines. The information what catalogues form a > set, which sets to use for the different pipelines was stored in DB. So I had > to > change a lot and recognized that it is quite difficult for me to extend the > existing I18N transformer. > The Idea was, whenever cocoon's I18N transformer is enhanced with some more > functionallity, my new transfomer should support the features too. > With the existing I18nTransformer class this seems not to be possible. So my > Idea was to move all the stuff doing the real transformations, implementing > the > logic for the i18n:*-Elements and doing lookups in the catalugues to an > abstract > class called AbstractI18nTransformer. > Now the cocoon I18nTransformer extends this class and implements only the > logic > for loading the right catalogues as configured in the sitemap, mainly the > setup(..) and configure(..) methods and the Cachable interface are > implemented here. > Like this I have a nice separation between the real transforming part and the > part loading and configuring the catalogues. Now I can simply extend this > AbstractI18nTransformer and add my own catalogue loading logic. > Coming back to my point that I want to have enhancments to the I18n functions > also in my transfomer without editing my code again and again: My separation > of > the two parts of the I18n transfomer only makes sense if there is some > interest > in having this AbstractI18nTransformer integrated into cocoon. > So I'd like to know if there is some interest in having this change integrated > into cocoon. > I sent my example how this separation could be done as an enhancement to the > bugzilla. Would be nice to hear some thoughts about the idea. > kind regards, > Christoph Gaffga > [EMAIL PROTECTED] -- 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] Commented: (COCOON-1898) [PATCH] XPatch support for maven-cocoon-deployer-plugin
[ http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432339 ] Simone Gianni commented on COCOON-1898: --- Sorry to jump on this issue so late, but I also was in the need for a patching mechanism for web.xml and other files, and came up with another solution, mainly because i don't like XPatch that much (had to fight with it a lot in the past). I aldready developed and I'm using internally the mvn plugin for it, it works using a src/main/xpatch folder, containing the patch files, so for example to patch the web xml you create a file src/main/xpatch/WEB-INF/web.xml-adding-filter.xml. My xml patching syntax is by far simpler than xpatch, for example to add a filter in the web.xml you just have to write a file like this : http://xpatch/1.0";> MyFilter My filter param value MyFilter Cocoon For many other tasks it's even simpler, for example to add a new match on the root sitemap, this is enought : http://apache.org/cocoon/sitemap/1.0";> and the new match will be added as the last element of the first encountered pipeline. I'm planning to contribute this anyway, so let me know if it could be a good alternative. > [PATCH] XPatch support for maven-cocoon-deployer-plugin > --- > > Key: COCOON-1898 > URL: http://issues.apache.org/jira/browse/COCOON-1898 > Project: Cocoon > Issue Type: Improvement > Components: - Build System: Maven >Affects Versions: 2.2-dev (Current SVN) >Reporter: Lars Trieloff > Attachments: maven-cocoon-deployer-plugin-with-xpatch-support.patch > > > The cocoon-deployer-plugin has currently no support for XPatch, which makes > it difficult to modify the web.xml when developing cocoon blocks. For example > the cocoon-xmldb-impl block should add, when deployed, a servlet for xindice > and a servlet mapping for the xindice servlet. This was possible in 2.1 using > the XConfToolTask, but is no longer possible with the current state of the > deployer-plugin. > My patch adds support for patching the web.xml file using *.xweb files in the > /conf directory of a block by filtering the block's jar file during > deployment for conf/*.xweb files, caching the patch document temporarily and > applying them (using code from the orgiginal XConfToolTask in 2.1) to the > web.xml. The patch has currently no support for other files than conf/*.xweb > files and does not support any property expansion. -- 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] Commented: (COCOON-1758) Form locale never used in JXMacros
[
http://issues.apache.org/jira/browse/COCOON-1758?page=comments#action_12427261
]
Simone Gianni commented on COCOON-1758:
---
The code in jx-macros actually calls cocoon.parameter.getParameter('locale').
Unfortunately, if a locale is not specified, this brings to an exception, since
a default value is not given.
This beaks compatibility with previous 2.1 versions, and in general IMMO having
to specify explicitly a local for every form template is verbose.
I think this should be substituted with getParameter('locale',null), and
subseguently in the JXMacrosHelper the given locale must be used, if present,
otherwise the request one, otherwise the default one.
I have this fix on my version, but wanted to know if this is the intended
behaviour before committing.
> Form locale never used in JXMacros
> --
>
> Key: COCOON-1758
> URL: http://issues.apache.org/jira/browse/COCOON-1758
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Forms
>Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9
>Reporter: Philippe Gassmann
> Assigned To: Antonio Gallardo
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
> Attachments: 20060201-cocoon-forms-1758, patch.txt, patch1.txt
>
>
> The JXMacroHelper is created with : value="#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request,$cocoon/parameters/locale)}"/>
> So the locale is get from sitemap parameters.
> the locale attribute of the form is then never used.
> I will provide a patch as soon as possible
--
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] Commented: (COCOON-1877) [PATCH] Pageable Repeater
[ http://issues.apache.org/jira/browse/COCOON-1877?page=comments#action_12424074 ] Simone Gianni commented on COCOON-1877: --- Committed this part, we tested it on a heavy hibernate backed application where we use repeaters to output enormous (11000+items) lists, and works. Things to do : - A page number widget, with jump to page links - Row insertion and deletion and harmonization with pages - Disabling action buttons when we are in the first/last page > [PATCH] Pageable Repeater > - > > Key: COCOON-1877 > URL: http://issues.apache.org/jira/browse/COCOON-1877 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Forms >Reporter: Matthias Epheser > Attachments: repeater-pagination-2.patch, repeater-pagination.patch > > > This patch provides simple pagination for the repeater widget using the > binding. > It consists of 3 main parts: It extends the repeater-definition to configure > the pages, adds a ChangePageAction for userinteraction and modifies the > binding so savePage/loadPage can be performed after the action is called. > Speaking of a first demo with basic functionality there are some known issues > and missing features: > - We plan to use some internal "storage area" inside the binding that > contains the updated rows after a page-change. The real doSave() code should > be called just once after the form was submitted. This should provide better > integration to scenarios where persistence frameworks like hibernate are used. > - The userinterface needs to be extended to features like > next/first/last-page buttons and the common "first 1 2 3 4 5 next" group of > links to choose pages directly. > - Filtering and Sorting of the rows would be nice and could maybe > accomplished extending the storage area implementation. -- 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] Commented: (COCOON-1879) Make fd:field whitespace trimming behavior configurable
[ http://issues.apache.org/jira/browse/COCOON-1879?page=comments#action_12420150 ] Simone Gianni commented on COCOON-1879: --- If you're going to use a typesafe enumeration, then consider using org.apache.commons.lang.enums.Enum, not to reinvent the wheel and also because could save you some work. See http://jakarta.apache.org/commons/lang/ > Make fd:field whitespace trimming behavior configurable > --- > > Key: COCOON-1879 > URL: http://issues.apache.org/jira/browse/COCOON-1879 > Project: Cocoon > Type: Improvement > Components: Blocks: Forms > 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=11496023148&r=1&w=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-1871) Flexible Content Aggregation sample does not work
[ http://issues.apache.org/jira/browse/COCOON-1871?page=all ] Simone Gianni closed COCOON-1871: - Fix Version: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed The paranoid classloader solved the problem in revision 417427. > Flexible Content Aggregation sample does not work > - > > Key: COCOON-1871 > URL: http://issues.apache.org/jira/browse/COCOON-1871 > Project: Cocoon > Type: Bug > Components: - Samples > Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > Reporter: Andrew Savory > Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > > On 2.1.10-dev it results in java.lang.ArrayIndexOutOfBoundsException: 10 > On 2.2-dev it results in HTTP ERROR: 500 -- 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] Commented: (COCOON-1871) Flexible Content Aggregation sample does not work
[ http://issues.apache.org/jira/browse/COCOON-1871?page=comments#action_12417847 ] Simone Gianni commented on COCOON-1871: --- Yes, that is the problem, we are now trying to figure out how to put xalan-2.7, xerces and bcel in the endorsed libs so that they will not conflict with JRE versions. In 2.1 this is done with the lib/endorsed dir and the cocoon.sh script, how to do it with jetty run by maven is our current problem. > Flexible Content Aggregation sample does not work > - > > Key: COCOON-1871 > URL: http://issues.apache.org/jira/browse/COCOON-1871 > Project: Cocoon > Type: Bug > Components: - Samples > Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > Reporter: Andrew Savory > > On 2.1.10-dev it results in java.lang.ArrayIndexOutOfBoundsException: 10 > On 2.2-dev it results in HTTP ERROR: 500 -- 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] Commented: (COCOON-1871) Flexible Content Aggregation sample does not work
[ http://issues.apache.org/jira/browse/COCOON-1871?page=comments#action_12417841 ] Simone Gianni commented on COCOON-1871: --- May the problem be in the endorsed libs stuff for xalan? At least this seems to be the problem for 2.2. > Flexible Content Aggregation sample does not work > - > > Key: COCOON-1871 > URL: http://issues.apache.org/jira/browse/COCOON-1871 > Project: Cocoon > Type: Bug > Components: - Samples > Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > Reporter: Andrew Savory > > On 2.1.10-dev it results in java.lang.ArrayIndexOutOfBoundsException: 10 > On 2.2-dev it results in HTTP ERROR: 500 -- 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] Commented: (COCOON-1871) Flexible Content Aggregation sample does not work
[ http://issues.apache.org/jira/browse/COCOON-1871?page=comments#action_12417839 ] Simone Gianni commented on COCOON-1871: --- Currently, under 2.2, the log reports the following exception : java.lang.IncompatibleClassChangeError at org.apache.xalan.xsltc.compiler.UnionPathExpr.setParser(UnionPathExpr.java:75) at org.apache.xalan.xsltc.compiler.Parser.parseTopLevel(Parser.java:1095) at org.apache.xalan.xsltc.compiler.Parser.parseExpression(Parser.java:1053) at org.apache.xalan.xsltc.compiler.ApplyTemplates.parseContents(ApplyTemplates.java:71) at org.apache.xalan.xsltc.compiler.SyntaxTreeNode.parseChildren(SyntaxTreeNode.java:423) at org.apache.xalan.xsltc.compiler.Copy.parseContents(Copy.java:58) at org.apache.xalan.xsltc.compiler.SyntaxTreeNode.parseChildren(SyntaxTreeNode.java:423) at org.apache.xalan.xsltc.compiler.Template.parseContents(Template.java:247) at org.apache.xalan.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:585) at org.apache.xalan.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:557) at org.apache.xalan.xsltc.compiler.Parser.createAST(Parser.java:381) at org.apache.xalan.xsltc.trax.TemplatesHandlerImpl.endDocument(TemplatesHandlerImpl.java:220) at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.cocoon.core.container.spring.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:340) at $Proxy0.parse(Unknown Source) at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:128) at org.apache.cocoon.components.xslt.TraxProcessor.sourceToSAX(TraxProcessor.java:300) at org.apache.cocoon.components.xslt.TraxProcessor.getTransformerHandlerAndValidity(TraxProcessor.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.cocoon.core.container.spring.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:340) at $Proxy7.getTransformerHandlerAndValidity(Unknown Source) at org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:322) What's this? :) > Flexible Content Aggregation sample does not work > - > > Key: COCOON-1871 > URL: http://issues.apache.org/jira/browse/COCOON-1871 > Project: Cocoon > Type: Bug > Components: - Samples > Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) > Reporter: Andrew Savory > > On 2.1.10-dev it results in java.lang.ArrayIndexOutOfBoundsException: 10 > On 2.2-dev it results in HTTP ERROR: 500 -- 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] Created: (COCOON-1872) ajax not working in 2.2
ajax not working in 2.2 --- Key: COCOON-1872 URL: http://issues.apache.org/jira/browse/COCOON-1872 Project: Cocoon Type: Bug Components: Blocks: Ajax Versions: 2.2-dev (Current SVN) Reporter: Simone Gianni Assigned to: Simone Gianni Priority: Critical In current 2.2 the Dojo stuff is not there. This is because (Sylvain told me) the dojo.js we are using is a reduced version of dojo, and in 2.1 there is an ant build file that takes only the parts we need from the complete unzipped dojo stuff and builds a custom .jar file for it. The problem is how to incorporate this in Maven for 2.2. -- 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] Created: (COCOON-1867) BeanConvertor uses a WeakHashMap in the wrong way.
BeanConvertor uses a WeakHashMap in the wrong way. -- Key: COCOON-1867 URL: http://issues.apache.org/jira/browse/COCOON-1867 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.10-dev (current SVN), 2.1.9 Reporter: Simone Gianni Assigned to: Simone Gianni Priority: Critical In the BeanConvertor, when a bean is converted to a string, the bean is stored in a WeakHashMap this way : m_objects.put(idValue, value); Actually idValue is a string representing the bean (toString or evalued on id_path) while the value is the bean. WeakHashMap DOES NOT remove a mapping when the bean is garbage collected, but actually removes it when the KEY is garbage collected. This means that since the string is serialized to XML in the form instance and then dropped, the mapping could be removed even while the user is filling the form, with the conseguence that the convertor stops working, see a null value, reports a validation error, even if the user correctly filled the form. This is even worse when you are using a selection list of beans, because in that case the bean has no chanches to enter the m_objects map anymore, since the selection list has been generated and stored st the beginning of the form (maybe thru flow, or on-create) and is not asking the convertor to convert the beans anymore. A better solution (and IMMO what the author intended to do) is to remove the mapping (so that the map does not hold references for everything) when the BEAN gets garbage collected. In this case I'm experimenting with apache commons ReferenceMap, which actually can remove mappings when the value (bean) is garbage collected. -- 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] Commented: (COCOON-1804) 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=comments#action_12412931
]
Simone Gianni commented on COCOON-1804:
---
Hi Andrew,
you can obtain this functionality :
- Patching your 2.1.9 installation (with the patch command, or with eclipse)
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
> ---
>
> Key: COCOON-1804
> URL: http://issues.apache.org/jira/browse/COCOON-1804
> Project: Cocoon
> Type: Bug
> Components: Blocks: Java Flow
> Versions: 2.1.8
> Reporter: Andrew Madu
> Priority: Blocker
> Fix For: 2.1.10-dev (current SVN)
> Attachments: javaflow-fomcocoon.diff
>
> I have created a java flow class which does the following:
> //Load in validation file
> FormInstance form = new FormInstance("forms/login.xml");
> My login map (snippet) is as follows:
> Login.xml:
>
>
> var success = true;
> var newUserReg = new Packages.test.User();
> var username = widget.lookupWidget("username");
> var password = widget.lookupWidget("password");
>
> try {
>
> var checkUserTest = newUserReg.getUser(username.value,
> password.value);
>
> if (checkUserTest != null) {
> cocoon.session.setAttribute("user", checkUserTest);
> success = true;
> }else{
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("The password,
> username combination does not exist. Please enter another one.", false));
> success = false;
> }
> } catch (e) {
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("e.", false));
> success = false;
> }
> return success;
>
>
> I am getting an error message when the line
> 'cocoon.session.setAttribute("user", checkUserTest)' is hit.:
> ReferenceError: "cocoon" is not defined
> What is the issue here, can I create a session object from within form
> validation/javascript in another way?
> Andrew
--
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-1804) 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 -
> ReferenceError: "cocoon" is not defined
> ---
>
> Key: COCOON-1804
> URL: http://issues.apache.org/jira/browse/COCOON-1804
> Project: Cocoon
> Type: Bug
> Components: Blocks: Java Flow
> Versions: 2.1.8
> Reporter: Andrew Madu
> Priority: Blocker
> Fix For: 2.1.10-dev (current SVN)
> Attachments: javaflow-fomcocoon.diff
>
> I have created a java flow class which does the following:
> //Load in validation file
> FormInstance form = new FormInstance("forms/login.xml");
> My login map (snippet) is as follows:
> Login.xml:
>
>
> var success = true;
> var newUserReg = new Packages.test.User();
> var username = widget.lookupWidget("username");
> var password = widget.lookupWidget("password");
>
> try {
>
> var checkUserTest = newUserReg.getUser(username.value,
> password.value);
>
> if (checkUserTest != null) {
> cocoon.session.setAttribute("user", checkUserTest);
> success = true;
> }else{
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("The password,
> username combination does not exist. Please enter another one.", false));
> success = false;
> }
> } catch (e) {
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("e.", false));
> success = false;
> }
> return success;
>
>
> I am getting an error message when the line
> 'cocoon.session.setAttribute("user", checkUserTest)' is hit.:
> ReferenceError: "cocoon" is not defined
> What is the issue here, can I create a session object from within form
> validation/javascript in another way?
> Andrew
--
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] Commented: (COCOON-1846) [PATCH] BooleanField and radio do not send on-value-changed at the rigth time with IE
[ http://issues.apache.org/jira/browse/COCOON-1846?page=comments#action_12378647 ] Simone Gianni commented on COCOON-1846: --- Has already been solved in 2.1.x / trunk . Thanks for the patch anyway ... you used a different condition, i used : forms_submitForm(this) forms_submitForm(this) I think yours is better, could you explain why you used that conditions? > [PATCH] BooleanField and radio do not send on-value-changed at the rigth time > with IE > - > > Key: COCOON-1846 > URL: http://issues.apache.org/jira/browse/COCOON-1846 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.9 > Reporter: vincent Demay > Assignee: Simone Gianni > > BooleanField and radio list do not send on-value-changed event when the value > changed but when the widget loose focus with IE. > So with ajax mode and submit-on-change='true', the form is submitted only > when the widget lost the focus. > Here is a patch to use event onclick rather than on value change : > --- forms-field-styling.xsl 2006-05-09 14:53:40.014409000 +0200 > +++ forms-field-styling.xsl 2006-05-09 14:45:01.499752000 +0200 > @@ -91,11 +91,20 @@ >+--> > > > - > > - > - forms_submitForm(this) > - > + > + > + > +name="onclick">forms_submitForm(this) > + > + > + > + > +name="onchange">forms_submitForm(this) > + > + > + > + > >disabled -- 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] Assigned: (COCOON-1846) [PATCH] BooleanField and radio do not send on-value-changed at the rigth time with IE
[ http://issues.apache.org/jira/browse/COCOON-1846?page=all ] Simone Gianni reassigned COCOON-1846: - Assign To: Simone Gianni > [PATCH] BooleanField and radio do not send on-value-changed at the rigth time > with IE > - > > Key: COCOON-1846 > URL: http://issues.apache.org/jira/browse/COCOON-1846 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.9 > Reporter: vincent Demay > Assignee: Simone Gianni > > BooleanField and radio list do not send on-value-changed event when the value > changed but when the widget loose focus with IE. > So with ajax mode and submit-on-change='true', the form is submitted only > when the widget lost the focus. > Here is a patch to use event onclick rather than on value change : > --- forms-field-styling.xsl 2006-05-09 14:53:40.014409000 +0200 > +++ forms-field-styling.xsl 2006-05-09 14:45:01.499752000 +0200 > @@ -91,11 +91,20 @@ >+--> > > > - > > - > - forms_submitForm(this) > - > + > + > + > +name="onclick">forms_submitForm(this) > + > + > + > + > +name="onchange">forms_submitForm(this) > + > + > + > + > >disabled -- 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-1782) [PATCH] Support for CSS classes in cocoon forms XSL
[ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
Simone Gianni closed COCOON-1782:
-
Fix Version: 2.1.10-dev (current SVN)
Resolution: Fixed
Also added documentation on zones, but not added to the tree since seems like i
cannot untile the document gets published.
> [PATCH] Support for CSS classes in cocoon forms XSL
> ---
>
> Key: COCOON-1782
> URL: http://issues.apache.org/jira/browse/COCOON-1782
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: 2.1.10-dev (current SVN)
> Attachments: xsl-css-2.diff, xsl-css-trunk.diff, xsl-css.diff
>
> Added CSS classes to key elements in default cocoon forms XSL. Here is a
> brief explanation of how it works :
> ---
> Common fields styling
> The general rule for common fields (styled by forms-field-styling.xsl) is to
> apply the following classes :
> - "forms" : is placed always, to avoid name clashes with already present
> site-specific classes.
> - : can be "field", "action", "output", "booleanfield",
> "multivaluefield", "upload", "repeater", "imagemap", "aggregatefield",
> "form", "messages".
> - : the state of the widget, can be empty, "active", "disbled",
> "output".
> - "required" : if the widget is required.
> - "with-errors" : if there are some fi:validation-messages associated with
> the widget.
> - : an optional, user defined, fi:styling/@class that can be
> specified on a field to fine tune widget styling.
> This technique makes it easy to write very specific CSS rules, as much as
> very general ones. For example :
> input.required {
> color: blue;
> }
> Will make all required inputs have a blue text color, while
> input.upload.required {
> color: red;
> }
> will make only the required upload widgets have a red text color.
> The HTML elements to which this classes will be applied varies depending on
> the widget type and special fi:styling attributes (like list-type for
> selection lists, fi:styling/@type etc..).
> There are also other classes, placed to correctly style other elements, these
> are :
> - "captcha" : applied to the img element of a captcha field.
> - "required-mark" : applied to the span containing the "*" near the required
> fields.
> - "validation-message" : applied to the anchor element containing the "!"
> near the fields with errors.
> - "vertical-list" and "horizontal-list" : applied to the tables used to
> layout these kind of lists.
> - "upload-change-button" : applied to the button that appears next to the
> upload widget when a file has been uploaded.
> For the validation-errors element (which outputs a list of all validation
> errors found in the form) there are other special classes :
> - "validation-errors" : applied to the div that contains the errors recap
> block.
> - "validation-errors-header" and "validation-errors-footer" : applied to the
> paragraphs that contains the header and footer of the errors recap.
> - "validation-errors-content" : applied to the "li" element of the errors
> list.
> Page styling
> Another set of classes is used for page styling (forms-page-styling.xsl). The
> general rule for fi:group is to apply the following classes :
> - "forms" : as always placed to mark a cocoon forms CSS class.
> - "group" : identify a group class
> - or : the fi:styling/@layout or fi:styling/@type of the
> fi:group
> - : an optional, user defined, fi:styling/@class that can be
> specified on a group to fine tune styling.
> As for the widgets, these classes are applied to different HTML elements
> depèending on the group type and layout.
> For those layouts which uses tables, special classes are used to mark
> specific cells :
> - "label" : applied to the "td" containing the label
> - "content" : applied to the "td" containing the form input
> - "action" : applied to the "td" containing an action widget, for those
> layouts that creates special cells for this widgets.
> - "booleanfield" : applied to the "td" containing a booleanfield widget, for
> those layouts that creates special cells for this widgets.
> - "other" : applied to the "td" containing other content, like another nested
> fi:group or non cocoon forms elements.
> Consider this CSS snippet :
> table.group.columns {
> border: 1px solid blue;
> }
> table.group.columns td {
> background: yellow;
> }
> table.group.columns td.label {
> background: blue;
> color: white;
> width: 20%;
> }
> This will style every fi:group with layout "columns" placing a blue border on
> the table, then using a yello background for every cell in the table, while a
> blue blackground, a while text color and a width of 20% will be used for
> cells containing labels.
> A special case of layout is handled directly in the basic xsl
> (forms-fiel
[jira] Assigned: (COCOON-1782) [PATCH] Support for CSS classes in cocoon forms XSL
[ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
Simone Gianni reassigned COCOON-1782:
-
Assign To: Simone Gianni
> [PATCH] Support for CSS classes in cocoon forms XSL
> ---
>
> Key: COCOON-1782
> URL: http://issues.apache.org/jira/browse/COCOON-1782
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Attachments: xsl-css-2.diff, xsl-css-trunk.diff, xsl-css.diff
>
> Added CSS classes to key elements in default cocoon forms XSL. Here is a
> brief explanation of how it works :
> ---
> Common fields styling
> The general rule for common fields (styled by forms-field-styling.xsl) is to
> apply the following classes :
> - "forms" : is placed always, to avoid name clashes with already present
> site-specific classes.
> - : can be "field", "action", "output", "booleanfield",
> "multivaluefield", "upload", "repeater", "imagemap", "aggregatefield",
> "form", "messages".
> - : the state of the widget, can be empty, "active", "disbled",
> "output".
> - "required" : if the widget is required.
> - "with-errors" : if there are some fi:validation-messages associated with
> the widget.
> - : an optional, user defined, fi:styling/@class that can be
> specified on a field to fine tune widget styling.
> This technique makes it easy to write very specific CSS rules, as much as
> very general ones. For example :
> input.required {
> color: blue;
> }
> Will make all required inputs have a blue text color, while
> input.upload.required {
> color: red;
> }
> will make only the required upload widgets have a red text color.
> The HTML elements to which this classes will be applied varies depending on
> the widget type and special fi:styling attributes (like list-type for
> selection lists, fi:styling/@type etc..).
> There are also other classes, placed to correctly style other elements, these
> are :
> - "captcha" : applied to the img element of a captcha field.
> - "required-mark" : applied to the span containing the "*" near the required
> fields.
> - "validation-message" : applied to the anchor element containing the "!"
> near the fields with errors.
> - "vertical-list" and "horizontal-list" : applied to the tables used to
> layout these kind of lists.
> - "upload-change-button" : applied to the button that appears next to the
> upload widget when a file has been uploaded.
> For the validation-errors element (which outputs a list of all validation
> errors found in the form) there are other special classes :
> - "validation-errors" : applied to the div that contains the errors recap
> block.
> - "validation-errors-header" and "validation-errors-footer" : applied to the
> paragraphs that contains the header and footer of the errors recap.
> - "validation-errors-content" : applied to the "li" element of the errors
> list.
> Page styling
> Another set of classes is used for page styling (forms-page-styling.xsl). The
> general rule for fi:group is to apply the following classes :
> - "forms" : as always placed to mark a cocoon forms CSS class.
> - "group" : identify a group class
> - or : the fi:styling/@layout or fi:styling/@type of the
> fi:group
> - : an optional, user defined, fi:styling/@class that can be
> specified on a group to fine tune styling.
> As for the widgets, these classes are applied to different HTML elements
> depèending on the group type and layout.
> For those layouts which uses tables, special classes are used to mark
> specific cells :
> - "label" : applied to the "td" containing the label
> - "content" : applied to the "td" containing the form input
> - "action" : applied to the "td" containing an action widget, for those
> layouts that creates special cells for this widgets.
> - "booleanfield" : applied to the "td" containing a booleanfield widget, for
> those layouts that creates special cells for this widgets.
> - "other" : applied to the "td" containing other content, like another nested
> fi:group or non cocoon forms elements.
> Consider this CSS snippet :
> table.group.columns {
> border: 1px solid blue;
> }
> table.group.columns td {
> background: yellow;
> }
> table.group.columns td.label {
> background: blue;
> color: white;
> width: 20%;
> }
> This will style every fi:group with layout "columns" placing a blue border on
> the table, then using a yello background for every cell in the table, while a
> blue blackground, a while text color and a width of 20% will be used for
> cells containing labels.
> A special case of layout is handled directly in the basic xsl
> (forms-field-styling.xsl), which format with a "columns" similar layout a
> "fi:form". In this case the same classes (label, content etc..) applies.
> Some special classes are used for the tab layout. These ar
[jira] Closed: (COCOON-1844) NPE caused by integer fields which have an but no locale attribute
[ http://issues.apache.org/jira/browse/COCOON-1844?page=all ] Simone Gianni closed COCOON-1844: - Fix Version: 2.1.10-dev (current SVN) Resolution: Fixed Fixed in revision 400045. > NPE caused by integer fields which have an but no locale > attribute > - > > Key: COCOON-1844 > URL: http://issues.apache.org/jira/browse/COCOON-1844 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.9 > Reporter: Dewi Roberts > Assignee: Simone Gianni > Priority: Minor > Fix For: 2.1.10-dev (current SVN) > Attachments: FormattingDecimalConvertor.java.diff > > A NullPointerException is thrown when setting an initial value to a field of > integer datatype without also specifying a locale, but the documentation > states that the locale attribute is optional. The problem is caused when > NumberFormat.getNumberInstance(locale) is passed null instead of using the > NumberFormat.getNumberInstance() method in FormattingDecimalConvertor. > This problem might also affect number, currency and percent datatypes. -- 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] Commented: (COCOON-1844) NPE caused by integer fields which have an but no locale attribute
[ http://issues.apache.org/jira/browse/COCOON-1844?page=comments#action_12378004 ] Simone Gianni commented on COCOON-1844: --- Yep, the problem is there, but unfortunately the given patch only solves the problem for a decimal datatype, with no variant specified. Maybe the right way of doing it is to use the default (system) locale in o.a.c.forms.formmodel.AbstractDatatypeWidgetDefinitionBuilder.setupDefinition() on line 71, and have the convertor always expect a Locale being passed in. > NPE caused by integer fields which have an but no locale > attribute > - > > Key: COCOON-1844 > URL: http://issues.apache.org/jira/browse/COCOON-1844 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.9 > Reporter: Dewi Roberts > Assignee: Simone Gianni > Priority: Minor > Attachments: FormattingDecimalConvertor.java.diff > > A NullPointerException is thrown when setting an initial value to a field of > integer datatype without also specifying a locale, but the documentation > states that the locale attribute is optional. The problem is caused when > NumberFormat.getNumberInstance(locale) is passed null instead of using the > NumberFormat.getNumberInstance() method in FormattingDecimalConvertor. > This problem might also affect number, currency and percent datatypes. -- 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] Assigned: (COCOON-1844) NPE caused by integer fields which have an but no locale attribute
[ http://issues.apache.org/jira/browse/COCOON-1844?page=all ] Simone Gianni reassigned COCOON-1844: - Assign To: Simone Gianni > NPE caused by integer fields which have an but no locale > attribute > - > > Key: COCOON-1844 > URL: http://issues.apache.org/jira/browse/COCOON-1844 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.9 > Reporter: Dewi Roberts > Assignee: Simone Gianni > Priority: Minor > Attachments: FormattingDecimalConvertor.java.diff > > A NullPointerException is thrown when setting an initial value to a field of > integer datatype without also specifying a locale, but the documentation > states that the locale attribute is optional. The problem is caused when > NumberFormat.getNumberInstance(locale) is passed null instead of using the > NumberFormat.getNumberInstance() method in FormattingDecimalConvertor. > This problem might also affect number, currency and percent datatypes. -- 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-1801) [PATCH] Repeater events
[ http://issues.apache.org/jira/browse/COCOON-1801?page=all ] Simone Gianni closed COCOON-1801: - Resolution: Fixed Committed the patch. > [PATCH] Repeater events > --- > > Key: COCOON-1801 > URL: http://issues.apache.org/jira/browse/COCOON-1801 > Project: Cocoon > Type: New Feature > Components: Blocks: Forms > Versions: 2.1.9 > Reporter: Simone Gianni > Attachments: repeaterlistener-sample.diff, repeaterlistener.diff > > Since I felt the need and there are many comments in the code about it, i've > implemented a RepeaterListener. The listener is triggered on row addition, > deletion, reordering and clear. The event also brings informations about the > row index and the actual action that took place. > I've adapted the javascript listener to support this new listener, and in the > meanwhile also noticed that lines 59 to 70 of it are useless, since i believe > that code has been moved inside the JavaScriptHelper methods and those lines > were left there. > I've added a sample in form1, in the contact repeater. It's better to use the > flow version of the sample, since in the no-flow sample the repeater is > always recreated, an all events are broadcasted again. > The usage is simply : > > > > ... > > > I took care to call the event after the row has been initalized and to > provide two events (deleting and deleted) for row deletion, so that accessing > the new or "about to be deleted" row inside the listener should not be a > problem. The forms1.xml listener has an example on how to do this. > The only place where i'm not sure this will always work correctly is inside > the initialize method, maybe the event broadcast should be moved to somewhere > else, or at least after the super.initialize() call, just to make sure that > when the listener gets the event everything is properly set up. > > Please note that the patch includes modifications on the javascript listener > (o.a.c.forms.events.impl.JavaScript*) which i already modified in > COCOON-1781. Regarding this file this patch will conflict with the other one > (since both contains the same modifications) and in part superseedes the > other one (due to the lines i've removed). So please apply the COCOON-1781 > first, then this one, and if having problems applying this one revert the > o.a.c.forms.event.impl.JavaScript* classes and then retry. -- 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-1781) Processing phase listener cannot be configured from form definitio
[ http://issues.apache.org/jira/browse/COCOON-1781?page=all ]
Simone Gianni closed COCOON-1781:
-
Resolution: Fixed
Committed the patch
> Processing phase listener cannot be configured from form definitio
> --
>
> Key: COCOON-1781
> URL: http://issues.apache.org/jira/browse/COCOON-1781
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Reporter: Simone Gianni
> Attachments: phase_listener.diff
>
> It's not currently possible to specify a ProcessingPhaseListener from the
> form definition.
> The patch makes it possible to specify a and specify
> a listener in it. Also patched the javascript listener to support this kind
> of events, so that can be used. For example :
>
>
>
> Packages.java.lang.System.out.println('Processing phase : ' +
> event.getPhase());
>
>
> http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
[ http://issues.apache.org/jira/browse/COCOON-1685?page=all ] Simone Gianni closed COCOON-1685: - Resolution: Fixed Committed fix > Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent > - > > Key: COCOON-1685 > URL: http://issues.apache.org/jira/browse/COCOON-1685 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8 > Reporter: Simone Gianni > Attachments: process_initialize.diff > > In the Form.process() method, there is a listener.phaseEnded on line 296 > which sends a LOAD_MODEL_VALUE the first time the form is executed, and a > READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is > registered it will receive a READ_FROM_REQUEST_VALUE before the request has > been processed, and another one after. > IMMO there are the following possible solutions : > - remove this event broadcast. > - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes > his chance to get broadcasted, while the spurious one doesn't. > - add a "PROCESS_INITIALIZED" phase event and send this one at this point. > I can produce the patch if needed, but don't know which solution is the best > one. -- 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] Created: (COCOON-1822) MultiValueField list-type="double-listbox" does not work correctly in ajax enabled forms
MultiValueField list-type="double-listbox" does not work correctly in ajax enabled forms Key: COCOON-1822 URL: http://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Priority: Critical The multi value field with fi:styling list-type="double-listbox" relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : CFormsForm cocoon.forms.ajax = true; forms_onsubmit(); I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- 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] Commented: (COCOON-1819) No support for creation of Bookmarks from JavaFlow
[ http://issues.apache.org/jira/browse/COCOON-1819?page=comments#action_12373077 ] Simone Gianni commented on COCOON-1819: --- Harlan, did you tried the patches? which one worked for you? > No support for creation of Bookmarks from JavaFlow > -- > > Key: COCOON-1819 > URL: http://issues.apache.org/jira/browse/COCOON-1819 > Project: Cocoon > Type: Improvement > Components: Blocks: Java Flow > Reporter: Harlan Iverson > Attachments: javaflow-bookmarks-1.diff, javaflow-bookmarks-2.diff, > javaflow-bookmarks-sample.diff > > There is no JavaFlow equivalent of createWebContinuation. -- 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] Updated: (COCOON-1819) No support for creation of Bookmarks from JavaFlow
[ http://issues.apache.org/jira/browse/COCOON-1819?page=all ] Simone Gianni updated COCOON-1819: -- Attachment: javaflow-bookmarks-sample.diff A sample for bookmarks and continuation invalidation. Performs simple operations on an int, creating bookmarks and allowing the user to go back to those bookmarks. Displays a simple "log" sotred in session to make it clear to the user what's happening. Finally invalidates the continuation so that a second request will fail with invalid continuation exception. > No support for creation of Bookmarks from JavaFlow > -- > > Key: COCOON-1819 > URL: http://issues.apache.org/jira/browse/COCOON-1819 > Project: Cocoon > Type: Improvement > Components: Blocks: Java Flow > Reporter: Harlan Iverson > Attachments: javaflow-bookmarks-1.diff, javaflow-bookmarks-2.diff, > javaflow-bookmarks-sample.diff > > There is no JavaFlow equivalent of createWebContinuation. -- 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] Updated: (COCOON-1819) No support for creation of Bookmarks from JavaFlow
[ http://issues.apache.org/jira/browse/COCOON-1819?page=all ] Simone Gianni updated COCOON-1819: -- Attachment: javaflow-bookmarks-2.diff A mixed approach, a bit more tidy : - Continuation invalidation is done directly inside AbstractContinuable. - Bookmarks are generated as in the first version (java interpreter calls the continuation immediately), but: ... There is a new interface, so that Continuable is untouched. ... There's no need for introspection. ... AbstractContinuable implements this interface. It works correctly, and I'm afraid this is the only solution without touching the BCEL code inside the ContinuationClassLoader. > No support for creation of Bookmarks from JavaFlow > -- > > Key: COCOON-1819 > URL: http://issues.apache.org/jira/browse/COCOON-1819 > Project: Cocoon > Type: Improvement > Components: Blocks: Java Flow > Reporter: Harlan Iverson > Attachments: javaflow-bookmarks-1.diff, javaflow-bookmarks-2.diff > > There is no JavaFlow equivalent of createWebContinuation. -- 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] Commented: (COCOON-1819) No support for creation of Bookmarks from JavaFlow
[ http://issues.apache.org/jira/browse/COCOON-1819?page=comments#action_12372876 ] Simone Gianni commented on COCOON-1819: --- The first solution (doing everything from inside the Continuation system, not involving JavaInterpreter) is really hard to work out: - Continuation has a two step system based on isRestoring and isCapturing - The ContinuationClassLoader inserts some checks, and if isCapturing = true it captures the current execution stack. - Unfortunately it then inserts a return null. - This means that there seems to be no (easy) way of capturing the stack in the current continuation and then continue creating a new continuation. The only way of doing this seems to be adding another boolean, like isBookmarking, and have the generated bytecode check for this one before inserting a return null .. and I'm afraid this would only be the first step. The provided patch simply ignores all this problems, stops the current continuation in the normal way and then starts it again in the normal way. > No support for creation of Bookmarks from JavaFlow > -- > > Key: COCOON-1819 > URL: http://issues.apache.org/jira/browse/COCOON-1819 > Project: Cocoon > Type: Improvement > Components: Blocks: Java Flow > Reporter: Harlan Iverson > Attachments: javaflow-bookmarks-1.diff > > There is no JavaFlow equivalent of createWebContinuation. -- 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] Updated: (COCOON-1819) No support for creation of Bookmarks from JavaFlow
[ http://issues.apache.org/jira/browse/COCOON-1819?page=all ] Simone Gianni updated COCOON-1819: -- Attachment: javaflow-bookmarks-1.diff The first solution to javaflow bookmarks : - Continuable have two methods : getState() and resetState(). - JavaInterpeter, depending on the value of getState(), calls the next continuation directly or invalidated the current or parent continuation. - AbstractContinuable implements the two method of Continuable and also provide createWebContinuation() and disposeWebContinuation(). > No support for creation of Bookmarks from JavaFlow > -- > > Key: COCOON-1819 > URL: http://issues.apache.org/jira/browse/COCOON-1819 > Project: Cocoon > Type: Improvement > Components: Blocks: Java Flow > Reporter: Harlan Iverson > Attachments: javaflow-bookmarks-1.diff > > There is no JavaFlow equivalent of createWebContinuation. -- 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] Commented: (COCOON-1819) No support for creation of Bookmarks from JavaFlow
[ http://issues.apache.org/jira/browse/COCOON-1819?page=comments#action_12372872 ] Simone Gianni commented on COCOON-1819: --- This was not an easy task. I first started trying to emulate what flowscript does : - Add a method in AbstractContinuable - From there get the continuation - Create a new continuation - Set the new continuation as the current one - Modify the JavaInterpreter a bit to get the current continuation after invoking the method since it could be changed. But unfortunately it was not so easy, i ended up with a certain number of stack exception since the ContinuationClassLoader was rewriting that method too, and managing continuation from a method that has been rewritten to work with continuations was not correct. Afterall, making a bookmark is nothing more than calling the next continuation, so this is a good workaround : // I want a bookmark here sendPageAndWait(mycontinuationid + ".cont"); (Obviously this means that there is a *.conf going to the continuations, it's a hack but it's a workaround). But, after testing this was true, maybe the problem could be solved this way : - The method createWebContinuation in AbstractContinuable should set a flag. - The interpreter checks that flag - If the flag is set calls the handleContinuation on the new continuation directly. Again it's not so easy, since due to class loader issues it's not possible to call a AbstractContinuable.getFlag() from the JavaInterpeter (if not with reflection). So I unfortunately had to push these methods (actually getState and resetState) up to Continuable, which seems to be the the only join point between JavaInterpreter and AbstractContinuable. This, unfortunately, changed Continuable from a marker only interface to an interface with two methods, thus breaking code compatibility with other implementations of Continuable (BTW, AbstractContinuable is the only implementation in cocoon, and implementing it directly is quite an uncommon practice). BUT, it works. I also added the code to invalidate the continuation, which is quite handy to avoid "the infamous back button" and subseguent resubmissions. Other possible solutions would be : 1) Placing the code to create a new continuation somewhere else accessible from AbstractContinuable. 2) Keep this code but call the getState and resetState thru reflection, so that Continuable is not affected, but having an impact on performance and code readability. > No support for creation of Bookmarks from JavaFlow > -- > > Key: COCOON-1819 > URL: http://issues.apache.org/jira/browse/COCOON-1819 > Project: Cocoon > Type: Improvement > Components: Blocks: Java Flow > Reporter: Harlan Iverson > > There is no JavaFlow equivalent of createWebContinuation. -- 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] Updated: (COCOON-1655) JavaFlow/CForm/select-list crash
[ http://issues.apache.org/jira/browse/COCOON-1655?page=all ]
Simone Gianni updated COCOON-1655:
--
Attachment: javaflow-continuationstack.diff
Unfied diff of the given patch applied to latest Continuation.java.
Tested that it works correctly with samples (that means, at least samples keep
working) but not on the specified case of a flow calling another flow ..
anyway theorically it should work.
P.S. in doubt i marked the attachment as "not intended for inclusion", since
IANAL and dunno if the original author granted the licence for incusion.
> JavaFlow/CForm/select-list crash
>
>
> Key: COCOON-1655
> URL: http://issues.apache.org/jira/browse/COCOON-1655
> Project: Cocoon
> Type: Bug
> Components: Blocks: Java Flow
> Versions: 2.1.7
> Environment: Operating System: other
> Platform: Other
> Reporter: Benoit Deshaies
> Assignee: Cocoon Developers Team
> Attachments: javaflow-continuationstack.diff
>
> I get an error whenever I include an
> where
> both the form and the XYZ pipeline use JavaFlow. The error is:
> No continuation is running
> cause: java.lang.IllegalStateException: No continuation is running
> java.lang.IllegalStateException: No continuation is running
> at
> org.apache.cocoon.components.flow.java.Continuation.suspend(Continuation.java:79)
> at
> org.apache.cocoon.components.flow.java.AbstractContinuable.sendPageAndWait(AbstractContinuable.java:75)
> at
> org.apache.cocoon.forms.flow.java.FormInstance.show(FormInstance.java:181)
> The reason is that when cocoon:/XYZ runs, a continuation is created for the
> same
> thread as the form continuation. The continuationsmap in Continuation class
> gets
> overwritten. When cocoon:/XYZ returns, the map is cleared for the thread,
> leaving no continuation for the form.
> Here's a bit of code from the app to help explain.
> The form contains a selection list defined as:
>
>
>
>
> The sitemap contains:
>
>
>
> Then I have the following JavaFlow
> public void doGenerateUserList() throws Exception {
>Collection userList = databaseManager.getUserList();
>sendPage("user_list", new VarMap().add("list", userList) );
> }
--
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] Updated: (COCOON-1782) [PATCH] Support for CSS classes in cocoon forms XSL
[ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
Simone Gianni updated COCOON-1782:
--
Attachment: xsl-css-2.diff
Adjusted the patch to work with recent changes in XSLs.
Also fixed an annoying bug in IE : since Ie does not trigger an onchange event
when the user clicks on a radio button or on a checkbox, the onchange (and the
ajax update) will happen only when the user then clicks on something else
(simultaneous to the onblur event). So I've changed the XSL so that when a
radio button or a checkbox is used the onclick event is used instead of the
onchange. This could lead to a few more form submits than those strictly
needed, but will update the page at the right time and not wait for the user to
click away from a radio or checkbox.
> [PATCH] Support for CSS classes in cocoon forms XSL
> ---
>
> Key: COCOON-1782
> URL: http://issues.apache.org/jira/browse/COCOON-1782
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Reporter: Simone Gianni
> Attachments: xsl-css-2.diff, xsl-css-trunk.diff, xsl-css.diff
>
> Added CSS classes to key elements in default cocoon forms XSL. Here is a
> brief explanation of how it works :
> ---
> Common fields styling
> The general rule for common fields (styled by forms-field-styling.xsl) is to
> apply the following classes :
> - "forms" : is placed always, to avoid name clashes with already present
> site-specific classes.
> - : can be "field", "action", "output", "booleanfield",
> "multivaluefield", "upload", "repeater", "imagemap", "aggregatefield",
> "form", "messages".
> - : the state of the widget, can be empty, "active", "disbled",
> "output".
> - "required" : if the widget is required.
> - "with-errors" : if there are some fi:validation-messages associated with
> the widget.
> - : an optional, user defined, fi:styling/@class that can be
> specified on a field to fine tune widget styling.
> This technique makes it easy to write very specific CSS rules, as much as
> very general ones. For example :
> input.required {
> color: blue;
> }
> Will make all required inputs have a blue text color, while
> input.upload.required {
> color: red;
> }
> will make only the required upload widgets have a red text color.
> The HTML elements to which this classes will be applied varies depending on
> the widget type and special fi:styling attributes (like list-type for
> selection lists, fi:styling/@type etc..).
> There are also other classes, placed to correctly style other elements, these
> are :
> - "captcha" : applied to the img element of a captcha field.
> - "required-mark" : applied to the span containing the "*" near the required
> fields.
> - "validation-message" : applied to the anchor element containing the "!"
> near the fields with errors.
> - "vertical-list" and "horizontal-list" : applied to the tables used to
> layout these kind of lists.
> - "upload-change-button" : applied to the button that appears next to the
> upload widget when a file has been uploaded.
> For the validation-errors element (which outputs a list of all validation
> errors found in the form) there are other special classes :
> - "validation-errors" : applied to the div that contains the errors recap
> block.
> - "validation-errors-header" and "validation-errors-footer" : applied to the
> paragraphs that contains the header and footer of the errors recap.
> - "validation-errors-content" : applied to the "li" element of the errors
> list.
> Page styling
> Another set of classes is used for page styling (forms-page-styling.xsl). The
> general rule for fi:group is to apply the following classes :
> - "forms" : as always placed to mark a cocoon forms CSS class.
> - "group" : identify a group class
> - or : the fi:styling/@layout or fi:styling/@type of the
> fi:group
> - : an optional, user defined, fi:styling/@class that can be
> specified on a group to fine tune styling.
> As for the widgets, these classes are applied to different HTML elements
> depèending on the group type and layout.
> For those layouts which uses tables, special classes are used to mark
> specific cells :
> - "label" : applied to the "td" containing the label
> - "content" : applied to the "td" containing the form input
> - "action" : applied to the "td" containing an action widget, for those
> layouts that creates special cells for this widgets.
> - "booleanfield" : applied to the "td" containing a booleanfield widget, for
> those layouts that creates special cells for this widgets.
> - "other" : applied to the "td" containing other content, like another nested
> fi:group or non cocoon forms elements.
> Consider this CSS snippet :
> table.group.columns {
> border: 1px solid blue;
> }
> table.group.columns td {
> background: yellow;
> }
> table.group.columns td.label {
> bac
[jira] Updated: (COCOON-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=all ] Simone Gianni updated COCOON-1818: -- Attachment: sendmail-exceptions2.diff This patch applies the solution number 3 : for every call to the sendMail() method a result element is always generated. It will contain an error, an exception, or the common email sent results. This changes the produced XML in many ways : - The error element was not conained in a result before this patch. - The exception element was or was not contained in a result before this patch (and this caused the main problems) So consider that after applying you'll probably have to change the XSL that transforms the result. If a mail is not sent, it should not stop sending all the others, unless a SAXException is received (in that case the pipeline is probably broken, so there's nothing cocoon can do about it). Maybe you've seen it stopping because of the inconsistent XML, which caused a SAXException, which stops everything. P.S. this patch is not a delta from the previous one, so you should revert the file on which you applied the previous patch and the apply this one on the clean reverted file. > SendMailTransformer misses closing tag when recipient address is malformed > -- > > Key: COCOON-1818 > URL: http://issues.apache.org/jira/browse/COCOON-1818 > Project: Cocoon > Type: Bug > Components: Blocks: Mail > Reporter: Jasha Joachimsthal > Attachments: sendmail-exceptions.diff, sendmail-exceptions2.diff > > When a recipient address contains an illegal character (, ; [EMAIL > PROTECTED]@com etc), an exception is being thrown by method sendMail(List > newAddresses, Transport trans). > The execution of the try in method sendMail() is stopped which may have > created a tag. > No end tag is created when this occurs. -- 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] Commented: (COCOON-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=comments#action_12372447 ] Simone Gianni commented on COCOON-1818: --- Ok, I'll try .. > SendMailTransformer misses closing tag when recipient address is malformed > -- > > Key: COCOON-1818 > URL: http://issues.apache.org/jira/browse/COCOON-1818 > Project: Cocoon > Type: Bug > Components: Blocks: Mail > Reporter: Jasha Joachimsthal > Attachments: sendmail-exceptions.diff > > When a recipient address contains an illegal character (, ; [EMAIL > PROTECTED]@com etc), an exception is being thrown by method sendMail(List > newAddresses, Transport trans). > The execution of the try in method sendMail() is stopped which may have > created a tag. > No end tag is created when this occurs. -- 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] Commented: (COCOON-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=comments#action_12372442 ] Simone Gianni commented on COCOON-1818: --- IMMO, it's a good idea to report an exception indicating that a single email was not sent in the XML report. This is useful to report to the user which email was invialid, and more important since sending a bunch of emails is not transactional, it's not possible to rollback, and this if the entire batch sending is aborted with an exception when an email fails there would be no way to avoid sending some emails more than once. Jasha, you are completely right : if the exception happens before the result element is opened, with my patch it would be closed anyway, so there are three possible solutions : 1) Use a boolean to indicate that the result element was opened, and check this boolean before closing it in the finally. Pros are that it's simple to implement, cons are that the result XML will have sometimes have a result containing an exception, other times only the exception not wrapped inside a result. 2) Open the result element always after everything has been done, so that a result will always contain the result of a good email, while exceptions will always be reported outside the result element. 3) Open the result element always before everything is done, so that an exception will always be wrapped inside a result, wether it happens at the very early stage of email sending or at the last step of it. I think the number 3 is the best one. It should not be that hard to implement, just moving the start element up in the code as much as possible (if possible, at the first line of the sendMail method). Jasha, do you want to try? :) > SendMailTransformer misses closing tag when recipient address is malformed > -- > > Key: COCOON-1818 > URL: http://issues.apache.org/jira/browse/COCOON-1818 > Project: Cocoon > Type: Bug > Components: Blocks: Mail > Reporter: Jasha Joachimsthal > Attachments: sendmail-exceptions.diff > > When a recipient address contains an illegal character (, ; [EMAIL > PROTECTED]@com etc), an exception is being thrown by method sendMail(List > newAddresses, Transport trans). > The execution of the try in method sendMail() is stopped which may have > created a tag. > No end tag is created when this occurs. -- 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] Updated: (COCOON-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=all ] Simone Gianni updated COCOON-1818: -- Attachment: sendmail-exceptions.diff I'm not an expert about this block, but i made the following modifications : - The sendEndElementEventNS is now called inside a finally, this way the output is ... - A SAXException is now propagated up to when it happens in sendMail, since IMMO it makes no sense to intercept a SAXException and try to generate an exception report producing more SAX events. The only thing i'm not sure is the this.ignoreHookCount-- . But since it's SAX related i moved it to the finally as well as the sendEndElementEventNS. > SendMailTransformer misses closing tag when recipient address is malformed > -- > > Key: COCOON-1818 > URL: http://issues.apache.org/jira/browse/COCOON-1818 > Project: Cocoon > Type: Bug > Components: Blocks: Mail > Reporter: Jasha Joachimsthal > Attachments: sendmail-exceptions.diff > > When a recipient address contains an illegal character (, ; [EMAIL > PROTECTED]@com etc), an exception is being thrown by method sendMail(List > newAddresses, Transport trans). > The execution of the try in method sendMail() is stopped which may have > created a tag. > No end tag is created when this occurs. -- 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] Updated: (COCOON-1804) 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 updated COCOON-1804:
--
Attachment: javaflow-fomcocoon.diff
This patch solves the problem, also if not perfect I don't think it's so easy
to do much more.
What i've done is this :
- Created a new class FOM_SimpleCocoon
... It's a javascript host object
... Exposes request, response, session and context
... It does not (yet?) exposes log and parameters
... Does not have (obviously) the methods of the FOM_Cocoon object like
sendPage etc..
- In JavascriptHelper, when a function is called :
... If there is not already a scope created by flowscript, getRootScope is
called.
... I added the object model as a parameter of getRootScope.
... If an object model is specified, it's used to create a new instance of
FOM_SimpleCocoon
... This instance is placed in a new scope, with the name "cocoon"
... The javascript function is explicity applied to this new scope
This way, the difference between a javascript snippet in a definition, wether
using flowscript or javaflow, is smaller, since cocoon.request, cocoon.session,
cocoon.response and cocoon.context are now available, and I don't think much
more is needed. It would be nice to also have log and parameters, just to be
more compatible with the complete FOM_Cocoon, but since i don't think they can
be obtained from an ObjectModel, they should be added as new parameters in all
the JavascripHelper calls.
> Javascript FOM_SCOPE issue when using Java as the flow engine -
> ReferenceError: "cocoon" is not defined
> ---
>
> Key: COCOON-1804
> URL: http://issues.apache.org/jira/browse/COCOON-1804
> Project: Cocoon
> Type: Bug
> Components: Blocks: Java Flow
> Versions: 2.1.8
> Reporter: Andrew Madu
> Priority: Blocker
> Attachments: javaflow-fomcocoon.diff
>
> I have created a java flow class which does the following:
> //Load in validation file
> FormInstance form = new FormInstance("forms/login.xml");
> My login map (snippet) is as follows:
> Login.xml:
>
>
> var success = true;
> var newUserReg = new Packages.test.User();
> var username = widget.lookupWidget("username");
> var password = widget.lookupWidget("password");
>
> try {
>
> var checkUserTest = newUserReg.getUser(username.value,
> password.value);
>
> if (checkUserTest != null) {
> cocoon.session.setAttribute("user", checkUserTest);
> success = true;
> }else{
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("The password,
> username combination does not exist. Please enter another one.", false));
> success = false;
> }
> } catch (e) {
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("e.", false));
> success = false;
> }
> return success;
>
>
> I am getting an error message when the line
> 'cocoon.session.setAttribute("user", checkUserTest)' is hit.:
> ReferenceError: "cocoon" is not defined
> What is the issue here, can I create a session object from within form
> validation/javascript in another way?
> Andrew
--
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] Commented: (COCOON-1804) 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=comments#action_12371979
]
Simone Gianni commented on COCOON-1804:
---
I'm trying to solve this issue. The way I'm acting is the following :
- Implementing a lightweight FOM_SimpleCocoon as a javascript host object
giving access to session, request etc..
- Passing the object model if present in JavascriptHelper.getRootScope (called
if a script flow scope is not present)
- If there is an object model instantiate the FOM_SimpleCocoon object in a new
scope and use that.
Everything is done, but i keep receiving a
org.mozilla.javascript.PropertyException:
Constructor for "FOM_SimpleCocoon" not found.
I tried everything, from not declaring a costructor at all, declaring
expliticly an empty constructor, declaring a costructor with a parameter and
passing that parameter in the ctx.newObject method, declaring a jsConstructor
method, but still can't understand where the problem is.
Does anyone have an idea? I followed this tutorial
http://www.mozilla.org/rhino/tutorial.html#AddingCounter step by step but it
keeps on giving the exception.
Please help!
> Javascript FOM_SCOPE issue when using Java as the flow engine -
> ReferenceError: "cocoon" is not defined
> ---
>
> Key: COCOON-1804
> URL: http://issues.apache.org/jira/browse/COCOON-1804
> Project: Cocoon
> Type: Bug
> Components: Blocks: Java Flow
> Versions: 2.1.8
> Reporter: Andrew Madu
> Priority: Blocker
>
> I have created a java flow class which does the following:
> //Load in validation file
> FormInstance form = new FormInstance("forms/login.xml");
> My login map (snippet) is as follows:
> Login.xml:
>
>
> var success = true;
> var newUserReg = new Packages.test.User();
> var username = widget.lookupWidget("username");
> var password = widget.lookupWidget("password");
>
> try {
>
> var checkUserTest = newUserReg.getUser(username.value,
> password.value);
>
> if (checkUserTest != null) {
> cocoon.session.setAttribute("user", checkUserTest);
> success = true;
> }else{
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("The password,
> username combination does not exist. Please enter another one.", false));
> success = false;
> }
> } catch (e) {
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("e.", false));
> success = false;
> }
> return success;
>
>
> I am getting an error message when the line
> 'cocoon.session.setAttribute("user", checkUserTest)' is hit.:
> ReferenceError: "cocoon" is not defined
> What is the issue here, can I create a session object from within form
> validation/javascript in another way?
> Andrew
--
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] Updated: (COCOON-1812) Javaflow and Ajax when sending two forms one after eachother
[ http://issues.apache.org/jira/browse/COCOON-1812?page=all ]
Simone Gianni updated COCOON-1812:
--
Attachment: javaflow-ajax.diff
Patch for javaflow ajax continue
> Javaflow and Ajax when sending two forms one after eachother
>
>
> Key: COCOON-1812
> URL: http://issues.apache.org/jira/browse/COCOON-1812
> Project: Cocoon
> Type: Bug
> Components: Blocks: Forms, Blocks: Java Flow
> Versions: 2.1.9-dev (current SVN)
> Reporter: Simone Gianni
> Priority: Critical
> Attachments: javaflow-ajax.diff
>
> In javaflow, if I try to send an ajax form and then send another ajax form I
> obtain a NPE originating from JXMacroHelper.
> For example :
> FormInstance fi = new FormInstance("myform.def.xml");
> fi.show("mypipe");
> fi = new FormInstance("myotherform.def.xml");
> fi.show("myotherpipe");
> I receive an NPE originating from JXMacroHelper:162 while showing the second
> forms.
> After investigations i noticed that the second form was displayed following
> the ajax behaviour, while this second form is new and should not be "ajaxed".
> This causes the updatedWidgets list to be null (both in form and in
> JXMacroHelper) and thus the NPE.
> Sniffing the http traffic showed me that while in javascript the submission
> of the first form causes a and a new non-ajax request from the
> browser, while with javaflow this does not happen.
> Seems like the lines from 176 to 201 of
> /cocoon-2.1.X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/Form.js
> were not ported to the javaflow FormInstance.
--
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] Commented: (COCOON-1812) Javaflow and Ajax when sending two forms one after eachother
[
http://issues.apache.org/jira/browse/COCOON-1812?page=comments#action_12371926
]
Simone Gianni commented on COCOON-1812:
---
Fixed this, now it works this way :
- The form is sent
- Once the form is complete and correct, a bu:continue is sent
... Please note that i ported the js code, but had to use redirector.setStatus
to avoid CallFunctionNode exception
- The continuation is suspended, and will never regain control.
- The client calls the next continuation, sending a cocoon-ajax-continue=true
- This reenters the show method, so it first checks if cocoon-ajax-continue is
present and in that case simply exits the loop.
> Javaflow and Ajax when sending two forms one after eachother
>
>
> Key: COCOON-1812
> URL: http://issues.apache.org/jira/browse/COCOON-1812
> Project: Cocoon
> Type: Bug
> Components: Blocks: Forms, Blocks: Java Flow
> Versions: 2.1.9-dev (current SVN)
> Reporter: Simone Gianni
> Priority: Critical
>
> In javaflow, if I try to send an ajax form and then send another ajax form I
> obtain a NPE originating from JXMacroHelper.
> For example :
> FormInstance fi = new FormInstance("myform.def.xml");
> fi.show("mypipe");
> fi = new FormInstance("myotherform.def.xml");
> fi.show("myotherpipe");
> I receive an NPE originating from JXMacroHelper:162 while showing the second
> forms.
> After investigations i noticed that the second form was displayed following
> the ajax behaviour, while this second form is new and should not be "ajaxed".
> This causes the updatedWidgets list to be null (both in form and in
> JXMacroHelper) and thus the NPE.
> Sniffing the http traffic showed me that while in javascript the submission
> of the first form causes a and a new non-ajax request from the
> browser, while with javaflow this does not happen.
> Seems like the lines from 176 to 201 of
> /cocoon-2.1.X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/Form.js
> were not ported to the javaflow FormInstance.
--
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] Commented: (COCOON-1804) 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=comments#action_12371909
]
Simone Gianni commented on COCOON-1804:
---
here is the java class :
src/blocks/forms/java/org/apache/cocoon/forms/samples/CustomBirthDateValidator.java
here is the form model : src/blocks/forms/samples/forms/form2_model.xml
> Javascript FOM_SCOPE issue when using Java as the flow engine -
> ReferenceError: "cocoon" is not defined
> ---
>
> Key: COCOON-1804
> URL: http://issues.apache.org/jira/browse/COCOON-1804
> Project: Cocoon
> Type: Bug
> Components: Blocks: Java Flow
> Versions: 2.1.8
> Reporter: Andrew Madu
> Priority: Blocker
>
> I have created a java flow class which does the following:
> //Load in validation file
> FormInstance form = new FormInstance("forms/login.xml");
> My login map (snippet) is as follows:
> Login.xml:
>
>
> var success = true;
> var newUserReg = new Packages.test.User();
> var username = widget.lookupWidget("username");
> var password = widget.lookupWidget("password");
>
> try {
>
> var checkUserTest = newUserReg.getUser(username.value,
> password.value);
>
> if (checkUserTest != null) {
> cocoon.session.setAttribute("user", checkUserTest);
> success = true;
> }else{
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("The password,
> username combination does not exist. Please enter another one.", false));
> success = false;
> }
> } catch (e) {
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("e.", false));
> success = false;
> }
> return success;
>
>
> I am getting an error message when the line
> 'cocoon.session.setAttribute("user", checkUserTest)' is hit.:
> ReferenceError: "cocoon" is not defined
> What is the issue here, can I create a session object from within form
> validation/javascript in another way?
> Andrew
--
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] Commented: (COCOON-1812) Javaflow and Ajax when sending two forms one after eachother
[
http://issues.apache.org/jira/browse/COCOON-1812?page=comments#action_12371778
]
Simone Gianni commented on COCOON-1812:
---
I can try to port them, but after writing in the response the javascript flow
terminates and waits for the new http request to arrive. How do i do this in
javaflow? Continuation.suspend() (creating a continuation that will wait for
nothing)?
The other way would be to throw an exception, but while this exception would go
unnoticed under tomcat and jetty, it will appear under BEA, WebSphere and other
containers.
I'll try suspending the continuation.
> Javaflow and Ajax when sending two forms one after eachother
>
>
> Key: COCOON-1812
> URL: http://issues.apache.org/jira/browse/COCOON-1812
> Project: Cocoon
> Type: Bug
> Components: Blocks: Forms, Blocks: Java Flow
> Versions: 2.1.9-dev (current SVN)
> Reporter: Simone Gianni
> Priority: Critical
>
> In javaflow, if I try to send an ajax form and then send another ajax form I
> obtain a NPE originating from JXMacroHelper.
> For example :
> FormInstance fi = new FormInstance("myform.def.xml");
> fi.show("mypipe");
> fi = new FormInstance("myotherform.def.xml");
> fi.show("myotherpipe");
> I receive an NPE originating from JXMacroHelper:162 while showing the second
> forms.
> After investigations i noticed that the second form was displayed following
> the ajax behaviour, while this second form is new and should not be "ajaxed".
> This causes the updatedWidgets list to be null (both in form and in
> JXMacroHelper) and thus the NPE.
> Sniffing the http traffic showed me that while in javascript the submission
> of the first form causes a and a new non-ajax request from the
> browser, while with javaflow this does not happen.
> Seems like the lines from 176 to 201 of
> /cocoon-2.1.X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/Form.js
> were not ported to the javaflow FormInstance.
--
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] Created: (COCOON-1812) Javaflow and Ajax when sending two forms one after eachother
Javaflow and Ajax when sending two forms one after eachother
Key: COCOON-1812
URL: http://issues.apache.org/jira/browse/COCOON-1812
Project: Cocoon
Type: Bug
Components: Blocks: Forms, Blocks: Java Flow
Versions: 2.1.9-dev (current SVN)
Reporter: Simone Gianni
Priority: Critical
In javaflow, if I try to send an ajax form and then send another ajax form I
obtain a NPE originating from JXMacroHelper.
For example :
FormInstance fi = new FormInstance("myform.def.xml");
fi.show("mypipe");
fi = new FormInstance("myotherform.def.xml");
fi.show("myotherpipe");
I receive an NPE originating from JXMacroHelper:162 while showing the second
forms.
After investigations i noticed that the second form was displayed following the
ajax behaviour, while this second form is new and should not be "ajaxed". This
causes the updatedWidgets list to be null (both in form and in JXMacroHelper)
and thus the NPE.
Sniffing the http traffic showed me that while in javascript the submission of
the first form causes a and a new non-ajax request from the
browser, while with javaflow this does not happen.
Seems like the lines from 176 to 201 of
/cocoon-2.1.X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/Form.js
were not ported to the javaflow FormInstance.
--
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] Commented: (COCOON-1806) [PATCH] Java class custom validator builder
[ http://issues.apache.org/jira/browse/COCOON-1806?page=comments#action_12371721 ] Simone Gianni commented on COCOON-1806: --- SVN repository path : http://svn.apache.org/repos/asf/cocoon Online html repository browsing : http://svn.apache.org/viewcvs.cgi/cocoon/branches/ Nightly generated downloadable 2.1.X svn snapshots : http://svn.apache.org/snapshots/cocoon-BRANCH_2_1_X > [PATCH] Java class custom validator builder > --- > > Key: COCOON-1806 > URL: http://issues.apache.org/jira/browse/COCOON-1806 > Project: Cocoon > Type: New Feature > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, > javavalidator.diff, javavalidator2.diff > > Implemented a custom java validator builder, very similar to the custom java > listener builder. Also implemented a sample birthday validator and added it > to form2 sample. -- 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] Commented: (COCOON-1806) [PATCH] Java class custom validator builder
[ http://issues.apache.org/jira/browse/COCOON-1806?page=comments#action_12371668 ] Simone Gianni commented on COCOON-1806: --- Andew, i'm a linux user so have no idea how it goes under windows. You can also apply the patch from eclipse, in the team synchronization perspective, or right click on the cocoon 2.1.8 source, then click team, then apply patch. Not sure, but i think this is a pure java patch system, so should work correctly even under windows. Since this patch has been committed, another option could be to check out only files modified by this patch from the cocoon 2.1.X branch using your favorite SVN client. Modified files are : src/blocks/forms/java/org/apache/cocoon/forms/validation/impl/JavaClassValidatorBuilder.java src/blocks/forms/conf/forms-validators.xconf And if you also want the samples : src/blocks/forms/java/org/apache/cocoon/forms/samples/CustomBirthDateValidator.java src/blocks/forms/samples/forms/form2_model.xml > [PATCH] Java class custom validator builder > --- > > Key: COCOON-1806 > URL: http://issues.apache.org/jira/browse/COCOON-1806 > Project: Cocoon > Type: New Feature > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, > javavalidator.diff, javavalidator2.diff > > Implemented a custom java validator builder, very similar to the custom java > listener builder. Also implemented a sample birthday validator and added it > to form2 sample. -- 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] Commented: (COCOON-1806) [PATCH] Java class custom validator builder
[ http://issues.apache.org/jira/browse/COCOON-1806?page=comments#action_12371564 ] Simone Gianni commented on COCOON-1806: --- Oh, I still have some problems undestanding what is shared between 2.1.X and 2.2 :) > [PATCH] Java class custom validator builder > --- > > Key: COCOON-1806 > URL: http://issues.apache.org/jira/browse/COCOON-1806 > Project: Cocoon > Type: New Feature > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, > javavalidator.diff, javavalidator2.diff > > Implemented a custom java validator builder, very similar to the custom java > listener builder. Also implemented a sample birthday validator and added it > to form2 sample. -- 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] Updated: (COCOON-1782) [PATCH] Support for CSS classes in cocoon forms XSL
[ http://issues.apache.org/jira/browse/COCOON-1782?page=all ]
Simone Gianni updated COCOON-1782:
--
Attachment: xsl-css-trunk.diff
Same patch to be applied to trunk.
> [PATCH] Support for CSS classes in cocoon forms XSL
> ---
>
> Key: COCOON-1782
> URL: http://issues.apache.org/jira/browse/COCOON-1782
> Project: Cocoon
> Type: Improvement
> Components: Blocks: Forms
> Reporter: Simone Gianni
> Attachments: xsl-css-trunk.diff, xsl-css.diff
>
> Added CSS classes to key elements in default cocoon forms XSL. Here is a
> brief explanation of how it works :
> ---
> Common fields styling
> The general rule for common fields (styled by forms-field-styling.xsl) is to
> apply the following classes :
> - "forms" : is placed always, to avoid name clashes with already present
> site-specific classes.
> - : can be "field", "action", "output", "booleanfield",
> "multivaluefield", "upload", "repeater", "imagemap", "aggregatefield",
> "form", "messages".
> - : the state of the widget, can be empty, "active", "disbled",
> "output".
> - "required" : if the widget is required.
> - "with-errors" : if there are some fi:validation-messages associated with
> the widget.
> - : an optional, user defined, fi:styling/@class that can be
> specified on a field to fine tune widget styling.
> This technique makes it easy to write very specific CSS rules, as much as
> very general ones. For example :
> input.required {
> color: blue;
> }
> Will make all required inputs have a blue text color, while
> input.upload.required {
> color: red;
> }
> will make only the required upload widgets have a red text color.
> The HTML elements to which this classes will be applied varies depending on
> the widget type and special fi:styling attributes (like list-type for
> selection lists, fi:styling/@type etc..).
> There are also other classes, placed to correctly style other elements, these
> are :
> - "captcha" : applied to the img element of a captcha field.
> - "required-mark" : applied to the span containing the "*" near the required
> fields.
> - "validation-message" : applied to the anchor element containing the "!"
> near the fields with errors.
> - "vertical-list" and "horizontal-list" : applied to the tables used to
> layout these kind of lists.
> - "upload-change-button" : applied to the button that appears next to the
> upload widget when a file has been uploaded.
> For the validation-errors element (which outputs a list of all validation
> errors found in the form) there are other special classes :
> - "validation-errors" : applied to the div that contains the errors recap
> block.
> - "validation-errors-header" and "validation-errors-footer" : applied to the
> paragraphs that contains the header and footer of the errors recap.
> - "validation-errors-content" : applied to the "li" element of the errors
> list.
> Page styling
> Another set of classes is used for page styling (forms-page-styling.xsl). The
> general rule for fi:group is to apply the following classes :
> - "forms" : as always placed to mark a cocoon forms CSS class.
> - "group" : identify a group class
> - or : the fi:styling/@layout or fi:styling/@type of the
> fi:group
> - : an optional, user defined, fi:styling/@class that can be
> specified on a group to fine tune styling.
> As for the widgets, these classes are applied to different HTML elements
> depèending on the group type and layout.
> For those layouts which uses tables, special classes are used to mark
> specific cells :
> - "label" : applied to the "td" containing the label
> - "content" : applied to the "td" containing the form input
> - "action" : applied to the "td" containing an action widget, for those
> layouts that creates special cells for this widgets.
> - "booleanfield" : applied to the "td" containing a booleanfield widget, for
> those layouts that creates special cells for this widgets.
> - "other" : applied to the "td" containing other content, like another nested
> fi:group or non cocoon forms elements.
> Consider this CSS snippet :
> table.group.columns {
> border: 1px solid blue;
> }
> table.group.columns td {
> background: yellow;
> }
> table.group.columns td.label {
> background: blue;
> color: white;
> width: 20%;
> }
> This will style every fi:group with layout "columns" placing a blue border on
> the table, then using a yello background for every cell in the table, while a
> blue blackground, a while text color and a width of 20% will be used for
> cells containing labels.
> A special case of layout is handled directly in the basic xsl
> (forms-field-styling.xsl), which format with a "columns" similar layout a
> "fi:form". In this case the same classes (label, content etc..) applies.
> Some special classes are used for the tab layout. These are :
> - "ta
[jira] Updated: (COCOON-1806) [PATCH] Java class custom validator builder
[ http://issues.apache.org/jira/browse/COCOON-1806?page=all ] Simone Gianni updated COCOON-1806: -- Attachment: javavalidator-trunk.diff Same patch but to be applied to cocoon trunk. > [PATCH] Java class custom validator builder > --- > > Key: COCOON-1806 > URL: http://issues.apache.org/jira/browse/COCOON-1806 > Project: Cocoon > Type: New Feature > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, > javavalidator.diff, javavalidator2.diff > > Implemented a custom java validator builder, very similar to the custom java > listener builder. Also implemented a sample birthday validator and added it > to form2 sample. -- 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] Updated: (COCOON-1806) [PATCH] Java class custom validator builder
[ http://issues.apache.org/jira/browse/COCOON-1806?page=all ] Simone Gianni updated COCOON-1806: -- Attachment: javavalidator2.diff Added logger and context to both java validator builder and sample validator. > [PATCH] Java class custom validator builder > --- > > Key: COCOON-1806 > URL: http://issues.apache.org/jira/browse/COCOON-1806 > Project: Cocoon > Type: New Feature > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > Attachments: javavalidator-conf.diff, javavalidator.diff, javavalidator2.diff > > Implemented a custom java validator builder, very similar to the custom java > listener builder. Also implemented a sample birthday validator and added it > to form2 sample. -- 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] Commented: (COCOON-1804) 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=comments#action_12371418
]
Simone Gianni commented on COCOON-1804:
---
Implemented a custom java validator. See COCOON-1806. It should be possible to
apply this patch also to older versions of cocoon since it's mainly file
additions.
Anyway, the problem of accessing the request, session or other objectmodel
objects from inside these classes is unresolved.
IMMO, this is a cocoon flow : the fact that a user decides to use another flow
interpreter should not modify the behaviour of a definition javascript snippet.
There are two possible solutions :
- Either we decide that a definition snippet shouldn't access the cocoon
object, since that's commonly used for "control", and definition is not the
right place for control. So the javascript scope in which the definition
snippets are executed should not be the same of the flowscript interpreter but
a new one, without the FOM objects inside.
- Or the behaviour must be the same, so the o.a.c.forms.utils.JavaScriptHelper,
if does not find an already prepared "FOM-enabled" javascript context creates a
new one, so that also with javaflow you have the same objects inside a
javascript snippet. It should not be that difficult, I think it's just a matter
of exporting relevant methods of the flowscript interpreter (expecially
createSessionScope) in another utility class, and partially export the
setupContext method in this same utility class.
> Javascript FOM_SCOPE issue when using Java as the flow engine -
> ReferenceError: "cocoon" is not defined
> ---
>
> Key: COCOON-1804
> URL: http://issues.apache.org/jira/browse/COCOON-1804
> Project: Cocoon
> Type: Bug
> Components: Blocks: Java Flow
> Versions: 2.1.8
> Reporter: Andrew Madu
> Priority: Blocker
>
> I have created a java flow class which does the following:
> //Load in validation file
> FormInstance form = new FormInstance("forms/login.xml");
> My login map (snippet) is as follows:
> Login.xml:
>
>
> var success = true;
> var newUserReg = new Packages.test.User();
> var username = widget.lookupWidget("username");
> var password = widget.lookupWidget("password");
>
> try {
>
> var checkUserTest = newUserReg.getUser(username.value,
> password.value);
>
> if (checkUserTest != null) {
> cocoon.session.setAttribute("user", checkUserTest);
> success = true;
> }else{
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("The password,
> username combination does not exist. Please enter another one.", false));
> success = false;
> }
> } catch (e) {
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("e.", false));
> success = false;
> }
> return success;
>
>
> I am getting an error message when the line
> 'cocoon.session.setAttribute("user", checkUserTest)' is hit.:
> ReferenceError: "cocoon" is not defined
> What is the issue here, can I create a session object from within form
> validation/javascript in another way?
> Andrew
--
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] Updated: (COCOON-1806) [PATCH] Java class custom validator builder
[ http://issues.apache.org/jira/browse/COCOON-1806?page=all ] Simone Gianni updated COCOON-1806: -- Attachment: javavalidator-conf.diff Forgot to include a patch for configuration. > [PATCH] Java class custom validator builder > --- > > Key: COCOON-1806 > URL: http://issues.apache.org/jira/browse/COCOON-1806 > Project: Cocoon > Type: New Feature > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > Attachments: javavalidator-conf.diff, javavalidator.diff > > Implemented a custom java validator builder, very similar to the custom java > listener builder. Also implemented a sample birthday validator and added it > to form2 sample. -- 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] Created: (COCOON-1806) [PATCH] Java class custom validator builder
[PATCH] Java class custom validator builder --- Key: COCOON-1806 URL: http://issues.apache.org/jira/browse/COCOON-1806 Project: Cocoon Type: New Feature Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Attachments: javavalidator.diff Implemented a custom java validator builder, very similar to the custom java listener builder. Also implemented a sample birthday validator and added it to form2 sample. -- 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] Commented: (COCOON-1804) 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=comments#action_12371298
]
Simone Gianni commented on COCOON-1804:
---
Andrew, a validator is simply a java class, so you can create your own
validators writing a java class implementing
o.a.c.forms.validation.WidgetValidator . Once you have the class, you have to
write also another class implementing WidgetValidatorBuilder which acts as a
factory creating instances of your validator class, and register this builder
in cocoon.xconf so that cocoon forms can load, configure and use it thru the
avalon framework.
But Reinhard, AFAIK this does not solve (at least not directly) the problem of
accessing the session from inside this validator, if not with some
context/objectmodel static classes.
Could you tell us how to retrieve the current session (request, object model..
) from inside a java widget validator (so, eventually, translating it to
javascript it could be usable also inside the javascript validator)?
> Javascript FOM_SCOPE issue when using Java as the flow engine -
> ReferenceError: "cocoon" is not defined
> ---
>
> Key: COCOON-1804
> URL: http://issues.apache.org/jira/browse/COCOON-1804
> Project: Cocoon
> Type: Bug
> Components: Blocks: Java Flow
> Versions: 2.1.8
> Reporter: Andrew Madu
> Priority: Blocker
>
> I have created a java flow class which does the following:
> //Load in validation file
> FormInstance form = new FormInstance("forms/login.xml");
> My login map (snippet) is as follows:
> Login.xml:
>
>
> var success = true;
> var newUserReg = new Packages.test.User();
> var username = widget.lookupWidget("username");
> var password = widget.lookupWidget("password");
>
> try {
>
> var checkUserTest = newUserReg.getUser(username.value,
> password.value);
>
> if (checkUserTest != null) {
> cocoon.session.setAttribute("user", checkUserTest);
> success = true;
> }else{
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("The password,
> username combination does not exist. Please enter another one.", false));
> success = false;
> }
> } catch (e) {
> username.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
> password.setValidationError(new
> Packages.org.apache.cocoon.forms.validation.ValidationError("e.", false));
> success = false;
> }
> return success;
>
>
> I am getting an error message when the line
> 'cocoon.session.setAttribute("user", checkUserTest)' is hit.:
> ReferenceError: "cocoon" is not defined
> What is the issue here, can I create a session object from within form
> validation/javascript in another way?
> Andrew
--
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] Created: (COCOON-1801) [PATCH] Repeater events
[PATCH] Repeater events --- Key: COCOON-1801 URL: http://issues.apache.org/jira/browse/COCOON-1801 Project: Cocoon Type: New Feature Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Attachments: repeaterlistener-sample.diff, repeaterlistener.diff Since I felt the need and there are many comments in the code about it, i've implemented a RepeaterListener. The listener is triggered on row addition, deletion, reordering and clear. The event also brings informations about the row index and the actual action that took place. I've adapted the javascript listener to support this new listener, and in the meanwhile also noticed that lines 59 to 70 of it are useless, since i believe that code has been moved inside the JavaScriptHelper methods and those lines were left there. I've added a sample in form1, in the contact repeater. It's better to use the flow version of the sample, since in the no-flow sample the repeater is always recreated, an all events are broadcasted again. The usage is simply : ... I took care to call the event after the row has been initalized and to provide two events (deleting and deleted) for row deletion, so that accessing the new or "about to be deleted" row inside the listener should not be a problem. The forms1.xml listener has an example on how to do this. The only place where i'm not sure this will always work correctly is inside the initialize method, maybe the event broadcast should be moved to somewhere else, or at least after the super.initialize() call, just to make sure that when the listener gets the event everything is properly set up. Please note that the patch includes modifications on the javascript listener (o.a.c.forms.events.impl.JavaScript*) which i already modified in COCOON-1781. Regarding this file this patch will conflict with the other one (since both contains the same modifications) and in part superseedes the other one (due to the lines i've removed). So please apply the COCOON-1781 first, then this one, and if having problems applying this one revert the o.a.c.forms.event.impl.JavaScript* classes and then retry. -- 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] Commented: (COCOON-1207) EnumSelectionListTestCase fails on IBM 1.4.1_02 JDK
[ http://issues.apache.org/jira/browse/COCOON-1207?page=comments#action_12370879 ] Simone Gianni commented on COCOON-1207: --- Yep, IBM jdk/jre has a problem with enums pattern, but there is no possible direct solution. See COCOON-1793 for a possible solution. > EnumSelectionListTestCase fails on IBM 1.4.1_02 JDK > --- > > Key: COCOON-1207 > URL: http://issues.apache.org/jira/browse/COCOON-1207 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8 > Environment: Operating System: other > Platform: Other > Reporter: Jörg Heinicke > Assignee: Cocoon Developers Team > > reported by Emanuel Pordes at > http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108938061328269&w=4 -- 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] Commented: (COCOON-1790) VerifyException "Attempt to split long or double on the stack" in javaflow
[ http://issues.apache.org/jira/browse/COCOON-1790?page=comments#action_12370191 ] Simone Gianni commented on COCOON-1790: --- Trying to understand what happens here (read: studying BCEL and BRAKES) i noticed that all "new" instructions are removed (in the rewrite method). I suppose they are moved somewhere somehow, and maybe that's the point where a check on the argument size is probabily missing, but i can't find where this happens. > VerifyException "Attempt to split long or double on the stack" in javaflow > -- > > Key: COCOON-1790 > URL: http://issues.apache.org/jira/browse/COCOON-1790 > Project: Cocoon > Type: Bug > Components: Blocks: Java Flow > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > > When writing code like this : > long time = System.currentTimeMillis(); > Date date = new Date(time); > the given exception is thrown. It's a validation exception. This happens > when a long (maybe also a double?) is used in a constructor (not in a > function call). The following code is a workaround : > Date date = new Date(); > date.setTime(time); > but can be used only when the object we are instantiating have a getter as an > alternative to the constructor parameter. > I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X > branch. Don't know yet if this apply to other versions of cocoon. I'm using > Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. > Googling around it seems that this exception is raised when the data type in > a pop2 JVM instruction is not correct. I think this is one of the > side-effects of the javaflow BCEL manipulations, but I'm not skilled enought > on BCEL and similar stuff to even think of a possible solution. > The exception is raised loading the javaflow class, so it will prevent the > entire flow (and not only the affected method) to be used. Also, the > exception will just tell you that the class is invalid, and not point you to > the place in code where this long is used in a constructor, so you'll have to > spot it by hand. > I can produce a test case to try to narrow it down, but the given 3 lines of > code are enought to produce the error in my javaflows. -- 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] Commented: (COCOON-1790) VerifyException "Attempt to split long or double on the stack" in javaflow
[ http://issues.apache.org/jira/browse/COCOON-1790?page=comments#action_12369876 ] Simone Gianni commented on COCOON-1790: --- Yes, just tested with sun jdk under windows XP and got the same result. > VerifyException "Attempt to split long or double on the stack" in javaflow > -- > > Key: COCOON-1790 > URL: http://issues.apache.org/jira/browse/COCOON-1790 > Project: Cocoon > Type: Bug > Components: Blocks: Java Flow > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > > When writing code like this : > long time = System.currentTimeMillis(); > Date date = new Date(time); > the given exception is thrown. It's a validation exception. This happens > when a long (maybe also a double?) is used in a constructor (not in a > function call). The following code is a workaround : > Date date = new Date(); > date.setTime(time); > but can be used only when the object we are instantiating have a getter as an > alternative to the constructor parameter. > I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X > branch. Don't know yet if this apply to other versions of cocoon. I'm using > Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. > Googling around it seems that this exception is raised when the data type in > a pop2 JVM instruction is not correct. I think this is one of the > side-effects of the javaflow BCEL manipulations, but I'm not skilled enought > on BCEL and similar stuff to even think of a possible solution. > The exception is raised loading the javaflow class, so it will prevent the > entire flow (and not only the affected method) to be used. Also, the > exception will just tell you that the class is invalid, and not point you to > the place in code where this long is used in a constructor, so you'll have to > spot it by hand. > I can produce a test case to try to narrow it down, but the given 3 lines of > code are enought to produce the error in my javaflows. -- 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] Created: (COCOON-1799) [PATCH] Threads waste when reading a not found resource.
[PATCH] Threads waste when reading a not found resource.
Key: COCOON-1799
URL: http://issues.apache.org/jira/browse/COCOON-1799
Project: Cocoon
Type: Bug
Components: * Cocoon Core
Versions: 2.1.9-dev (current SVN)
Reporter: Simone Gianni
Priority: Blocker
Attachments: pipeline.diff
When setting up a pipeline with a reader on a not found file, the first time a
404 is reported, but following requests will hang up and the thread will never
get released, causing a potential complete lock exausting threads.
In the AbstractCachingProcessingPipeline class, in ProcessReader method, the
following happens :
- 774: a pcKey is created for caching content
- 853: the method eventually waits if another thread is generating
- 869: the method acquires a lock, to avoid other threads to generate twice
- 886: if there is no need cache validity pcKey is setted to null
- 918: if an exception occurrs while generating, the following code is in a
finally :
if (pcKey != null) {
releaseLock(pcKey);
}
This obviously brings to the following situation :
- A non existing resource is being generated
- A lock is acquired
- The FileSource returns null if the file does not exist.
- So pcKey is setted to null.
- An exception is thrown, since the file is not found.
- The finally block does not release the lock
- Next requests on the same file will hang waiting on the lock, but the other
thread will never release it.
This can easily consume all threads, it's quite easy to have this kind of
errors on a missing gif, or css, or favicon.ico or something else.
I modified this class so that it :
- Does not set pckey to null when readerValidity == null
- Checks for pckey != null && readerValidity != null on line 907 so that
content is not cached if readerValidity == null
- Since pckey is != null the lock is released.
I tested it and seems to work correctly, but this is core stuff, please double
check it!!
--
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] Updated: (COCOON-1793) [PATCH] Enum selection list with apache enum support and null-text
[ http://issues.apache.org/jira/browse/COCOON-1793?page=all ] Simone Gianni updated COCOON-1793: -- Attachment: enumselectionlist-samples2.diff Yeah, right, forgot svn add :) this is the patch for it. > [PATCH] Enum selection list with apache enum support and null-text > -- > > Key: COCOON-1793 > URL: http://issues.apache.org/jira/browse/COCOON-1793 > Project: Cocoon > Type: Improvement > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > Assignee: Ugo Cei > Attachments: enumselectionlist-samples.diff, > enumselectionlist-samples2.diff, enumselectionlist.diff > > Added support for apache enum in the EnumSelectionList. This will grant > selection list items order on those JREs (expecially IBM, used by WebSphere) > that will honor litteraly the Class.getDeclaredFields() javadocs and return > elements in random order. This also adds the ability to implement the > getEnumList method in the enum classes and implement a custom order. In case > it isn't possible to retrieve a valid iterator for the apache enum, then the > common way will be used. > Since i felt the lack of it, i also added a null-text="i18nkey" so that it's > now possible to specify a label for the null element when the selection list > is nullable="true". > The second patch updates the samples adding a PreferredContact apache enum to > the Contact bean, the form2 files (both for bean and xml binding) and > messages, to demostrate the usage of both apache enum and the new null-text. -- 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] Created: (COCOON-1793) [PATCH] Enum selection list with apache enum support and null-text
[PATCH] Enum selection list with apache enum support and null-text -- Key: COCOON-1793 URL: http://issues.apache.org/jira/browse/COCOON-1793 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Attachments: enumselectionlist-samples.diff, enumselectionlist.diff Added support for apache enum in the EnumSelectionList. This will grant selection list items order on those JREs (expecially IBM, used by WebSphere) that will honor litteraly the Class.getDeclaredFields() javadocs and return elements in random order. This also adds the ability to implement the getEnumList method in the enum classes and implement a custom order. In case it isn't possible to retrieve a valid iterator for the apache enum, then the common way will be used. Since i felt the lack of it, i also added a null-text="i18nkey" so that it's now possible to specify a label for the null element when the selection list is nullable="true". The second patch updates the samples adding a PreferredContact apache enum to the Contact bean, the form2 files (both for bean and xml binding) and messages, to demostrate the usage of both apache enum and the new null-text. -- 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] Created: (COCOON-1790) VerifyException "Attempt to split long or double on the stack" in javaflow
VerifyException "Attempt to split long or double on the stack" in javaflow -- Key: COCOON-1790 URL: http://issues.apache.org/jira/browse/COCOON-1790 Project: Cocoon Type: Bug Components: Blocks: Java Flow Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni When writing code like this : long time = System.currentTimeMillis(); Date date = new Date(time); the given exception is thrown. It's a validation exception. This happens when a long (maybe also a double?) is used in a constructor (not in a function call). The following code is a workaround : Date date = new Date(); date.setTime(time); but can be used only when the object we are instantiating have a getter as an alternative to the constructor parameter. I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X branch. Don't know yet if this apply to other versions of cocoon. I'm using Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. Googling around it seems that this exception is raised when the data type in a pop2 JVM instruction is not correct. I think this is one of the side-effects of the javaflow BCEL manipulations, but I'm not skilled enought on BCEL and similar stuff to even think of a possible solution. The exception is raised loading the javaflow class, so it will prevent the entire flow (and not only the affected method) to be used. Also, the exception will just tell you that the class is invalid, and not point you to the place in code where this long is used in a constructor, so you'll have to spot it by hand. I can produce a test case to try to narrow it down, but the given 3 lines of code are enought to produce the error in my javaflows. -- 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] Created: (COCOON-1789) [PATCH] Char datatype
[PATCH] Char datatype - Key: COCOON-1789 URL: http://issues.apache.org/jira/browse/COCOON-1789 Project: Cocoon Type: New Feature Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Priority: Minor Attachments: chardataype-conf.diff, chardataype-samples.diff, chardataype.diff Cocoon forms lacks a Char datatype. This is often needed in bean bindings for database oriented applications, where the char often appears in a field. The first patch provides a char datatype with it's builder, it's char convertor, the second patch the changes to the configuration to add the datatype, the third a modification of the samples form2 definition, bean and binding to give an example of the char datatype adding a middleInitial char field. Patches applied to 2.1.X branch, but tested on 2.1.6, 2.1.7 and trunk. Thanks to Maurizio Pillitu for first implementation. -- 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] Created: (COCOON-1782) [PATCH] Support for CSS classes in cocoon forms XSL
[PATCH] Support for CSS classes in cocoon forms XSL
---
Key: COCOON-1782
URL: http://issues.apache.org/jira/browse/COCOON-1782
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Reporter: Simone Gianni
Attachments: xsl-css.diff
Added CSS classes to key elements in default cocoon forms XSL. Here is a brief
explanation of how it works :
---
Common fields styling
The general rule for common fields (styled by forms-field-styling.xsl) is to
apply the following classes :
- "forms" : is placed always, to avoid name clashes with already present
site-specific classes.
- : can be "field", "action", "output", "booleanfield",
"multivaluefield", "upload", "repeater", "imagemap", "aggregatefield", "form",
"messages".
- : the state of the widget, can be empty, "active", "disbled",
"output".
- "required" : if the widget is required.
- "with-errors" : if there are some fi:validation-messages associated with the
widget.
- : an optional, user defined, fi:styling/@class that can be specified
on a field to fine tune widget styling.
This technique makes it easy to write very specific CSS rules, as much as very
general ones. For example :
input.required {
color: blue;
}
Will make all required inputs have a blue text color, while
input.upload.required {
color: red;
}
will make only the required upload widgets have a red text color.
The HTML elements to which this classes will be applied varies depending on the
widget type and special fi:styling attributes (like list-type for selection
lists, fi:styling/@type etc..).
There are also other classes, placed to correctly style other elements, these
are :
- "captcha" : applied to the img element of a captcha field.
- "required-mark" : applied to the span containing the "*" near the required
fields.
- "validation-message" : applied to the anchor element containing the "!" near
the fields with errors.
- "vertical-list" and "horizontal-list" : applied to the tables used to layout
these kind of lists.
- "upload-change-button" : applied to the button that appears next to the
upload widget when a file has been uploaded.
For the validation-errors element (which outputs a list of all validation
errors found in the form) there are other special classes :
- "validation-errors" : applied to the div that contains the errors recap block.
- "validation-errors-header" and "validation-errors-footer" : applied to the
paragraphs that contains the header and footer of the errors recap.
- "validation-errors-content" : applied to the "li" element of the errors list.
Page styling
Another set of classes is used for page styling (forms-page-styling.xsl). The
general rule for fi:group is to apply the following classes :
- "forms" : as always placed to mark a cocoon forms CSS class.
- "group" : identify a group class
- or : the fi:styling/@layout or fi:styling/@type of the
fi:group
- : an optional, user defined, fi:styling/@class that can be specified
on a group to fine tune styling.
As for the widgets, these classes are applied to different HTML elements
depèending on the group type and layout.
For those layouts which uses tables, special classes are used to mark specific
cells :
- "label" : applied to the "td" containing the label
- "content" : applied to the "td" containing the form input
- "action" : applied to the "td" containing an action widget, for those layouts
that creates special cells for this widgets.
- "booleanfield" : applied to the "td" containing a booleanfield widget, for
those layouts that creates special cells for this widgets.
- "other" : applied to the "td" containing other content, like another nested
fi:group or non cocoon forms elements.
Consider this CSS snippet :
table.group.columns {
border: 1px solid blue;
}
table.group.columns td {
background: yellow;
}
table.group.columns td.label {
background: blue;
color: white;
width: 20%;
}
This will style every fi:group with layout "columns" placing a blue border on
the table, then using a yello background for every cell in the table, while a
blue blackground, a while text color and a width of 20% will be used for cells
containing labels.
A special case of layout is handled directly in the basic xsl
(forms-field-styling.xsl), which format with a "columns" similar layout a
"fi:form". In this case the same classes (label, content etc..) applies.
Some special classes are used for the tab layout. These are :
- "tabArea" : applied to the div containing the tabs.
- "tabContent" : applied to the div containing the tabs contents.
- "tab" : applied to every span representing a single tab
- "active" : marks the currently active tab.
- "validation-message" : applied to the span placed in a tab when there are
validation-messages in any control inside that tab.
Compatibility with old classes
The co
[jira] Created: (COCOON-1781) Processing phase listener cannot be configured from form definitio
Processing phase listener cannot be configured from form definitio
--
Key: COCOON-1781
URL: http://issues.apache.org/jira/browse/COCOON-1781
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Reporter: Simone Gianni
Attachments: phase_listener.diff
It's not currently possible to specify a ProcessingPhaseListener from the form
definition.
The patch makes it possible to specify a and specify a
listener in it. Also patched the javascript listener to support this kind of
events, so that can be used. For example :
Packages.java.lang.System.out.println('Processing phase : ' +
event.getPhase());
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
[ http://issues.apache.org/jira/browse/COCOON-1685?page=comments#action_12367041 ] Simone Gianni commented on COCOON-1685: --- Added a PROCESS_INITIALIZE event type, now this event is broadcasted as the first event. Note that LOAD_MODEL and SAVE_MODEL are not used. LOAD_MODEL was incorrectly broadcasted instead of the new event i added, while SAVE_MODEL seems to have no references. I suppose this events should be broadcasted when a binding is applied. > Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent > - > > Key: COCOON-1685 > URL: http://issues.apache.org/jira/browse/COCOON-1685 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8 > Reporter: Simone Gianni > Attachments: process_initialize.diff > > In the Form.process() method, there is a listener.phaseEnded on line 296 > which sends a LOAD_MODEL_VALUE the first time the form is executed, and a > READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is > registered it will receive a READ_FROM_REQUEST_VALUE before the request has > been processed, and another one after. > IMMO there are the following possible solutions : > - remove this event broadcast. > - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes > his chance to get broadcasted, while the spurious one doesn't. > - add a "PROCESS_INITIALIZED" phase event and send this one at this point. > I can produce the patch if needed, but don't know which solution is the best > one. -- 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] Updated: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
[ http://issues.apache.org/jira/browse/COCOON-1685?page=all ] Simone Gianni updated COCOON-1685: -- Attachment: process_initialize.diff PATCH for the issue > Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent > - > > Key: COCOON-1685 > URL: http://issues.apache.org/jira/browse/COCOON-1685 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8 > Reporter: Simone Gianni > Attachments: process_initialize.diff > > In the Form.process() method, there is a listener.phaseEnded on line 296 > which sends a LOAD_MODEL_VALUE the first time the form is executed, and a > READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is > registered it will receive a READ_FROM_REQUEST_VALUE before the request has > been processed, and another one after. > IMMO there are the following possible solutions : > - remove this event broadcast. > - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes > his chance to get broadcasted, while the spurious one doesn't. > - add a "PROCESS_INITIALIZED" phase event and send this one at this point. > I can produce the patch if needed, but don't know which solution is the best > one. -- 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] Created: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent - Key: COCOON-1685 URL: http://issues.apache.org/jira/browse/COCOON-1685 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8-dev (Current SVN) Reporter: Simone Gianni In the Form.process() method, there is a listener.phaseEnded on line 296 which sends a LOAD_MODEL_VALUE the first time the form is executed, and a READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is registered it will receive a READ_FROM_REQUEST_VALUE before the request has been processed, and another one after. IMMO there are the following possible solutions : - remove this event broadcast. - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes his chance to get broadcasted, while the spurious one doesn't. - add a "PROCESS_INITIALIZED" phase event and send this one at this point. I can produce the patch if needed, but don't know which solution is the best one. -- 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] Reopened: (COCOON-476) [PATCH] No-cache enhancement for ResourceReader component
[ http://issues.apache.org/jira/browse/COCOON-476?page=all ]
Simone Gianni reopened COCOON-476:
--
> [PATCH] No-cache enhancement for ResourceReader component
> -
>
> Key: COCOON-476
> URL: http://issues.apache.org/jira/browse/COCOON-476
> Project: Cocoon
> Type: Improvement
> Components: * Cocoon Core
> Versions: 2.0.3
> Environment: Operating System: Linux
> Platform: Other
> Reporter: andi
> Assignee: Cocoon Developers Team
> Priority: Minor
>
> This small patch enables the possibility to prevent IE from caching resources:
> Sitemap:
>
>
>
> In the original code, it wasn't possible to set the expires value to 0.
> Therefore it wasn't possible to prevent IE to cache specific resources.
> Can someone apply this small patch? Thx.
> Andi
> diff
> ResourceReader.java
> /home/xmlcocoon2/src/java/org/apache/cocoon/reading/Resourc
> eReader.java
> 163,166d162
> < if (expires == 0) {
> < response.addHeader("Vary", "Host");
> < }
> <
--
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] Commented: (COCOON-476) [PATCH] No-cache enhancement for ResourceReader component
[
http://issues.apache.org/jira/browse/COCOON-476?page=comments#action_12357594 ]
Simone Gianni commented on COCOON-476:
--
This patch is giving some problems. The Vary header (as stated on
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44 ) is not used to
tell a browser not to cache a file, this happens with Microsoft explorer just
because Microsoft decided not to fully implement this header in their cache
control, and took the short path "don't cache if this header is there" (look
http://lists.over.net/pipermail/mod_gzip/2002-December/006826.html for a nice
overview)
This was good as long as the HTTP/1.1 specs were quite new and Firefox was not
there. Firefox has a different approach, caches the file, and many proxies as
well, so using the Vary header is now Microsoft ie specific and based on a
Microsoft ie bug.
IMMO the common headers should be used (Expires, Last-modified, Pragma etc..
etc..) not to be Microsoft specific and to be HTTP/1.1 compliant. I can produce
the patch if needed.
> [PATCH] No-cache enhancement for ResourceReader component
> -
>
> Key: COCOON-476
> URL: http://issues.apache.org/jira/browse/COCOON-476
> Project: Cocoon
> Type: Improvement
> Components: * Cocoon Core
> Versions: 2.0.3
> Environment: Operating System: Linux
> Platform: Other
> Reporter: andi
> Assignee: Cocoon Developers Team
> Priority: Minor
>
> This small patch enables the possibility to prevent IE from caching resources:
> Sitemap:
>
>
>
> In the original code, it wasn't possible to set the expires value to 0.
> Therefore it wasn't possible to prevent IE to cache specific resources.
> Can someone apply this small patch? Thx.
> Andi
> diff
> ResourceReader.java
> /home/xmlcocoon2/src/java/org/apache/cocoon/reading/Resourc
> eReader.java
> 163,166d162
> < if (expires == 0) {
> < response.addHeader("Vary", "Host");
> < }
> <
--
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
