Re: Cound it possible using ajax after cform submit?
roy huang wrote: > Hi,all: > I am trying implement an application using CForm with Ajax.Now I have a > problem: > When form submit(using submit widget),the form will entirely refresh and > display the result,just like samples in form block.I just want to using Ajax > to make the entire process don't refresh.Here's my thought: > 1.Use action widget instead of submit widget > 2.Like multipage sample,I can use a fd:group to show the result > But this will get several problems > A.action widget won't validate form's value,submit widget will. > B.in form define ,how can I get binding and other object in > parent flowscript?If put this object in global the same people access twice > or more at the same continuation life cycle will cause problem. > > Any suggestion? > In Ajax mode, a submit widget doesn't necessarily lead to a full page refresh. The request for the submit widget is sent asynchronously, and the page is refreshed only if we exit form.showForm(), i.e. the form is valid. If the form is not valid, then partial page update instructions are sent just like for any other action. However, there are some widget that don't support Ajax, such as file upload. Do you have an upload in your form? Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Cound it possible using ajax after cform submit?
Hi,all: I am trying implement an application using CForm with Ajax.Now I have a problem: When form submit(using submit widget),the form will entirely refresh and display the result,just like samples in form block.I just want to using Ajax to make the entire process don't refresh.Here's my thought: 1.Use action widget instead of submit widget 2.Like multipage sample,I can use a fd:group to show the result But this will get several problems A.action widget won't validate form's value,submit widget will. B.in form define ,how can I get binding and other object in parent flowscript?If put this object in global the same people access twice or more at the same continuation life cycle will cause problem. Any suggestion? regards Roy Huang
Re: Planning 2.2
On Nov 21, 2005, at 12:16 AM, Reinhard Poetz wrote: Carsten Ziegeler wrote: Now as 2.1.8 is out, we should think about a 2.2 release. I think for a 2.2 release we should at least finish the following things: - Finish the maven2 build - Sync everything with 2.1.x (apply changes that were only applied to 2.1.x if appropriate) - Separate samples from blocks - Remove author tags While imho the first two items on the list are a simple must, I think we should really do the other ones as well. If we don't aim to do them for 2.2 we'll simply never do them. And it's really not that hard to do it. And finally, we should make a stable forms block (and perhaps others as well). WDYT Aren't we aiming at a 2.2M1 release? If yes, the only must is a working build system IMHO. I'm a bit confused, is this the only difference between 2.1 and 2.2 or are the other changes complete and ready to roll? These changes amount to a refactoring. What distinguishes 2.2 from 2.1.8? As date I agree with Sylvain that we should schedule it for the mid or the of January so that people (like me that nearly don't have any time) can contribute over the Chrismas break. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: "If they can get you asking the wrong questions, they don't have to worry about answers." - Thomas Pynchon Gravity's Rainbow
Re: Core Documentation
Le 20 nov. 05, à 18:14, Stefan Pietschmann a écrit : ...For this any documentation or tips would be great… I read that Bertrand gave an introduction on the Cocoon internals at the CocoonGT2005. Are there any docs from there perhaps?... My presentation was not on internals but on http://wiki.apache.org/cocoon/BricksCms We had some talks at the Hackathon about internals, a document has been written at http://cocoon.zones.apache.org/daisy/documentation/732.html, but it has not been published to the Cocoon website yet. But...what is your use-case? I'm wondering if there might be an easier way than digging deep into sitemap internals. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Planning 2.2
Carsten Ziegeler wrote:
Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
2.2 release we should at least finish the following things:
- Finish the maven2 build
- Sync everything with 2.1.x (apply changes that were only applied to
2.1.x if appropriate)
- Separate samples from blocks
- Remove author tags
While imho the first two items on the list are a simple must, I think we
should really do the other ones as well. If we don't aim to do them for
2.2 we'll simply never do them. And it's really not that hard to do it.
And finally, we should make a stable forms block (and perhaps others as
well).
WDYT
Aren't we aiming at a 2.2M1 release? If yes, the only must is a working build
system IMHO.
As date I agree with Sylvain that we should schedule it for the mid or the of
January so that people (like me that nearly don't have any time) can contribute
over the Chrismas break.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[EMAIL PROTECTED]: Project cocoon-block-cron (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-block-cron has an issue affecting its community integration. This issue affects 4 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-cron : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-repository : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [cron-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html Work Name: build_cocoon_cocoon-block-cron (Type: Build) Work ended in a state of : Failed Elapsed: 7 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-20112005 -Dblock-name=cron gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-20112005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-20112005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-20112005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-20112005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-20112005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20112005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jxpath/dist/commons-jxpath.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/comm
[EMAIL PROTECTED]: Project cocoon-block-cron (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-block-cron has an issue affecting its community integration. This issue affects 4 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-cron : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-repository : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [cron-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html Work Name: build_cocoon_cocoon-block-cron (Type: Build) Work ended in a state of : Failed Elapsed: 7 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-20112005 -Dblock-name=cron gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-20112005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-20112005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-20112005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-20112005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-20112005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20112005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jxpath/dist/commons-jxpath.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/comm
[EMAIL PROTECTED]: Project cocoon-block-forms (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-block-forms has an issue affecting its community integration. This issue affects 7 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-apples : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-tour : Java XML Framework - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-forms/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [forms-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-forms/gump_work/build_cocoon_cocoon-block-forms.html Work Name: build_cocoon_cocoon-block-forms (Type: Build) Work ended in a state of : Failed Elapsed: 19 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-20112005 -Dblock-name=forms gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-20112005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-20112005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-20112005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-20112005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-20112005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20112005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jxpath/dist/commons-jxpath.jar:/usr/loc
[EMAIL PROTECTED]: Project cocoon-block-forms (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-block-forms has an issue affecting its community integration. This issue affects 7 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-apples : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-tour : Java XML Framework - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-forms/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [forms-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-forms/gump_work/build_cocoon_cocoon-block-forms.html Work Name: build_cocoon_cocoon-block-forms (Type: Build) Work ended in a state of : Failed Elapsed: 19 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-20112005 -Dblock-name=forms gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-20112005.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-20112005.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-20112005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/api/target/excalibur-pool-api-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/impl/target/excalibur-pool-impl-20112005.jar:/usr/local/gump/public/workspace/excalibur/components/pool/instrumented/target/excalibur-pool-instrumented-20112005.jar:/usr/local/gump/public/workspace/excalibur/containerkit/logger/target/excalibur-logger-20112005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20112005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/jakarta-turbine-jcs/target/jcs-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons-httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20112005.jar:/usr/local/gump/public/workspace/jakarta-commons/jxpath/dist/commons-jxpath.jar:/usr/loc
Re: AW: Core Documentation
Stefan Pietschmann wrote:
The elements in the pipeline shall have attributes like
I don't believe you can do that. Instead you need to either do:
src="com.whatever.MyTransformer">
someID
Then implement the configurable interface and int the configure method
do config.getChild("conf").getValue() to get the value.
or in your pipeline
Then implement Parameterizable. The conf parameter will be passed to the
parameterize method.
Or finally in your pipeline do:
In this case the conf parameter will be passed in the Parameters object
to the transformer's setup method.
HTH
Ralph
Re: [RT] A Cocoon installer with IzPack
Upayavira wrote: > > Actually I interpret the communities response as "too late for 2.1 and > too early for 2.2". +1 ! > We need to stop adding features to 2.1, and we've got a lot to fix > before we'll be able to work out what an installer should do on 2.2. +1 ! > So, don't forget it, just hold onto the idea for a while! and +1 ! Jorg
[IMP] Switch bugreport to Jira (was: Re: Bug report for Cocoon 2 [2005/11/20])
Hi, Can someone take care of stop the bugzilla bug report and start a Jira based bugreport? I will like to do it myself, but I suspect I don't jave the permissions to do that. :-) Best Regards, Antonio Gallardo. [EMAIL PROTECTED] wrote: +---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6200|New|Maj|2002-02-03|Parser failure with validate=true when processing | | 9916|New|Enh|2002-06-17|Support passing of object parameters into sitemap | |10203|Opn|Enh|2002-06-25|Docs referenced by XSLT's document() are not inclu| |10827|New|Enh|2002-07-15|ESQL doesn't support namespaces| |14048|Opn|Enh|2002-10-29|[PATCH] No-cache enhancement for ResourceReader co| |15302|Ass|Nor|2002-12-12|XSPUtil.relativeFilename() returns differents resu| |15316|New|Nor|2002-12-12|FOP does not resolve relative paths | |16537|New|Nor|2003-01-29|[PATCH] fixed redirect under JRun 3.1 | |17594|New|Nor|2003-03-03|WebSphere redirect bug| |19138|New|Enh|2003-04-18|[PATCH] Made SQLTransformer paginatable | |19641|New|Nor|2003-05-05|[PATCH] HSSFSerializer Support for FreezePane | |20508|New|Nor|2003-06-05|[PATCH] Namespace cleanup in HTMLSerializer | |20631|New|Enh|2003-06-10|[PATCH] Support for transactions in SQLTransformer| |21177|Ass|Nor|2003-06-30|a crash in the name() function of the xslt, when u| |22732|Opn|Nor|2003-08-26|Cocoon Servlet can't be included | |23002|New|Nor|2003-09-08|[PATCH]: HSSF Serializer does not process and moving load() and| |24135|Ass|Min|2003-10-26|carselector sample: reloading page puts old values| |24389|New|Enh|2003-11-04|[PATCH] New ResourceLoadAction| |24391|New|Nor|2003-11-04|[PATCH] wsinclude and htmlinclude transformers| |24402|New|Enh|2003-11-04|[PATCH] XML posting from SourceWritingTransformer | |24529|New|Enh|2003-11-08|[PATCH] file upload component for usage with flows| |24741|New|Nor|2003-11-17|XSP: returns nothing| |24871|New|Maj|2003-11-20|jsp block functionality broken, running on resin 3| |24891|New|Nor|2003-11-21|raw-request-param returns null when used with cinc| |25083|Opn|Nor|2003-11-29|JXTemplate evaluates expressions in comments, need| |25099|New|Enh|2003-12-01|[Roadmap] CocoonForms | |25100|New|Nor|2003-12-01|[PATCH] sitemap parameters support for SVGSerializ| |25110|New|Enh|2003-12-01|[Roadmap] CocoonForms - release 1.0 | |25113|New|Enh|2003-12-01|[Roadmap] CocoonForms - FUTURE releases | |25114|New|Enh|2003-12-01|[Roadmap] Support for multi-page forms| |25115|New|Enh|2003-12-01|[Roadmap] General review of all XML elements | |25280|New|Enh|2003-12-08|[Roadmap] Flowscript | |25281|New|Enh|2003-12-08|[Roadmap] Make it possible to use continuations in| |25284|New|Enh|2003-12-08|[Roadmap] Flowscript - FUTURE releases| |25289|New|Enh|2003-12-08|[Roadmap] Multi-sources binding | |25290|New|Enh|2003-12-08|[Roadmap] Change expression language | |25294|Opn|Enh|2003-12-08|[Roadmap] Refactoring current styles for making ex| |25295|New|Enh|2003-12-08|[Roadmap] XUL support | |25298|New|Enh|2003-12-08|[Roadmap] Calculated fields | |25299|New|Enh|2003-12-08|[Roadmap] Default values for fields | |25301|New|Enh|2003-12-08|[Roadmap] Subforms| |25302|New|Enh|2003-12-08|[Roadmap] Utility checking form definition and for| |25303|New|Enh|2003-12-08|[Roadmap] Enhanced validation for selection lists | |25305|New|Enh|2003-12-08|[Roadmap] Form-model - JavaScript model | |25306|New|Enh|2003-12-08|[Roadmap] Binding isolation model | |25307|New|Enh|2003-12-08|[Roadmap] Cache compiled bindings | |25310|New|Enh|2003-12-08|[Roadmap] Namespaced widgets | |25312|New|Enh|2003-12-08|[Roadmap] Clean up forms (woody) samples | |25314|New|Enh|2003
Bug report for Cocoon 2 [2005/11/20]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 6200|New|Maj|2002-02-03|Parser failure with validate=true when processing | | 9916|New|Enh|2002-06-17|Support passing of object parameters into sitemap | |10203|Opn|Enh|2002-06-25|Docs referenced by XSLT's document() are not inclu| |10827|New|Enh|2002-07-15|ESQL doesn't support namespaces| |14048|Opn|Enh|2002-10-29|[PATCH] No-cache enhancement for ResourceReader co| |15302|Ass|Nor|2002-12-12|XSPUtil.relativeFilename() returns differents resu| |15316|New|Nor|2002-12-12|FOP does not resolve relative paths | |16537|New|Nor|2003-01-29|[PATCH] fixed redirect under JRun 3.1 | |17594|New|Nor|2003-03-03|WebSphere redirect bug| |19138|New|Enh|2003-04-18|[PATCH] Made SQLTransformer paginatable | |19641|New|Nor|2003-05-05|[PATCH] HSSFSerializer Support for FreezePane | |20508|New|Nor|2003-06-05|[PATCH] Namespace cleanup in HTMLSerializer | |20631|New|Enh|2003-06-10|[PATCH] Support for transactions in SQLTransformer| |21177|Ass|Nor|2003-06-30|a crash in the name() function of the xslt, when u| |22732|Opn|Nor|2003-08-26|Cocoon Servlet can't be included | |23002|New|Nor|2003-09-08|[PATCH]: HSSF Serializer does not process and moving load() and| |24135|Ass|Min|2003-10-26|carselector sample: reloading page puts old values| |24389|New|Enh|2003-11-04|[PATCH] New ResourceLoadAction| |24391|New|Nor|2003-11-04|[PATCH] wsinclude and htmlinclude transformers| |24402|New|Enh|2003-11-04|[PATCH] XML posting from SourceWritingTransformer | |24529|New|Enh|2003-11-08|[PATCH] file upload component for usage with flows| |24741|New|Nor|2003-11-17|XSP: returns nothing| |24871|New|Maj|2003-11-20|jsp block functionality broken, running on resin 3| |24891|New|Nor|2003-11-21|raw-request-param returns null when used with cinc| |25083|Opn|Nor|2003-11-29|JXTemplate evaluates expressions in comments, need| |25099|New|Enh|2003-12-01|[Roadmap] CocoonForms | |25100|New|Nor|2003-12-01|[PATCH] sitemap parameters support for SVGSerializ| |25110|New|Enh|2003-12-01|[Roadmap] CocoonForms - release 1.0 | |25113|New|Enh|2003-12-01|[Roadmap] CocoonForms - FUTURE releases | |25114|New|Enh|2003-12-01|[Roadmap] Support for multi-page forms| |25115|New|Enh|2003-12-01|[Roadmap] General review of all XML elements | |25280|New|Enh|2003-12-08|[Roadmap] Flowscript | |25281|New|Enh|2003-12-08|[Roadmap] Make it possible to use continuations in| |25284|New|Enh|2003-12-08|[Roadmap] Flowscript - FUTURE releases| |25289|New|Enh|2003-12-08|[Roadmap] Multi-sources binding | |25290|New|Enh|2003-12-08|[Roadmap] Change expression language | |25294|Opn|Enh|2003-12-08|[Roadmap] Refactoring current styles for making ex| |25295|New|Enh|2003-12-08|[Roadmap] XUL support | |25298|New|Enh|2003-12-08|[Roadmap] Calculated fields | |25299|New|Enh|2003-12-08|[Roadmap] Default values for fields | |25301|New|Enh|2003-12-08|[Roadmap] Subforms| |25302|New|Enh|2003-12-08|[Roadmap] Utility checking form definition and for| |25303|New|Enh|2003-12-08|[Roadmap] Enhanced validation for selection lists | |25305|New|Enh|2003-12-08|[Roadmap] Form-model - JavaScript model | |25306|New|Enh|2003-12-08|[Roadmap] Binding isolation model | |25307|New|Enh|2003-12-08|[Roadmap] Cache compiled bindings | |25310|New|Enh|2003-12-08|[Roadmap] Namespaced widgets | |25312|New|Enh|2003-12-08|[Roadmap] Clean up forms (woody) samples | |25314|New|Enh|2003-12-08|[Roadmap] Form state info | |25315|New|Enh|2003-12-08|[Roadmap] Form repeater row ordering | |25316|New|Enh|2003-12-08|[Roadmap] Form combo box extended lookups | |25318|New|Enh|2003-12-08|[Roadm
Re: [RT] A Cocoon installer with IzPack
Ralph Goers wrote: Sylvain Wallez wrote: Joerg Heinicke wrote: Do you really want to add such an additional feature to 2.1 branch? If we already have one (like Ugo's Guilder) we shall go with that one. But I would not add anything new like an installer based on IzPack. Ok... IzPack has been under my radar for a long time as a cool thing, and its licence change to the ASL made me consider it would be worth mentioning it here. Now I certainly don't want to start a "my installer is better than yours" or "maven or nothing" debate. So forget it! Sylvain I disagree. This is a do-ocracy. If someone implements an installer we can evaluate whether it is any good or not. If they choose to use IzPack or Guilder or whatever that is their choice. Anything else would be a little bit like me telling you that you should use some Javscript library instead of Dojo. Sure. Now I was just saying "don't fight for this idea", as I don't think I'll have the time to work on it myself. So if someone wants to do it, great, but I don't want people to start a flame fest for this. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
AW: Core Documentation
Thank you for your quick response :) | You should create a component that implements the required Avalon | interfaces and then declare it in cocoon.xconf. You will need to assign | it a role (faily simple - look at other components to see how they do | it). The code that uses the component then calls the component manager | to look up the role and return the component attached to it. The manager | will be initialized the first time it is looked up. Will have to take a look at it. | What do you mean by "attributes". Transformers, etc. can have hardwired | attributes associated with them when they are configured in the | component section of the sitemap. In addition, they can have parameters | declared in the pipelines which are passed as parameters to the setup | method. The elements in the pipeline shall have attributes like once this node is transfered, the code should use the manager and this attribute to decide, whether to append the component to the pipeline or not. Is there some entry point to the pipeline building, where I can setup the manager? It needs to be setup with every new request. Cheers, Stefan | Ralph | | | Stefan Pietschmann wrote: | | > Hello Cocooners, | > | > I'm desperately looking for Cocoon Core Documentation of any kind. I | > have - quite unsuccessfully - tried to get a clue from looking at the | > soure, but this whole sitemap processing seems quite complex. | > | > What I need to do - and I will bug you with this in detail for sure | > later - is in short: To setup a kind of manager object once the | > sitemap is read. Then any element in a pipeline - like transform, act | > etc - might have an additional attribute, which is to be evaluated by | > this manager. So I need to know: | > | >1. where to instanciate the manager | >2. where and how to get the attributes of the pipeline elements | > before they are appended to the ProcessingPipeline | >3. and how to access the manager object from there | > | > For this any documentation or tips would be great. I read that | > Bertrand gave an introduction on the Cocoon internals at the | > CocoonGT2005. Are there any docs from there perhaps? | > | > Thanx alot, | > | > Stefan | >
Re: [RT] A Cocoon installer with IzPack
Sylvain Wallez wrote: > Joerg Heinicke wrote: > >> On 20.11.2005 16:13, Upayavira wrote: >> >> What about using it to build a neat installer for Cocoon? > > > Could it handle the dependency resolution bit? That's the > callenging bit. We should keep installation and deployment separate. I have nothing against tools that unpack and install core cocoon into a specified dir, maybe even add desktop shortcuts for starting/stopping etc. Deployment however should be handled in a different tool, separate from the installer. I expect maven to handle most of the tricky stuff like the dependency resolution, we should just hand it a pom and off it goes. >> >> >> Same here. >> >>> It depends which version you are talking about 2.1 or 2.2. If we're >>> talking 2.2, then yes, Maven will do a lot of it. >> >> >> 2.2 of course. Nobody wants to maintain Maven stuff additionally for >> 2.1 I guess. >> >>> If we're talking 2.1 >>> then no, Maven won't do any. In fact, we already have some code in the >>> whiteboard that can do the necessary dependency resolution with 2.1 >>> blocks (see http://svn.apache.org/repos/asf/cocoon/whiteboard/guilder). >>> >>> With 2.1, the installer would need to do dependency resolution and a >>> build - without this, it would be hardly worth having. >> >> >> Do you really want to add such an additional feature to 2.1 branch? If >> we already have one (like Ugo's Guilder) we shall go with that one. >> But I would not add anything new like an installer based on IzPack. > > > Ok... > > IzPack has been under my radar for a long time as a cool thing, and its > licence change to the ASL made me consider it would be worth mentioning > it here. > > Now I certainly don't want to start a "my installer is better than > yours" or "maven or nothing" debate. > > So forget it! Actually I interpret the communities response as "too late for 2.1 and too early for 2.2". We need to stop adding features to 2.1, and we've got a lot to fix before we'll be able to work out what an installer should do on 2.2. So, don't forget it, just hold onto the idea for a while! Regards, Upayavira
Planning 2.2
Now as 2.1.8 is out, we should think about a 2.2 release. I think for a 2.2 release we should at least finish the following things: - Finish the maven2 build - Sync everything with 2.1.x (apply changes that were only applied to 2.1.x if appropriate) - Separate samples from blocks - Remove author tags While imho the first two items on the list are a simple must, I think we should really do the other ones as well. If we don't aim to do them for 2.2 we'll simply never do them. And it's really not that hard to do it. And finally, we should make a stable forms block (and perhaps others as well). WDYT Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Portal work
Ralph Goers wrote: > You make some good points here and the behavior is certainly correct. It > seemed to me that the search layout was called for each layout as it was > being processed, but I could be wrong. The solution I added in 2.1 was > to essentially have the AspectRenderer and RendererContext keep track of > the state of the portal as they traverse downwards. I think the end > effect could be the same, it is just the manner in which the determining > the state of the parent(s) that is different. Yes, that's true - I'll recheck my statement about the "search layout" functionality only called onces in the next days (just to be 100% sure). > > Sounds good to me. Speaking of events, have you made it so that events > which are not convertable cannot be exposed in urls? No, in this case the numbering scheme is used, but the numbers are unique per session and not per page anymore. And in addition, I think not all events that could be made convertable are already implememting the interface. > It looks like > trunk is now using page labels by default, however they still appear to > be a request parameter. Hmm, might be that trunk is using this as default, I'm not sure. But in any case, yes a request parameter is still used. We had spoken about moving the page labels into > the url path. If we know that only convertable events are coming in from > the browser I can clean up the page label stuff some and I can look into > moving the page labels into the path if you would like. Yes, please - I think this stuff should be made more general- Which means it should work with all events and there shouldn't be any need for the special page label components anymore. > How will this fit in with the portal tools? I looked at that when it > was first submitted but I'm not using that code at all in my sites. The deployment stuff is "tool-less" - so, it's independent from the tools. Now we could build some tools on top of it, if required. The whole tools topic is currently not in my focus - I personally would like to have a cool portal for development and build the tools on top. > You might consider opening jira incidents as enhancement ideas where we > can bounce possible solutions around. > Yepp, I already started with adding one or two issues there. I'll try to add more. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Portal work
Giacomo Pati wrote: >>>Yeah, it would. I'm not sure why this is the case. I find the portal to be >>>a >>>great way to build any website, whether it needs the features of a portal or >>>not. > > > I think it's probably because of a steep learing curve without the > necessary documentation. So I appreciate Carstens statement "I'll start > to document around christmas (hopefully)" :-) > Note to myself: "Never announce such things in public places, people will remember it." :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: AuthenticationContextListener?
I haven't tried the technique you are using. I found it easier to create
an object with references to everything else my application needs and
store that in the session. The object then implements
HttpSessionBindingListener to detect that the session is being
destroyed. This does not require anything be added to web.xml. Since it
is your object being called I should think you'd have access to
everything you need without even going to the authentication context.
I'm not sure how to retrieve the authentication context manually. You
will have to read the code in the authentication framework block unless
someone can provide a code snippet.
Ralph
Stefan Pietschmann wrote:
I asked something similar in the users list some time ago but got no
response, so you’re my last chance ;)
As usual we’re storing information in the AuthenticationContext. So
far this information has been written on disk with every request
processed by the server.
Due to several reasons we’ve decided to just write it to a file
everytime the user logs out OR the session times out. Thus it is not
sufficient to add the method to the logout matcher, because the data
will be lost if the user just closes is browser.
I decided to use an HTTPSessionListener which I added to Cocoon’s
web.xml. This works fine so far, but it only allows me to retrieve the
user’s HTTPSession in the method sessionDestroyed(HttpSessionEvent
event). From there I can get the the ServletContext, but I see no way
to access the AuthenticationContext? Is it accessable at all? I tought
one of these should work, but both are null.
AuthenticationContext authContext =
(AuthenticationContext)session.getServletContext().getContext("authentication");
AuthenticationContext authContext2 =
(AuthenticationContext)session.getServletContext().getContext(AuthenticationConstants.SESSION_CONTEXT_NAME)
Cheers,
Stefan
Re: Core Documentation
You should create a component that implements the required Avalon interfaces and then declare it in cocoon.xconf. You will need to assign it a role (faily simple - look at other components to see how they do it). The code that uses the component then calls the component manager to look up the role and return the component attached to it. The manager will be initialized the first time it is looked up. What do you mean by "attributes". Transformers, etc. can have hardwired attributes associated with them when they are configured in the component section of the sitemap. In addition, they can have parameters declared in the pipelines which are passed as parameters to the setup method. Ralph Stefan Pietschmann wrote: Hello Cocooners, I’m desperately looking for Cocoon Core Documentation of any kind. I have – quite unsuccessfully – tried to get a clue from looking at the soure, but this whole sitemap processing seems quite complex. What I need to do – and I will bug you with this in detail for sure later – is in short: To setup a kind of manager object once the sitemap is read. Then any element in a pipeline – like transform, act etc – might have an additional attribute, which is to be evaluated by this manager. So I need to know: 1. where to instanciate the manager 2. where and how to get the attributes of the pipeline elements before they are appended to the ProcessingPipeline 3. and how to access the manager object from there For this any documentation or tips would be great… I read that Bertrand gave an introduction on the Cocoon internals at the CocoonGT2005. Are there any docs from there perhaps? Thanx alot, Stefan
AuthenticationContextListener?
I asked something similar in the users
list some time ago but got no response, so you’re my last chance ;)
As usual we’re storing information
in the AuthenticationContext. So far this information has been
written on disk with every request processed by the server.
Due to several reasons we’ve decided to just write it
to a file everytime the user logs out OR the session times out. Thus it is not
sufficient to add the method to the logout matcher, because the data will be
lost if the user just closes is browser.
I decided to use an HTTPSessionListener which I added to
Cocoon’s web.xml. This works fine so far, but it only allows me to
retrieve the user’s HTTPSession in the method sessionDestroyed(HttpSessionEvent
event). From there I can get the the ServletContext, but I see no way to access
the AuthenticationContext? Is it accessable at all? I tought one of these
should work, but both are null.
AuthenticationContext authContext = (AuthenticationContext)session.getServletContext().getContext("authentication");
AuthenticationContext authContext2 =
(AuthenticationContext)session.getServletContext().getContext(AuthenticationConstants.SESSION_CONTEXT_NAME)
Cheers,
Stefan
Re: [RT] A Cocoon installer with IzPack
Sylvain Wallez wrote: Joerg Heinicke wrote: Do you really want to add such an additional feature to 2.1 branch? If we already have one (like Ugo's Guilder) we shall go with that one. But I would not add anything new like an installer based on IzPack. Ok... IzPack has been under my radar for a long time as a cool thing, and its licence change to the ASL made me consider it would be worth mentioning it here. Now I certainly don't want to start a "my installer is better than yours" or "maven or nothing" debate. So forget it! Sylvain I disagree. This is a do-ocracy. If someone implements an installer we can evaluate whether it is any good or not. If they choose to use IzPack or Guilder or whatever that is their choice. Anything else would be a little bit like me telling you that you should use some Javscript library instead of Dojo. Ralph
Re: [RT] A Cocoon installer with IzPack
Upayavira wrote: It depends which version you are talking about 2.1 or 2.2. If we're talking 2.2, then yes, Maven will do a lot of it. If we're talking 2.1 then no, Maven won't do any. In fact, we already have some code in the whiteboard that can do the necessary dependency resolution with 2.1 blocks (see http://svn.apache.org/repos/asf/cocoon/whiteboard/guilder). With 2.1, the installer would need to do dependency resolution and a build - without this, it would be hardly worth having. So, the question to Sylvain would be: what version did you have in mind? Regards, Upayavira My 2 cents. While I believe we need to plan to release 2.1.9, post 2.1.8 we should not allow any new features to go into the 2.1 branch. We need to get 2.2M1 out fairly quickly and features like an installer should only go there. Ralph
Core Documentation
Hello Cocooners, I’m desperately looking for Cocoon Core Documentation of any kind. I have – quite unsuccessfully – tried to get a clue from looking at the soure, but this whole sitemap processing seems quite complex. What I need to do – and I will bug you with this in detail for sure later – is in short: To setup a kind of manager object once the sitemap is read. Then any element in a pipeline – like transform, act etc – might have an additional attribute, which is to be evaluated by this manager. So I need to know: where to instanciate the manager where and how to get the attributes of the pipeline elements before they are appended to the ProcessingPipeline and how to access the manager object from there For this any documentation or tips would be great… I read that Bertrand gave an introduction on the Cocoon internals at the CocoonGT2005. Are there any docs from there perhaps? Thanx alot, Stefan
Re: [cforms] - released in 2.1.8?
Max Pfingsthorn wrote: On 11/20/05 10:28 AM, "Antonio Gallardo" <[EMAIL PROTECTED]> wrote: ... About Dojo, one of the concerns is that it takes longer initializing on the client. Maybe it is just due the internet wire. Let me explain, seems like dojo use a load on demand scheme to load the required JS files, hence it connects back to the server and this takes time, making the initialization slower. A bug or a feature? Dunno Dojo has a "compressor" which is supposed to speed up javascript initialization. See [1]. Not sure if it takes care of making dynamic loads static, but that would be nice. In some way it does. Basically, the compressor works with a "profile", which contains a number or "dojo.require()" instructions (this loads JS code on-demand without
Re: Portal work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 19 Nov 2005, Ralph Goers wrote: Date: Sat, 19 Nov 2005 10:40:14 -0800 From: Ralph Goers <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Portal work Carsten Ziegeler wrote: It would be great if more than the two of us would be interested in the portal stuff. But I think we are very near to a cleanup version which I'll start to document around christmas (hopefully) and then others will hopefully join in. Yeah, it would. I'm not sure why this is the case. I find the portal to be a great way to build any website, whether it needs the features of a portal or not. I think it's probably because of a steep learing curve without the necessary documentation. So I appreciate Carstens statement "I'll start to document around christmas (hopefully)" :-) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgKWmLNdJvZjjVZARAj44AKCYwPZ29hCd6GOy1n//p1MFhN3NCACfbC0l lWmLkofXpMGNl7IHCwxfKt0= =ss0J -END PGP SIGNATURE-
Re: [RT] A Cocoon installer with IzPack
Joerg Heinicke wrote: On 20.11.2005 16:13, Upayavira wrote: What about using it to build a neat installer for Cocoon? Could it handle the dependency resolution bit? That's the callenging bit. We should keep installation and deployment separate. I have nothing against tools that unpack and install core cocoon into a specified dir, maybe even add desktop shortcuts for starting/stopping etc. Deployment however should be handled in a different tool, separate from the installer. I expect maven to handle most of the tricky stuff like the dependency resolution, we should just hand it a pom and off it goes. Same here. It depends which version you are talking about 2.1 or 2.2. If we're talking 2.2, then yes, Maven will do a lot of it. 2.2 of course. Nobody wants to maintain Maven stuff additionally for 2.1 I guess. If we're talking 2.1 then no, Maven won't do any. In fact, we already have some code in the whiteboard that can do the necessary dependency resolution with 2.1 blocks (see http://svn.apache.org/repos/asf/cocoon/whiteboard/guilder). With 2.1, the installer would need to do dependency resolution and a build - without this, it would be hardly worth having. Do you really want to add such an additional feature to 2.1 branch? If we already have one (like Ugo's Guilder) we shall go with that one. But I would not add anything new like an installer based on IzPack. Ok... IzPack has been under my radar for a long time as a cool thing, and its licence change to the ASL made me consider it would be worth mentioning it here. Now I certainly don't want to start a "my installer is better than yours" or "maven or nothing" debate. So forget it! Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [RT] A Cocoon installer with IzPack
On 20.11.2005 16:13, Upayavira wrote: What about using it to build a neat installer for Cocoon? Could it handle the dependency resolution bit? That's the callenging bit. We should keep installation and deployment separate. I have nothing against tools that unpack and install core cocoon into a specified dir, maybe even add desktop shortcuts for starting/stopping etc. Deployment however should be handled in a different tool, separate from the installer. I expect maven to handle most of the tricky stuff like the dependency resolution, we should just hand it a pom and off it goes. Same here. It depends which version you are talking about 2.1 or 2.2. If we're talking 2.2, then yes, Maven will do a lot of it. 2.2 of course. Nobody wants to maintain Maven stuff additionally for 2.1 I guess. If we're talking 2.1 then no, Maven won't do any. In fact, we already have some code in the whiteboard that can do the necessary dependency resolution with 2.1 blocks (see http://svn.apache.org/repos/asf/cocoon/whiteboard/guilder). With 2.1, the installer would need to do dependency resolution and a build - without this, it would be hardly worth having. Do you really want to add such an additional feature to 2.1 branch? If we already have one (like Ugo's Guilder) we shall go with that one. But I would not add anything new like an installer based on IzPack. Jörg
Re: [cforms] - released in 2.1.8?
On 11/20/05 10:28 AM, "Antonio Gallardo" <[EMAIL PROTECTED]> wrote: ... > > About Dojo, one of the concerns is that it takes longer initializing on > the client. Maybe it is just due the internet wire. Let me explain, > seems like dojo use a load on demand scheme to load the required JS > files, hence it connects back to the server and this takes time, making > the initialization slower. A bug or a feature? Dunno Dojo has a "compressor" which is supposed to speed up javascript initialization. See [1]. Not sure if it takes care of making dynamic loads static, but that would be nice. ... > Then the question is. How we will approach? > > A. Having our own AJAX code in cocoon > B. Using one of the AJAX frameworks outthere. > > I prefer to go for A. until the dust go out in the AJAX world. Seems > like every week is an annuncement of a new AJAX framework now! > But if B. is the way to go, then please share with us wich one is the > best for us. I would definitely go with B. Personally, I think maintaining such a library would just be way too much work. Seeing what sort of people work on Dojo, we probably can be sure that it will be around and maintained for a while. ... > -- 0 - > > Also, with the suggestion-list we can also create a new multivalue > widget rendering. One without an selection-list but with one > suggestion-list using AJAX. > Usecase: You need to define a group of 10 users from a list of 200+ > potential users. Is this too specialized or do you think it makes sense? I like the idea. You mean sort of by populating a list with entries from a suggestion-list? Bye! max [1] http://dojotoolkit.org/docs/compressor_system.html
Re: [RT] A Cocoon installer with IzPack
Jorg Heymans wrote: > Upayavira wrote: > > >>>What about using it to build a neat installer for Cocoon? >> >>Could it handle the dependency resolution bit? That's the callenging bit. >> > > > We should keep installation and deployment separate. > > I have nothing against tools that unpack and install core cocoon into a > specified dir, maybe even add desktop shortcuts for starting/stopping > etc. Deployment however should be handled in a different tool, separate > from the installer. > > I expect maven to handle most of the tricky stuff like the dependency > resolution, we should just hand it a pom and off it goes. It depends which version you are talking about 2.1 or 2.2. If we're talking 2.2, then yes, Maven will do a lot of it. If we're talking 2.1 then no, Maven won't do any. In fact, we already have some code in the whiteboard that can do the necessary dependency resolution with 2.1 blocks (see http://svn.apache.org/repos/asf/cocoon/whiteboard/guilder). With 2.1, the installer would need to do dependency resolution and a build - without this, it would be hardly worth having. So, the question to Sylvain would be: what version did you have in mind? Regards, Upayavira
Re: [RT] A Cocoon installer with IzPack
Upayavira wrote: >>What about using it to build a neat installer for Cocoon? > > Could it handle the dependency resolution bit? That's the callenging bit. > We should keep installation and deployment separate. I have nothing against tools that unpack and install core cocoon into a specified dir, maybe even add desktop shortcuts for starting/stopping etc. Deployment however should be handled in a different tool, separate from the installer. I expect maven to handle most of the tricky stuff like the dependency resolution, we should just hand it a pom and off it goes. Jorg
[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 55 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-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-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-20112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/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: 30 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/java/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-20112005.jar -Dbuild=build/cocoon-20112005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/work
[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 55 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-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-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-20112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-20112005/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: 30 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/java/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-20112005.jar -Dbuild=build/cocoon-20112005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/work
Re: [cforms] - released in 2.1.8?
Sylvain, thanks for replying! :-) I had been playing with some of the AJAX client-side frameworks suggested by you (scriptaculous and dojo) . I was looking the internals to learn how they works and looking for "what is cool", so we can "borrow" for cocoon. ;-) Scriptaculous is great, but I agree with your scriptaculous concerns. About Dojo, one of the concerns is that it takes longer initializing on the client. Maybe it is just due the internet wire. Let me explain, seems like dojo use a load on demand scheme to load the required JS files, hence it connects back to the server and this takes time, making the initialization slower. A bug or a feature? Dunno. Anyhow, I noted that this does not happens with the cute AJAX library currently distributed with cocoon. Also, the dojo samples seems to require javascript arrays back from the server. Maybe I am wrong and please correct me if this is the case. Dojo also seems to be on the same wave as your blog about JSON [1]. Then the question is. How we will approach? A. Having our own AJAX code in cocoon B. Using one of the AJAX frameworks outthere. I prefer to go for A. until the dust go out in the AJAX world. Seems like every week is an annuncement of a new AJAX framework now! But if B. is the way to go, then please share with us wich one is the best for us. Please see comments between lines Sylvain Wallez wrote: Antonio Gallardo wrote: Hi: Was the for cforms released in 2.1.8? I cannot find samples of it at cocoon.zones. The suggestion list was part of Sylvain's presentation in GT2005. At the same time, I am aware of the decision to drop scritpaculous support in cocoon. What is the status of all of this? The client-side stuff, based on Scriptaculous, was removed. The server-side stuff is still there, but needs more work: it currently based on selection-lists and filters the full list of options according to the user input, which doesn't scale for large datasets. We need a "fileterable" selection list for this purpose. Yep. Introduce a new parameter to define the max number of items the suggestion will send back to the client. For an initial version this should be enough. Later, in a 2nd version or so, we can also add a 2nd parameter to define how many rows need to be skipped in the beggining. This can helps us to display the "next 20 items". -- 0 - Also, with the suggestion-list we can also create a new multivalue widget rendering. One without an selection-list but with one suggestion-list using AJAX. Usecase: You need to define a group of 10 users from a list of 200+ potential users. Is this too specialized or do you think it makes sense? I will work on this in december for a project. Of course, this doesn't prevent other people to join! :-D I like to join the effort. I will need some guide. ;-) Best Regards, Antonio Gallardo [1] http://bluxte.net/blog/2005-11/17-49-57.html
Re: [cforms] - released in 2.1.8?
Antonio Gallardo wrote: Hi: Was the for cforms released in 2.1.8? I cannot find samples of it at cocoon.zones. The suggestion list was part of Sylvain's presentation in GT2005. At the same time, I am aware of the decision to drop scritpaculous support in cocoon. What is the status of all of this? The client-side stuff, based on Scriptaculous, was removed. The server-side stuff is still there, but needs more work: it currently based on selection-lists and filters the full list of options according to the user input, which doesn't scale for large datasets. We need a "fileterable" selection list for this purpose. I will work on this in december for a project. Of course, this doesn't prevent other people to join! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
