Re: [VOTE] Release 2.1.9
Giacomo Pati wrote:
Now, the only way I see ATM is to extend the Ant-script for the
repository block to download that jcr.jar from the Day site and put it
to the correct location for deployment/build (this is meant for the
branch).
That solves the problem technically but if the user doesn't even notice that a
library with some not-ASF-acknowledged license is installed I wonder what's the
difference ... (I know that the situation isn't better with Maven, maybe even
worse as it isn't possible to extend the download mechanism by some interstitial
that informs the user of what is happening. Well, I think we need a ASF-wide
solution here, best some mechanism that is integrated into Maven 2)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 23 February 12:02 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2006-02-23 12:02:06 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy check-plugin: [echo] org.apache.forrest.plugin.input.Daisy is not available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Sat Feb 11 07:07:04 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Sat Feb 11 08:07:06 GMT+00:00 2006 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. fetch-plugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl findPlugin: [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-versioned-plugin: fetch-unversioned-plugin: [echo] Versioned plugin unavailable, trying to get versionless plugin... [echo] Looking in local plugins src... [echo] Unable to find plugin src in main plugins src dir. [echo] Looking in local whiteboard plugins src... [copy] Copying 23 files to /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy [copy] Copied 10 empty directories to 1 empty directory under /export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy final-check: fetchplugin: unpack-plugin: install-plugin: configure-plugin: configure-input-plugin: [echo] Mounting input plugin: org.apache.forrest.plugin.input.Daisy [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/input.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.
Re: [VOTE] Release 2.1.9
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Feb 2006, Upayavira wrote: Date: Wed, 22 Feb 2006 06:49:39 -0800 From: Upayavira <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [VOTE] Release 2.1.9 Ralph Goers wrote: Carsten Ziegeler wrote: > Sylvain Wallez wrote: > > > > I believe the alternatives that were mentioned were to either get > > > the OK from legal or not deliver the jcr block as part of the > > > release. If the answer above means you don't feel we have > > > permission than the release should go out without JCR. > > > > > The API can be redistributed with an implementation, and we do > > redistribute the implementation. Does this give use the permission to > > redistribute the API with the implementation? IANAL and I don't > > know... > > > > > Ok, so how do we solve this issue? I understand the comment from Roy > that we are not allowed to ship the jar right now. I personally would go > the easiest way: remove the jcr api from the repo, disable the block by > default, add a readme that people have to download the jar and put it > into local libs to build the block. My understanding from Roy is that, if we ship Jackrabbit, we don't need the JCR jar, as Jackrabbit provides its own impl. Does it still work if you just remove the JCR jar? Or did I misunderstand something? No, this is not correct. The jackrabbit-jar is only an implementation of the JCR APIs. Rereading Roys mail: "The JCR API, in contrast, will either already be present in the J2SE engine (with or without an implementation) or must be downloaded and installed by the user." IMO for Cocoon this means that our users needs to get/have the jcr.jar by themself, either donwloading it by hand from the SUN/Day site and install it as an Java extension or other mechanism (i.e. global lib dir of a target container) or use a scritp (read Maven) to get it. Now, the only way I see ATM is to extend the Ant-script for the repository block to download that jcr.jar from the Day site and put it to the correct location for deployment/build (this is meant for the branch). Or add some mock classes in our base code. Se far, we have been doing it for mail.jar and other jars that we don't distribute due legal reasons. Best Regards, Antonio Gallardo. - -- 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.1 (GNU/Linux) iD8DBQFD/OdrLNdJvZjjVZARAn5CAJsH4ZCDaP5JfuXlM8Bj/ad7XP6VsQCgpQzc HgGFORsS8vlrf9/PTxzRBfg= =cCJL -END PGP SIGNATURE-
Re: [VOTE] Release 2.1.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Feb 2006, Upayavira wrote: Date: Wed, 22 Feb 2006 06:49:39 -0800 From: Upayavira <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [VOTE] Release 2.1.9 Ralph Goers wrote: Carsten Ziegeler wrote: > Sylvain Wallez wrote: > > > > I believe the alternatives that were mentioned were to either get > > > the OK from legal or not deliver the jcr block as part of the > > > release. If the answer above means you don't feel we have > > > permission than the release should go out without JCR. > > > > > The API can be redistributed with an implementation, and we do > > redistribute the implementation. Does this give use the permission to > > redistribute the API with the implementation? IANAL and I don't > > know... > > > > > Ok, so how do we solve this issue? I understand the comment from Roy > that we are not allowed to ship the jar right now. I personally would go > the easiest way: remove the jcr api from the repo, disable the block by > default, add a readme that people have to download the jar and put it > into local libs to build the block. My understanding from Roy is that, if we ship Jackrabbit, we don't need the JCR jar, as Jackrabbit provides its own impl. Does it still work if you just remove the JCR jar? Or did I misunderstand something? No, this is not correct. The jackrabbit-jar is only an implementation of the JCR APIs. Rereading Roys mail: "The JCR API, in contrast, will either already be present in the J2SE engine (with or without an implementation) or must be downloaded and installed by the user." IMO for Cocoon this means that our users needs to get/have the jcr.jar by themself, either donwloading it by hand from the SUN/Day site and install it as an Java extension or other mechanism (i.e. global lib dir of a target container) or use a scritp (read Maven) to get it. Now, the only way I see ATM is to extend the Ant-script for the repository block to download that jcr.jar from the Day site and put it to the correct location for deployment/build (this is meant for the branch). - -- 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.1 (GNU/Linux) iD8DBQFD/OdrLNdJvZjjVZARAn5CAJsH4ZCDaP5JfuXlM8Bj/ad7XP6VsQCgpQzc HgGFORsS8vlrf9/PTxzRBfg= =cCJL -END PGP SIGNATURE-
[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367363 ] Philippe Gassmann commented on COCOON-1780: --- Sylvain has just explained to me the purpose of "submit widgets" . Now I realized that my point of view was wrong, so ok, your solution seems good ! > [PATCH] Upload Widget : Can not change selected file > > > Key: COCOON-1780 > URL: http://issues.apache.org/jira/browse/COCOON-1780 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: vincent Demay > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > > When a file is selected with the upload widget and a on-value-change event is > fired, the value of the widget can not be changed by user. > here is the patch > Index: > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(revision 377974) > +++ > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(working copy) > @@ -486,7 +486,7 @@ > [ > > ] > - > + > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367361 ] Bruno Dumon commented on COCOON-1780: - > If you want to use an image as a button, you can use an > it works fine ! Well yes, but try to combine an image and text in one button then. Just kidding, it's not that this is important to me, but why artifically limit it to form controls that leave a request parameter? This could as suggeted by Vincent also be done by just checking: fullId.equals(request.getParameter(Form.SUBMIT_ID_PARAMETER) but then I don't see why not to set the submit widget while we're at it? It just seems a little nicer to me to set it at the beginning and then later do the "form.getSubmitWidget() == this" test, which better explains what we're testing. > I think that the Upload widget is a totally different kind of widget than an > action or a submit widget (that is an action ;) ). You do not want to submit > the form nor doing a custom action, you just want the upload widget to delete > its uploaded file. So I do not understand the need to set the form submit id > in this widget. But it *is* the submit widget, and it will be set as submit widget anyway, just a little bit later (after the readFromRequest processing). Anyhow, adjust it as you feel appropriate. I'll already be happy if it works :-) > [PATCH] Upload Widget : Can not change selected file > > > Key: COCOON-1780 > URL: http://issues.apache.org/jira/browse/COCOON-1780 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: vincent Demay > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > > When a file is selected with the upload widget and a on-value-change event is > fired, the value of the widget can not be changed by user. > here is the patch > Index: > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(revision 377974) > +++ > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(working copy) > @@ -486,7 +486,7 @@ > [ > > ] > - > + > > > -- 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: [VOTE] Release 2.1.9
Sylvain Wallez wrote: >>And does the new jxtemplate generator implement? >> >> >> > >Sorry, implement what? > > I think Roy is refers to the requested backport of the new jxtemplate implementation from 2.2. Best Regards, Antonio Gallardo.
[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367355 ] Philippe Gassmann commented on COCOON-1780: --- If you want to use an image as a button, you can use an it works fine ! I think that the Upload widget is a totally different kind of widget than an action or a submit widget (that is an action ;) ). You do not want to submit the form nor doing a custom action, you just want the upload widget to delete its uploaded file. So I do not understand the need to set the form submit id in this widget. > [PATCH] Upload Widget : Can not change selected file > > > Key: COCOON-1780 > URL: http://issues.apache.org/jira/browse/COCOON-1780 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: vincent Demay > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > > When a file is selected with the upload widget and a on-value-change event is > fired, the value of the widget can not be changed by user. > here is the patch > Index: > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(revision 377974) > +++ > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(working copy) > @@ -486,7 +486,7 @@ > [ > > ] > - > + > > > -- 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: [VOTE] Release 2.1.9
Carsten Ziegeler wrote: Ok, so how do we solve this issue? I understand the comment from Roy that we are not allowed to ship the jar right now. I personally would go the easiest way: remove the jcr api from the repo, disable the block by default, add a readme that people have to download the jar and put it into local libs to build the block. Sounds like an interesting way to solve the situation! Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [VOTE] Release 2.1.9
Ralph Goers wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: I believe the alternatives that were mentioned were to either get the OK from legal or not deliver the jcr block as part of the release. If the answer above means you don't feel we have permission than the release should go out without JCR. The API can be redistributed with an implementation, and we do redistribute the implementation. Does this give use the permission to redistribute the API with the implementation? IANAL and I don't know... Ok, so how do we solve this issue? I understand the comment from Roy that we are not allowed to ship the jar right now. I personally would go the easiest way: remove the jcr api from the repo, disable the block by default, add a readme that people have to download the jar and put it into local libs to build the block. My understanding from Roy is that, if we ship Jackrabbit, we don't need the JCR jar, as Jackrabbit provides its own impl. Does it still work if you just remove the JCR jar? Or did I misunderstand something? Upayavira
Re: [VOTE] Release 2.1.9
Carsten Ziegeler wrote: Sylvain Wallez wrote: I believe the alternatives that were mentioned were to either get the OK from legal or not deliver the jcr block as part of the release. If the answer above means you don't feel we have permission than the release should go out without JCR. The API can be redistributed with an implementation, and we do redistribute the implementation. Does this give use the permission to redistribute the API with the implementation? IANAL and I don't know... Ok, so how do we solve this issue? I understand the comment from Roy that we are not allowed to ship the jar right now. I personally would go the easiest way: remove the jcr api from the repo, disable the block by default, add a readme that people have to download the jar and put it into local libs to build the block. +1 Ralph
[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367344 ] Bruno Dumon commented on COCOON-1780: - Hi Vincent, It's not really useless code, since it allows more flexibility in rendering. For example, it would allow to use the HTML tag, allowing to put an image on the button. The way I've fixed the Upload widget follows the same pattern as the other widgets do, such as Action. In fact, I looked a bit too much at the Action widget and that's why I got it wrong the first time. > [PATCH] Upload Widget : Can not change selected file > > > Key: COCOON-1780 > URL: http://issues.apache.org/jira/browse/COCOON-1780 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: vincent Demay > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > > When a file is selected with the upload widget and a on-value-change event is > fired, the value of the widget can not be changed by user. > here is the patch > Index: > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(revision 377974) > +++ > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(working copy) > @@ -486,7 +486,7 @@ > [ > > ] > - > + > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[
http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367339
]
vincent Demay commented on COCOON-1780:
---
What do you think of doing something like that to keep your idea (in order to
avoid useless code):
Index:
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Upload.java
===
---
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Upload.java
(revision 379761)
+++
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Upload.java
(working copy)
@@ -105,11 +105,6 @@
Object obj = request.get(fullId);
-if (fullId.equals(request.getParameter(Form.SUBMIT_ID_PARAMETER))) {
- form.setSubmitWidget(this);
-}
-
-
// If the request object is a Part, keep it
if (obj instanceof Part) {
Part requestPart = (Part)obj;
@@ -129,7 +124,7 @@
// If it's not a part and not null, clear any existing value
// We also check if we're the submit widget, as a result of clicking
the "..." button
-} else if (obj != null || form.getSubmitWidget() == this){
+} else if (obj != null ||
fullId.equals(request.getParameter(Form.SUBMIT_ID_PARAMETER))){
// Clear the part, if any
if (this.part != null) {
this.part.dispose();
or, and I think it's better because, replace the button by a submit and remove
the useless condition as in the following patch
Index:
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Upload.java
===
---
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Upload.java
(revision 379761)
+++
/cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Upload.java
(working copy)
@@ -105,11 +105,6 @@
Object obj = request.get(fullId);
-if (fullId.equals(request.getParameter(Form.SUBMIT_ID_PARAMETER))) {
- form.setSubmitWidget(this);
-}
-
-
// If the request object is a Part, keep it
if (obj instanceof Part) {
Part requestPart = (Part)obj;
@@ -129,7 +124,7 @@
// If it's not a part and not null, clear any existing value
// We also check if we're the submit widget, as a result of clicking
the "..." button
-} else if (obj != null || form.getSubmitWidget() == this){
+} else if (obj != null){
// Clear the part, if any
if (this.part != null) {
this.part.dispose();
> [PATCH] Upload Widget : Can not change selected file
>
>
> Key: COCOON-1780
> URL: http://issues.apache.org/jira/browse/COCOON-1780
> Project: Cocoon
> Type: Bug
> Components: Blocks: Forms
> Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
> Reporter: vincent Demay
> Assignee: Jean-Baptiste Quenot
> Fix For: 2.1.9-dev (current SVN)
>
> When a file is selected with the upload widget and a on-value-change event is
> fired, the value of the widget can not be changed by user.
> here is the patch
> Index:
> /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
> ===
> ---
> /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
>(revision 377974)
> +++
> /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
>(working copy)
> @@ -486,7 +486,7 @@
> [
>
> ]
> -
> +
>
>
>
--
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: [VOTE] Release 2.1.9
Ralph Goers wrote: The forms block is now marked stable. I believe legal has given the OK for us to use the JCR api. To the best of my recollection I believe those were the only two items standing in the way of a 2.1.9 release. So please vote. +1 Vadim
Re: [VOTE] Release 2.1.9
Le 22 févr. 06 à 10:26, Carsten Ziegeler a écrit : ...I personally would go the easiest way: remove the jcr api from the repo, disable the block by default, add a readme that people have to download the jar and put it into local libs to build the block. Sounds good to me. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Forms broken on IE
Hi,
With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
This happens whenever I click somewhere on the page (doesn't matter
where: in a blank area or an input field).
The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
variable is undefined:
onMouseUp: function(e){
this.mouseDownX = null;
this.mouseDownY = null;
this._dragTriggered = false;
var _this = this;
e.preventDefault(); <=== e undefined
Maybe some of you who follow up dojo development know if this is already
fixed or if the problem is caused by us.
TIA
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367334 ] Bruno Dumon commented on COCOON-1780: - good you noticed, it's fixed now, I hope. > [PATCH] Upload Widget : Can not change selected file > > > Key: COCOON-1780 > URL: http://issues.apache.org/jira/browse/COCOON-1780 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: vincent Demay > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > > When a file is selected with the upload widget and a on-value-change event is > fired, the value of the widget can not be changed by user. > here is the patch > Index: > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(revision 377974) > +++ > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(working copy) > @@ -486,7 +486,7 @@ > [ > > ] > - > + > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=all ] vincent Demay reopened COCOON-1780: --- I tried you patch on a form with a on-value-changed listener on upload and it works. but when there isn't any on-value-change-listener and you submit the form with another input type="submit" the fallowing error occurs java.lang.IllegalStateException: Submit widget already set to Upload 'upload'. Cannot set also Submit 'ok' I think it's because we set the submit-id with the upload and after we set it again. > [PATCH] Upload Widget : Can not change selected file > > > Key: COCOON-1780 > URL: http://issues.apache.org/jira/browse/COCOON-1780 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: vincent Demay > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > > When a file is selected with the upload widget and a on-value-change event is > fired, the value of the widget can not be changed by user. > here is the patch > Index: > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(revision 377974) > +++ > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(working copy) > @@ -486,7 +486,7 @@ > [ > > ] > - > + > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1659) Finish the sitemap internals document in Daisy
[ http://issues.apache.org/jira/browse/COCOON-1659?page=all ] Helma van der Linden updated COCOON-1659: - Attachment: svgs-of-article.zip The zip includes the original SVG files that are used to generate the pictures used in the document. > Finish the sitemap internals document in Daisy > -- > > Key: COCOON-1659 > URL: http://issues.apache.org/jira/browse/COCOON-1659 > Project: Cocoon > Type: Task > Components: - Documentation > Versions: 2.2-dev (Current SVN) > Reporter: Helma van der Linden > Assignee: Helma van der Linden > Priority: Minor > Attachments: svgs-of-article.zip > > Text and images of the description of the sitemap processing should be > enhanced and reviewed. > http://cocoon.zones.apache.org/daisy/documentation/732.html > - integrate related wiki pages: > http://wiki.apache.org/cocoon/InterpretedSitemapInternals > http://wiki.apache.org/cocoon/GT2005HackatonDay1Notes > - Review of the content by sitemap experts (Sylvain?) > - Create better images (see also pages on wiki page) > - add links to appropriate classes into apidocs -- 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: [VOTE] Release 2.1.9
Sylvain Wallez wrote: >>> Although we can solve this issue in 2.2 with Maven, can we consider >>> that we redistribute the JCR API as part of our redistribution of >>> Jackrabbit? >> I believe the alternatives that were mentioned were to either get the >> OK from legal or not deliver the jcr block as part of the release. If >> the answer above means you don't feel we have permission than the >> release should go out without JCR. > > The API can be redistributed with an implementation, and we do > redistribute the implementation. Does this give use the permission to > redistribute the API with the implementation? IANAL and I don't know... > Ok, so how do we solve this issue? I understand the comment from Roy that we are not allowed to ship the jar right now. I personally would go the easiest way: remove the jcr api from the repo, disable the block by default, add a readme that people have to download the jar and put it into local libs to build the block. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367320 ] Bruno Dumon commented on COCOON-1780: - @vincent: I don't think there's a problem with that, but since it worked with 'button' before, the real cause of the bug had to be something else. > [PATCH] Upload Widget : Can not change selected file > > > Key: COCOON-1780 > URL: http://issues.apache.org/jira/browse/COCOON-1780 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: vincent Demay > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > > When a file is selected with the upload widget and a on-value-change event is > fired, the value of the widget can not be changed by user. > here is the patch > Index: > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(revision 377974) > +++ > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(working copy) > @@ -486,7 +486,7 @@ > [ > > ] > - > + > > > -- 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: [VOTE] Release 2.1.9
roy huang wrote: > The Form Block now in trunk seems has problems because the change of ajax > block. > Yep. Unfortunately, I currently lack time to investigate the maven build in trunk. > And does the new jxtemplate generator implement? > Sorry, implement what? Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file
[ http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367318 ] vincent Demay commented on COCOON-1780: --- Thanks for the patch, it's working properly now. I just have a question, what was the problem with replacing button in submit? > [PATCH] Upload Widget : Can not change selected file > > > Key: COCOON-1780 > URL: http://issues.apache.org/jira/browse/COCOON-1780 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) > Reporter: vincent Demay > Assignee: Jean-Baptiste Quenot > Fix For: 2.1.9-dev (current SVN) > > When a file is selected with the upload widget and a on-value-change event is > fired, the value of the widget can not be changed by user. > here is the patch > Index: > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(revision 377974) > +++ > /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl >(working copy) > @@ -486,7 +486,7 @@ > [ > > ] > - > + > > > -- 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
