[jira] Created: (COCOON-1718) Ajax client library handling script tags
Ajax client library handling script tags Key: COCOON-1718 URL: http://issues.apache.org/jira/browse/COCOON-1718 Project: Cocoon Type: Improvement Components: Blocks: Ajax Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Freek Segers Attachments: cocoon-ajax.js The way Ajax currently handles script tags in browser updates, the scripts are evaluated before the HTML elements are replaced. Because scripts may call for example document.getElementById() they act on the old elements, that are replaced later on. It would be better to evaluate the scripts after the element has been replaced. The attached file contains a few overridden functions from from the default cocoon-ajax.js file to postpone script evaluation until after element replacement. I'm still investigating a possible problem with IE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Ajax client library handling script tags
Freek Segers wrote: Thanks for the quick response. I already made a fix so I could keep working. Do you want we to submit this somewhere? Please. Add it to jira [1] Best Regards, Antonio Gallardo. [1] http://issues.apache.org/jira/secure/CreateIssue!default.jspa
Re: Bug report for Cocoon 2 [2005/12/18]
Pier Fumagalli wrote: On 18 Dec 2005, at 23:00, Jorg Heymans wrote: I've asked infra@ for this report to be switched off. It will no longer run as of today. Shall we re-create one from Jira? +1 Best Regards, Antonio Gallardo.
Re: Cocoon's use of Daisy on the Cocoon Zone
Unfortunately no-one from cocoon-dev followed up on this and the topic is stalled at Infrastructure. So please do follow up. The suggestion was to resolve the main part at site-dev@ Any ASF committer can join: http://www.apache.org/dev/infra-mail.html Today i sent a separate message to [EMAIL PROTECTED] to try to move things along on another front. http://marc.theaimsgroup.com/?l=incubator-general&m=113504829430312 -David On Fri, Oct 28, 2005 at 04:16:45PM +0100, Upayavira wrote: > [[This is copied to [EMAIL PROTECTED] for informational purposes. For the > moment please keep infrastructure at apache.org as the principal list > for this discussion, as the issues discussed are wider than just Cocoon]] > > = Cocoon and Daisy = > We have discussed this within the Cocoon PMC, and would like to start > discussions with infrastructure about our Daisy instance. > > Let me start by saying that, previous to this installation, Cocoon's > documentation saw next to no movement. Now, we are regularly seeing > updates by multiple people, as can be witnessed by the > docs@cocoon.apache.org list. > > That change is significant for the Cocoon project. > > == How it all Works == > > When we wish to publish a new document, we go to our Daisy instance and > log in. Users have various access levels. Anonymous access is allowed, > however we plan to have a robots.txt file blocking crawlers, and to put > large warnings "this content is not live content" or some such when > content is viewed anonymously. > > Anyone can create an account. Logging in gives you the ability to add > comments to documents. > > Users can be granted "doc-editor" rights (a lightweight proposal on the > mailing list is sufficient for this), which allows a user to edit > documents, but not publish them. (Unpublished docs will not appear on > the anonymous Daisy site). Any committer will be given doc-committer > rights, which allows them to mark a document as published after reviewing. > > This allows for Stefano's lightweight documentation authorship ideas > from Doco (http://wiki.apache.org/cocoon/Doco) - we will encourage our > users to start contributing to our documentation and make it easy for > them to do so. > > When we do a new release of Cocoon, we will publish the site. This will > currently use Forrest and its Daisy plugin. The Forrest community > already have a Forrestbot set up on their zone which generates the > Cocoon site every 3 hours. We would then just need to commit that > generated site to SVN, and check that out on Minotaur for publishing. > > I believe the data is stored in a combination of filesystem and Mysql. > Data is versioned in the repository, and commit notices go to our > docs@cocoon.apache.org mailing list. > > As explained, we do not intend to have this Daisy instance used by the > public for our live documentation, although we do want to encourage > people to use it where they see the need for modifications to our docs. > > == What Next == > > So, we have definitely moved from an experiment to an 'in use' > installation. I believe our system is working well for us, and would > like to discuss further here about how we should proceed. > > I believe also that our system might be of interest to other ASF > projects and thus it may be worth exploring whether it can be installed > on an alternative ASF machine. > > So, where do we go from here? :-) > > Regards, Upayavira
Re: Cocoon 2.1.7 hang
We are still experiencing this hang. Does anyone have any idea what may be causing these threads to hang? It seems to hanging at the same spot, but admittedly I'm not sure what I'm looking at. "http-8080-Processor1" daemon prio=1 tid=0x082ca7d8 nid=0x574c runnable [2e6fe000..2e6ff87c] at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java :92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:714) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer (ByteChunk.java:398) at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:304) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:921) at org.apache.coyote.Response.action (Response.java:182) at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:326) at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:297) at org.apache.coyote.tomcat5.CoyoteOutputStream.flush (CoyoteOutputStream.java:85) at org.apache.cocoon.util.BufferedOutputStream.realFlush(BufferedOutputStream.java:128) at org.apache.cocoon.environment.AbstractEnvironment.commitResponse(AbstractEnvironment.java:512) at org.apache.cocoon.Cocoon.process(Cocoon.java:630) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) ... "http-8080-Processor1" daemon prio=1 tid=0x082ca7d8 nid=0x574c runnable [2e6fe000..2e6ff87c] at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java :92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:714) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer (ByteChunk.java:398) at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:304) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:921) at org.apache.coyote.Response.action (Response.java:182) at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:326) at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:297) at org.apache.coyote.tomcat5.CoyoteOutputStream.flush (CoyoteOutputStream.java:85) at org.apache.cocoon.util.BufferedOutputStream.realFlush(BufferedOutputStream.java:128) at org.apache.cocoon.environment.AbstractEnvironment.commitResponse(AbstractEnvironment.java:512) at org.apache.cocoon.Cocoon.process(Cocoon.java:630) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
Re: Ajax client library handling script tags
Thanks for the quick response. I already made a fix so I could keep working. Do you want we to submit this somewhere? Freek On 19-dec-2005, at 13:38, Sylvain Wallez wrote: Freek Segers wrote: Hi, I'm having a problem with the way Ajax handles script tags in the browser update XML. The way it is implemented in Cocoon 2.1.8 the scripts are evaluated before the HTML elements are replaced. Because my script calls document.getElementById() my script acts on the old element, that is replaced later on. Wouldn't it be better to evaluate the scripts after the element has been replaced? Yep. You're right. I'll change this. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Exception using auto-generated Forms in 2.1.8
Am Montag, 19. Dezember 2005 16:57 schrieb Sylvain Wallez: Hello, > > I don't know if this should be like this, i just wanted to inform you: > > > > In 2.1.8 i get an exception using this construct: > > > > > > > > > > > > whereas it worked fine in 2.1.7. > > > > If i change the fi:styling to ft:styling (i vs t) everything is fine > > (took me really long to find this!). > > Is the "fi:" namespace declared in whatever (looks like a complicated > setup) generates ? Yes, i have both Namespaces declared. I have no Idea what causes the error, because in 2.1.7 and some version of 2.1.8-dev (before the release) it worked fine. I just discovered this error when writing some ant scripts that automatically build the app from cocoon-src, eXist xmldb, and some other stuff. BTW. the new error stacktrace was really helpful! :-) If you need more Information, just ask, for me the problem is "solved" atm. The template and definition for the form is automatically built using some xsls and xml config files. Not really complicated, but very easy to use afterwards (even if it mixes up model and view a little bit). Christoph
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 57 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A "jcr:" protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-19122005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-19122005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-19122005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 29 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-19122005.jar -Dbuild=build/cocoon-19122005 gump-core [Working Directory: /usr/local/g
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 57 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A "jcr:" protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-19122005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-19122005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-19122005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 29 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-19122005.jar -Dbuild=build/cocoon-19122005 gump-core [Working Directory: /usr/local/g
Re: svn commit: r357004 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/datatype/convertor: FormattingDateConvertor.java FormattingDateConvertorBuilder.java Icu4jDateConvertor.java Icu4jD
Sylvain Wallez wrote: Hmm... forbidding "12-32-2005" seems more like a bug fix to me than a backwards incompatible change ! +1 On the user list often people ask why cforms quietly compute the right date without notice. The expected behavior is a Invalid Date error message. Best Regards, Antonio Gallardo.
RE: rejuvenating the webdav block
Hi!
Thanks, I would have missed the versioning in the source. Unfortunately, there
are some incompatibilities between the existing VersionableSource interface
from the repository block and what can be done via WebDAV.
Some issues:
- Resources in WebDAV are not versioned by default [1]
- Currently, there is no way to access older revisions of a source, you have to
guess
- No way to make new revision either (in webdav via checkin/out)
So, seeing the current shortcomings and inadequacies of the VersionableSource
interface and seeing that SlideSource is the only implementing class, I would
propose the following:
I would refactor the interface to something like this:
public Interface VersionableSource {
boolean isVersioned();
boolean startVersioning();
String getSourceRevision();
String getLatestSourceRevision();
Map getSourceRevisions(); (renders the version tree, maybe there is a better
way)
boolean checkout();
boolean uncheckout();
boolean checkin();
}
Other than that, I would also like to add a removeSourceLocks(SourceLock)
method in LockableSource.
On another note: I need the eventcaching block for webdav, but that one only
needs jms in one class, and databases in the samples. So, I'll work on the
dependency issue there instead of in the webdav block directly.
WDYT?
max
[1] http://www.ietf.org/rfc/rfc3253.txt
> -Original Message-
> From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 16, 2005 17:51
> To: dev@cocoon.apache.org
> Subject: Re: rejuvenating the webdav block
>
>
> * Max Pfingsthorn:
>
> > I would like to start rejuventating the webdav block. We have
> > some code to do cool things like event caching and a more
> > general purpose WebDAVTransformer (which can also do propfind,
> > proppatch, etc).
> >
> > If you know anything you would like to see in the webdav block,
> > please say so now. Maybe I can work it in!
>
> Hello Max,
>
> Thank you for taking care of the WebDAV block. We wish to have
> versioning support in WebDAVSource: checkin(), checkout(), lock(),
> unlock(), versionControl(), and so on.
>
> Is there an open-source implementation for that?
> --
> Jean-Baptiste Quenot
> Systèmes d'Information
> ANYWARE TECHNOLOGIES
> Tel : +33 (0)5 61 00 52 90
> Fax : +33 (0)5 61 00 51 46
> http://www.anyware-tech.com/
>
Re: Exception using auto-generated Forms in 2.1.8
Christoph Hermann wrote: Hello, I don't know if this should be like this, i just wanted to inform you: In 2.1.8 i get an exception using this construct: whereas it worked fine in 2.1.7. If i change the fi:styling to ft:styling (i vs t) everything is fine (took me really long to find this!). Is the "fi:" namespace declared in whatever (looks like a complicated setup) generates ? Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Exception using auto-generated Forms in 2.1.8
Hello, I don't know if this should be like this, i just wanted to inform you: In 2.1.8 i get an exception using this construct: whereas it worked fine in 2.1.7. If i change the fi:styling to ft:styling (i vs t) everything is fine (took me really long to find this!). The exception is: org.apache.cocoon.ProcessingException: Failed to process pipeline at - file:/C:/...path/to/sitemap.xmap:846:61 at - file:/C:/...path/to/sitemap.xmap:845:92 at - file:/C:/...path/to/sitemap.xmap:844:67 at - file:/C:/...path/to/sitemap.xmap:840:68 at - file:/C:/...path/to/sitemap.xmap:838:92 at - file:/C:/...path/to/sitemap.xmap:837:66 at - file:/C:/...path/to/sitemap.xmap:833:84 at - file:/C:/...path/to/sitemap.xmap:832:88 at - file:/C:/...path/to/sitemap.xmap:828:83 at - file:/C:/downloads/programme/cocoon/eucostip/build/cocoon/webapp/sitemap.xmap:796:66 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:144) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:951) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:582) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:183) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:480) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.Cocoon.process(Cocoon.java:679) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketLis
Re: svn commit: r357004 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/datatype/convertor: FormattingDateConvertor.java FormattingDateConvertorBuilder.java Icu4jDateConvertor.java Icu4jD
Ugo Cei wrote: Il giorno 19/dic/05, alle ore 13:43, Sylvain Wallez ha scritto: Do we really need yet another configuration option? I didn't knew about this date format's leniency, and IMO the date convertor shouldn't be lenient since "12-32-2005" is obviously an invalid input. So what about simply always set lenient to false? The problem is that the default leniency for DateFormat is true, so setting it to false would break backward compatibility (even if it's admittedly improbable that someone would have relied on this behavior). Hmm... forbidding "12-32-2005" seems more like a bug fix to me than a backwards incompatible change ! With my fix, we have one more option, but omitting it gives exactly the same behavior as before. All in all, I don't have a strong opinion on this, so we might do a quick informal vote and let people decide. +1 for always setting lenient to false! Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
[jira] Commented: (COCOON-1717) Use custom cache keys for caching uri coplets using input modules.
[ http://issues.apache.org/jira/browse/COCOON-1717?page=comments#action_12360818 ] Philippe Gassmann commented on COCOON-1717: --- The component affected by this evolution is the Portal block. > Use custom cache keys for caching uri coplets using input modules. > -- > > Key: COCOON-1717 > URL: http://issues.apache.org/jira/browse/COCOON-1717 > Project: Cocoon > Type: Improvement > Versions: 2.1.9-dev (current SVN) > Reporter: Philippe Gassmann > Attachments: input-module-attribute-patch > > When using cache global with attributes in a caching uri coplet, it is > sometimes usefull to specify a parameter that the coplet depends on and that > is not a coplet attribute. (the coplet could depend on layout parameters, the > current user or something in the session). > The patch I provide solve this problem by adding parameters to the cache key > using input modules. The developper can add custom parameters as coplet data > attributes : > > input-module-cache-key:userlogin > > >session-context:authentication/authentication/user/login > > > input-module-cache-key:myLayout > >portal-layout:MYLAYOUT/aspectDatas/tab > > The key used by the cache will contain, after regular coplet attributes : > &userLogin=phil&myLayout=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] Created: (COCOON-1717) Use custom cache keys for caching uri coplets using input modules.
Use custom cache keys for caching uri coplets using input modules. -- Key: COCOON-1717 URL: http://issues.apache.org/jira/browse/COCOON-1717 Project: Cocoon Type: Improvement Versions: 2.1.9-dev (current SVN) Reporter: Philippe Gassmann Attachments: input-module-attribute-patch When using cache global with attributes in a caching uri coplet, it is sometimes usefull to specify a parameter that the coplet depends on and that is not a coplet attribute. (the coplet could depend on layout parameters, the current user or something in the session). The patch I provide solve this problem by adding parameters to the cache key using input modules. The developper can add custom parameters as coplet data attributes : input-module-cache-key:userlogin session-context:authentication/authentication/user/login input-module-cache-key:myLayout portal-layout:MYLAYOUT/aspectDatas/tab The key used by the cache will contain, after regular coplet attributes : &userLogin=phil&myLayout=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
Re: svn commit: r357004 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/datatype/convertor: FormattingDateConvertor.java FormattingDateConvertorBuilder.java Icu4jDateConvertor.java Icu4jD
Il giorno 19/dic/05, alle ore 13:43, Sylvain Wallez ha scritto: Do we really need yet another configuration option? I didn't knew about this date format's leniency, and IMO the date convertor shouldn't be lenient since "12-32-2005" is obviously an invalid input. So what about simply always set lenient to false? The problem is that the default leniency for DateFormat is true, so setting it to false would break backward compatibility (even if it's admittedly improbable that someone would have relied on this behavior). With my fix, we have one more option, but omitting it gives exactly the same behavior as before. All in all, I don't have a strong opinion on this, so we might do a quick informal vote and let people decide. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine & Food Blog: http://www.divinocibo.it/
Re: svn commit: r357004 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/datatype/convertor: FormattingDateConvertor.java FormattingDateConvertorBuilder.java Icu4jDateConvertor.java Icu4jD
Ugo Cei wrote: Il giorno 15/dic/05, alle ore 12:24, [EMAIL PROTECTED] ha scritto: Author: ugo Date: Thu Dec 15 03:23:56 2005 New Revision: 357004 URL: http://svn.apache.org/viewcvs?rev=357004&view=rev Log: [Forms] Added "lenient" attribute to date convertors. What this change does is adding a new "lenient" attribute to the CForms date convertors (formatting AND icu4j). By default, "lenient" is true and what this means is that a date like "12-32-2005" (Dec. 32nd) is silently converted to "01-01-2006" due to the way Java's DateFormat class works. But if you set lenient="false", a date like that will be rejected and will not pass validation. Do we really need yet another configuration option? I didn't knew about this date format's leniency, and IMO the date convertor shouldn't be lenient since "12-32-2005" is obviously an invalid input. So what about simply always set lenient to false? Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Add form widgets
Ralph Goers wrote: I have been asked to look into how custom form widgets can be added. With the block structure in 2.2 this would imply that the widgets would need to be added to our own block. How can we "append" to the widget definitions in cocoon-forms.xconf without touching that file since it will be internal to the forms block? The structure of component management currently doesn't allow this, as the FormManager creates its own ServiceSelector, and therefore can't use the xconf includes. This is something that must be changed though. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: rejuvenating the webdav block
Max Pfingsthorn wrote: Dear Cocooners, I would like to start rejuventating the webdav block. We have some code to do cool things like event caching and a more general purpose WebDAVTransformer (which can also do propfind, proppatch, etc). If you know anything you would like to see in the webdav block, please say so now. Maybe I can work it in! I once hacked the webdav sitemap to build a simple webdav server with no Repository component, and using a regular TraversableSource (i.e. "file:"). I can provide it if you think it can be useful. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: Ajax client library handling script tags
Freek Segers wrote: Hi, I'm having a problem with the way Ajax handles script tags in the browser update XML. The way it is implemented in Cocoon 2.1.8 the scripts are evaluated before the HTML elements are replaced. Because my script calls document.getElementById() my script acts on the old element, that is replaced later on. Wouldn't it be better to evaluate the scripts after the element has been replaced? Yep. You're right. I'll change this. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
[jira] Created: (COCOON-1716) RandomNumberModule wrong answers
RandomNumberModule wrong answers Key: COCOON-1716 URL: http://issues.apache.org/jira/browse/COCOON-1716 Project: Cocoon Type: Bug Reporter: Antonio Fiol Apparently, the distribution of the numbers returned by the RandomNumberModule is not quite uniform. Without any special configuration, its result "mod 4" usually (if not always) returns the same value (Windows platform, Tomcat 5.5, JDK 1.5). Other than that, the code does not add up "min" to the result, so it gives a random number in the range (0,max-min), and not in (min,max) as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Bug report for Cocoon 2 [2005/12/18]
Pier Fumagalli wrote: >> I've asked infra@ for this report to be switched off. It will no longer >> run as of today. > > Shall we re-create one from Jira? I'm not sure how useful a full report will be once we really start splitting up the core. Perhaps we should hold off a bit until the new structure is more clear. I'm easy on this though, if the bugzilla reports have been useful for other people then by all means go ahead. Jorg
Re: Bug report for Cocoon 2 [2005/12/18]
On 18 Dec 2005, at 23:00, Jorg Heymans wrote: I've asked infra@ for this report to be switched off. It will no longer run as of today. Shall we re-create one from Jira? Pier smime.p7s Description: S/MIME cryptographic signature
Ajax client library handling script tags
Hi, I'm having a problem with the way Ajax handles script tags in the browser update XML. The way it is implemented in Cocoon 2.1.8 the scripts are evaluated before the HTML elements are replaced. Because my script calls document.getElementById() my script acts on the old element, that is replaced later on. Wouldn't it be better to evaluate the scripts after the element has been replaced? Freek Segers
