Re: svn commit: r415374 - /cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
Antonio Gallardo wrote:
With all due respect: I don't think this is the best way to have a
better 2.2.
I don't have the time to fix the bug myself. I filled a bug report. Sorry, I
can't be more helpful ATM.
--
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
[jira] Created: (COCOON-1866) jx:comment doesn't work
jx:comment doesn't work --- Key: COCOON-1866 URL: http://issues.apache.org/jira/browse/COCOON-1866 Project: Cocoon Type: Bug Components: Blocks: Templating Reporter: Reinhard Poetz Fix For: 2.2-dev (Current SVN) jx:comment produces following stack trace in trunk: java.lang.ArrayIndexOutOfBoundsException: -1 at org.apache.xalan.serialize.SerializerToXML.comment(SerializerToXML.java:1298) at org.apache.xalan.transformer.TransformerIdentityImpl.comment(TransformerIdentityImpl.java:1272) at org.apache.cocoon.xml.AbstractXMLPipe.comment(AbstractXMLPipe.java:228) at org.apache.cocoon.xml.AbstractXMLPipe.comment(AbstractXMLPipe.java:228) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.cocoon.core.container.spring.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:340) at $Proxy5.comment(Unknown Source) at org.apache.xalan.transformer.ResultTreeHandler.comment(ResultTreeHandler.java:624) at org.apache.xpath.objects.XString.dispatchAsComment(XString.java:329) at org.apache.xalan.transformer.ClonerToResultTree.cloneToResultTree(ClonerToResultTree.java:248) at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:155) at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:425) at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:216) at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:425) at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:216) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2339) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:710) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2339) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:710) at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:425) at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:216) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2339) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2160) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1213) at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3372) at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:433) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:54) at org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:577) -- 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
jx:comment doesn't work
[EMAIL PROTECTED] wrote:
Author: reinhard
Date: Mon Jun 19 10:07:38 2006
New Revision: 415374
URL: http://svn.apache.org/viewvc?rev=415374&view=rev
Log:
jx:comment doesn't work
Modified:
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
Modified:
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
URL:
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml?rev=415374&r1=415373&r2=415374&view=diff
==
---
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
(original)
+++
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
Mon Jun 19 10:07:38 2006
@@ -28,13 +28,13 @@
|ie: This expresion don't break the Generator:
#{$.[4.]$..cocoon/continuation/id}">
+-->
-
+
Enter value of a:
In the template block jx:comment doesn't work. I guess that it produces invalid
XML. I created a JIRA issue (COCOON-1866) that also shows the stacktrace.
I commented the usuage of this tag because the it isn't the main purpose of this
sample to demonstrate jx:comment.
--
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
Re: svn commit: r415374 - /cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
[EMAIL PROTECTED] escribió:
Author: reinhard
Date: Mon Jun 19 10:07:38 2006
New Revision: 415374
URL: http://svn.apache.org/viewvc?rev=415374&view=rev
Log:
jx:comment doesn't work
Modified:
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
Modified:
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
URL:
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml?rev=415374&r1=415373&r2=415374&view=diff
==
---
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
(original)
+++
cocoon/trunk/blocks/cocoon-core-samples-main/cocoon-core-samples-main-sample/src/main/resources/COB-INF/flow/jxcalc/screens/getNumberA.xml
Mon Jun 19 10:07:38 2006
@@ -28,13 +28,13 @@
|ie: This expresion don't break the Generator:
#{$.[4.]$..cocoon/continuation/id}">
+-->
-
+
Enter value of a:
With all due respect: I don't think this is the best way to have a
better 2.2.
Best Regards,
Antonio Gallardo.
[jira] Commented: (COCOON-1858) [PATCH]on-value-change does not work on suggestion list
[
http://issues.apache.org/jira/browse/COCOON-1858?page=comments#action_12416796
]
Antonio Gallardo commented on COCOON-1858:
--
http://trac.dojotoolkit.org/ticket/897 was closed as invalid. Is there another
suggestion to fix this issue?
In cocoon zones, the suggestion does not work at all:
http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-suggest.flow
> [PATCH]on-value-change does not work on suggestion list
> ---
>
> Key: COCOON-1858
> URL: http://issues.apache.org/jira/browse/COCOON-1858
> Project: Cocoon
> Type: Bug
> Components: Blocks: Forms
> Versions: 2.1.9
> Reporter: vincent Demay
> Attachments: ComboBox.js, ComboBox.js
>
> on-value-change does not work on suggestion list : there are to issues :
> 1 - submit on change is not setted on the widget in
> form-advanced-field-styling.xsl :
> Here is the patch :
> --- sample/forms-advanced-field-styling.xsl 2006-06-07 14:51:27.809216500
> +0
> 200
> +++ sample/forms-advanced-field-styling.new.xsl 2006-06-07 14:52:04.293358000
> +0
> 200
> @@ -272,6 +272,7 @@
>
>
> value="{fi:value}" dojoType="CFormsSuggest">
> +
>
> select="fi:suggestion"/>
>
> 2 - dojo Widget does not support onchange (see bug :
> http://trac.dojotoolkit.org/ticket/897)
> So I change the dojo file src/widget/html/ComboBox.js
> The new file is in Attachement (and patch in dojo tracker)
--
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: Compatiblity problem in template block
Leszek Gawron wrote > > Was this ever intended? Don't know :) > >> As we have removed the deprecated stuff in the template block and in >> 2.2, there is no way to access the Parameters object anymore. As a >> properties object does not allow to iterate over the stored properties, >> there is no way to simply list all parameters (which makes the samples >> fail). >> Because of compatibility I think we can not simply change this code and >> store the Parameters object under "cocoon.parameters" (although this >> would make most sense to me). So perhaps using something more verbose >> like "cocoon.sitemap-parameters" could be used instead? > > This looks more like a hack then a solution. Couldn't we stay with > Parameters object but provide some additional helper methods that would > simplify the usage and made it more similar to using Properties object? > Sounds good to me: +1 Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Compatiblity problem in template block
Carsten Ziegeler wrote: After some searching I found out why the samples in 2.2 do not work anymore. It's an problem caused by removing deprecated stuff in 2.2. In 2.1.x with JXTG (not template block!), you can directory refer to "request", "response" and "parameters" in your template. We deprecated this in favour of always using the prefix "cocoon.". Unfortunately when we introduced "cocoon.parameters" we did not store the Parameters object but convert the Parameters object into a Properties object. So in 2.1.x accessing "parameters" returns a Parameters object while accessing "cocoon.parameters" returns a Properties object. Was this ever intended? As we have removed the deprecated stuff in the template block and in 2.2, there is no way to access the Parameters object anymore. As a properties object does not allow to iterate over the stored properties, there is no way to simply list all parameters (which makes the samples fail). Because of compatibility I think we can not simply change this code and store the Parameters object under "cocoon.parameters" (although this would make most sense to me). So perhaps using something more verbose like "cocoon.sitemap-parameters" could be used instead? This looks more like a hack then a solution. Couldn't we stay with Parameters object but provide some additional helper methods that would simplify the usage and made it more similar to using Properties object? -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Incorrect EHDefaultStore behavior when overflow-to-disk is false
Hi Ard, In 2.1.10-dev and 2.2-dev we've already updated to ehcache 1.2. Few weeks ago there were some changes to the ehcache implementation. I don't recall exactly what it was. Anyhow, please use the latest svn version for your patch. I will be waiting for your patch in jira to upload it patch ASAP. Many thanks in advance. Best Regards, Antonio Gallardo. Ard Schrijvers escribió: Currently, the EHDefaultStore can be configured to have overflow-to-disk=false. Since "diskPersistent" is not configurable, and always "true", disposing the cache results in a spoolToDisk error (ofcourse it is on schutting down the VM, so not to serious a problem). I changed the EHDefaultStore impl to have diskPersistent configurable (default true when overflow-to-disk=true). I will send a patch. Furhtermore, I read about ehcache-1.2 version that is has a large performance increase for DiskStore performance (up to 7 fold they say (1)). I tested the 1.2 version, and everything seems to be working fine. What do you think about upgrading the 1.1 version in lib/core to 1.2 for the ehcache. (1) http://sourceforge.net/project/shownotes.php?release_id=392051&group_id=93232 Regards Ard
Re: Time based release cylces
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Carsten Ziegeler wrote:
Ralph Goers wrote:
I have no problem with this release as a first step, but I'd
hesitate to even call it 2.2M1. OTOH, if I had an idea of what our
subsequent milestones are this might make more sense to me.
Good point! Now, if you something label milestone or beta people have a
specific expectation. I don't think we meet these expectations, so I
would suggest calling this release alpha.
Before we decide what we call the releases exactly I want to draw our
attention to a decision we made long time ago. We agreed that we want
to change to time-based release cycles instead of the feature-driven
releases we had up to now which wasn't helpful in becoming more agile.
Taking this into consideration I think we can stick with giving our
releases the "milestone" postfix. The name "milestone" only says that
another period of development is over ("time-boxing").
We only need to decide how long the periods between releases should
be. I guess this will highly depend on the module. The most important
modules (e.g. cocoon-core, cocoon-forms, cocoon-template,
cocoon-javaflow, the archetypes, the deployment plugin) should be
released every 4 weeks, other modules every 3 months and there will be
modules that will only be released if required. Additionally we should
coordinate the release cycles so that at least twice a year, we
release everything at the same time (IIUC the Eclipse project wants to
make this happen for their universe with the "Callisto" initiative).
+1
I would however suggest that we follow the example from Eclipse and have
a milestone release every 6:th week instead of every 4:th. Considering
that we probably want to discourage large changes and encourage testing
the week before each release it gives us the possibility to develop 5/6
of the time instead of 3/4.
I don't have a strong opinion on the length of the period as long as we don't
count in years ;-)
so yes, every 6th week is fine for me.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Please review changes to WildcardHelper
Giacomo Pati wrote: > How about using the Ant code (as the Wildcard syntax was borrowed from > it)? Either using the Ant code directly (introducing a runtime > dependency to Ant) or copy the code? > > As we use spring now, now about the class > org.springframework.util.AntPathMatcher? > Yes, I thought about using the Ant code as well - do you know which class it is? Now, I think we can't directly use existing code, but have to copy it as we need to know whether a uri matches *and* if it matches we need to know the current values for the placeholders. At least the spring code does not provide this information. I think I will copy the code from one of those projects and use that as a base. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: [CForms] Tree widget based on XML document
Bruno Dumon [mailto:[EMAIL PROTECTED] wrote: > On Sun, 2006-06-18 at 11:03 +0200, Bruno Dumon wrote: > > On Thu, 2006-06-15 at 23:49 +0200, Fred Vos wrote: > > > > Another > > > thing that is necessary is the possibility to add > key-value pairs to every > > > folder and node, available in the form template. To > create a directory tree > > > with directories and files, showing filename, size, date > et cetera, then > > > requires the use of a directory generator and > transforming its output to an > > > xml document that can be used in the tree widget. > > > > I don't think the current tree model implementation forbids > to add such > > key-value pairs (or any sort of attribute) to your own tree node > > implementation. It might of course be considered to make this a > > standarized concept. > > I didn't think of this before, but the example you have given is > perfectly possible with the SourceTreeModel today, without any work at > all (no pipelines to set up, no XSL to write, and in addition branches > are only loaded on demand and file name filtering is > possible). So from > a user POV, using the specific SourceTreeModel really is > easier in this case. I understand this was just an example though. I think it was an example to show that an XMLTreeModel can be used as a SourceTreeModel, but not the other way around. In any case, I need a tree widget that can take its input from a cocoon pipeline. At the moment I'm using Fred's (or trying to, so far), but getting rid of that Xom dependency would be very nice indeed. mcv.
Re: Time based release cylces
Reinhard Poetz skrev:
Carsten Ziegeler wrote:
Ralph Goers wrote:
I have no problem with this release as a first step, but I'd
hesitate to even call it 2.2M1. OTOH, if I had an idea of what our
subsequent milestones are this might make more sense to me.
Good point! Now, if you something label milestone or beta people have a
specific expectation. I don't think we meet these expectations, so I
would suggest calling this release alpha.
Before we decide what we call the releases exactly I want to draw our
attention to a decision we made long time ago. We agreed that we want
to change to time-based release cycles instead of the feature-driven
releases we had up to now which wasn't helpful in becoming more agile.
Taking this into consideration I think we can stick with giving our
releases the "milestone" postfix. The name "milestone" only says that
another period of development is over ("time-boxing").
We only need to decide how long the periods between releases should
be. I guess this will highly depend on the module. The most important
modules (e.g. cocoon-core, cocoon-forms, cocoon-template,
cocoon-javaflow, the archetypes, the deployment plugin) should be
released every 4 weeks, other modules every 3 months and there will be
modules that will only be released if required. Additionally we should
coordinate the release cycles so that at least twice a year, we
release everything at the same time (IIUC the Eclipse project wants to
make this happen for their universe with the "Callisto" initiative).
+1
I would however suggest that we follow the example from Eclipse and have
a milestone release every 6:th week instead of every 4:th. Considering
that we probably want to discourage large changes and encourage testing
the week before each release it gives us the possibility to develop 5/6
of the time instead of 3/4.
/Daniel
Re: [Vote] New committers
Joerg Heinicke skrev: Hello, I'd like to introduce some people of our community and invite them for becoming committers of the Cocoon project. Three people do I have in mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston. +3 /Daniel
Re: Please review changes to WildcardHelper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Jun 2006, Giacomo Pati wrote: Date: Mon, 19 Jun 2006 17:15:14 +0200 (CEST) From: Giacomo Pati <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Please review changes to WildcardHelper --[PinePGP]--[begin]-- On Mon, 19 Jun 2006, Carsten Ziegeler wrote: Date: Mon, 19 Jun 2006 15:51:04 +0200 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Please review changes to WildcardHelper Andreas Hartmann wrote: > > > > > > > > > > > > > > > > > > After the change, this matches all URLs ending with a slash, > > > even ones containing slashes. This is not intended, is it? > > > > > No, it's definitly not. This is a bug, I'll add your test case. > > OK, thanks a lot! > Ok, I fixed this one, but I'm getting more and more unhappy with the code; perhaps a clean rewrite would help... How about using the Ant code (as the Wildcard syntax was borrowed from it)? Either using the Ant code directly (introducing a runtime dependency to Ant) or copy the code? As we use spring now, now about the class org.springframework.util.AntPathMatcher? -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com --[PinePGP]--- gpg: Signature made Mon Jun 19 17:15:19 2006 CEST using DSA key ID 98E35590 gpg: Good signature from "Giacomo Pati <[EMAIL PROTECTED]>" gpg: aka "Giacomo Pati <[EMAIL PROTECTED]>" gpg: aka "Giacomo Pati <[EMAIL PROTECTED]>" --[PinePGP][end]-- - -- 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.3 (GNU/Linux) iD8DBQFElsE1LNdJvZjjVZARAgZ5AKDF+GNi29k0JYnQbl1Mr1tCmkL88wCgvnTJ xmKgMZDiKZTrNjQ66Lho8Vc= =/Azf -END PGP SIGNATURE-
Re: Please review changes to WildcardHelper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Jun 2006, Carsten Ziegeler wrote: Date: Mon, 19 Jun 2006 15:51:04 +0200 From: Carsten Ziegeler <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Please review changes to WildcardHelper Andreas Hartmann wrote: After the change, this matches all URLs ending with a slash, even ones containing slashes. This is not intended, is it? No, it's definitly not. This is a bug, I'll add your test case. OK, thanks a lot! Ok, I fixed this one, but I'm getting more and more unhappy with the code; perhaps a clean rewrite would help... How about using the Ant code (as the Wildcard syntax was borrowed from it)? Either using the Ant code directly (introducing a runtime dependency to Ant) or copy the code? - -- 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.3 (GNU/Linux) iD8DBQFElr+HLNdJvZjjVZARArXwAKCTTIsLhCuMMgGzSdRp92UyDmeH4wCgiFrI DgddqO7VaPyACW0s24sqKpI= =Q4Gq -END PGP SIGNATURE-
Re: [CForms] Tree widget based on XML document
On Sun, 2006-06-18 at 11:03 +0200, Bruno Dumon wrote: > Hi, > > On Thu, 2006-06-15 at 23:49 +0200, Fred Vos wrote: > > Another > > thing that is necessary is the possibility to add key-value pairs to every > > folder and node, available in the form template. To create a directory tree > > with directories and files, showing filename, size, date et cetera, then > > requires the use of a directory generator and transforming its output to an > > xml document that can be used in the tree widget. > > I don't think the current tree model implementation forbids to add such > key-value pairs (or any sort of attribute) to your own tree node > implementation. It might of course be considered to make this a > standarized concept. I didn't think of this before, but the example you have given is perfectly possible with the SourceTreeModel today, without any work at all (no pipelines to set up, no XSL to write, and in addition branches are only loaded on demand and file name filtering is possible). So from a user POV, using the specific SourceTreeModel really is easier in this case. I understand this was just an example though. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Compatiblity problem in template block
After some searching I found out why the samples in 2.2 do not work anymore. It's an problem caused by removing deprecated stuff in 2.2. In 2.1.x with JXTG (not template block!), you can directory refer to "request", "response" and "parameters" in your template. We deprecated this in favour of always using the prefix "cocoon.". Unfortunately when we introduced "cocoon.parameters" we did not store the Parameters object but convert the Parameters object into a Properties object. So in 2.1.x accessing "parameters" returns a Parameters object while accessing "cocoon.parameters" returns a Properties object. As we have removed the deprecated stuff in the template block and in 2.2, there is no way to access the Parameters object anymore. As a properties object does not allow to iterate over the stored properties, there is no way to simply list all parameters (which makes the samples fail). Because of compatibility I think we can not simply change this code and store the Parameters object under "cocoon.parameters" (although this would make most sense to me). So perhaps using something more verbose like "cocoon.sitemap-parameters" could be used instead? WDYT? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: [CForms] Tree widget based on XML document
On Mon, 2006-06-19 at 11:56 +0200, Martijn C. Vos wrote: > Bruno Dumon [mailto:[EMAIL PROTECTED] wrote: > > > > > I think Cocoon only needs one tree model and that is a tree > > > model based on > > > XML. The selection-list widget has the possibility to > > > declare static content > > > in the form definition and can also refer to an xml > > > document in the src > > > attribute. Something like that would be nice for the tree widget. > > > > I don't see why the tree widget should be limited to XML models only, > > the selection list isn't limited to that either (see e.g. the jxpath > > selection list). Dictating to use XML would again require needless > > conversions from Java to XML when it is not needed. > > I don't think it should necessarily be the only one, but it > definitely should be the default tree. Sure, that would make sense. > Everything can be converted > to XML, and Cocoon is designed around XML. The only reason to use > something else is to skip a conversion step and save a bit of > time, but unlike the current trees, a good XML tree can do anything. > > > mcv. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: How to config Cocoon to handle Japanese characters?
Thanks a lot! I get it working. -- View this message in context: http://www.nabble.com/How-to-config-Cocoon-to-handle-Japanese-characters--t1795151.html#a4937022 Sent from the Cocoon - Dev forum at Nabble.com.
Re: Please review changes to WildcardHelper
Andreas Hartmann wrote: >>> >>> >>> >>> >>> >>> After the change, this matches all URLs ending with a slash, >>> even ones containing slashes. This is not intended, is it? >>> >> No, it's definitly not. This is a bug, I'll add your test case. > > OK, thanks a lot! > Ok, I fixed this one, but I'm getting more and more unhappy with the code; perhaps a clean rewrite would help... Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Please review changes to WildcardHelper
Carsten Ziegeler wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Hi,
I just fixed the bug in our wildcard helper. The problem was the
following: if a pattern ends with a constant string (like ".xml")
and the uri in question contained this constant twice (like
("hello.xml.xml") the pattern did not match.
We noticed a problem in Lenya:
After the change, this matches all URLs ending with a slash,
even ones containing slashes. This is not intended, is it?
No, it's definitly not. This is a bug, I'll add your test case.
OK, thanks a lot!
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
Incorrect EHDefaultStore behavior when overflow-to-disk is false
Currently, the EHDefaultStore can be configured to have overflow-to-disk=false. Since "diskPersistent" is not configurable, and always "true", disposing the cache results in a spoolToDisk error (ofcourse it is on schutting down the VM, so not to serious a problem). I changed the EHDefaultStore impl to have diskPersistent configurable (default true when overflow-to-disk=true). I will send a patch. Furhtermore, I read about ehcache-1.2 version that is has a large performance increase for DiskStore performance (up to 7 fold they say (1)). I tested the 1.2 version, and everything seems to be working fine. What do you think about upgrading the 1.1 version in lib/core to 1.2 for the ehcache. (1) http://sourceforge.net/project/shownotes.php?release_id=392051&group_id=93232 Regards Ard -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: Visiting get together
Hi Nils, Nils Kaiser wrote: I read some information about a cocoon get together this year. I am a german student working since a while as developer and currently involved in a cocoon project, and would be glad to assist the get together. Thanks, we'd certainly welcome your input and assistance. Apart of beeing very interested by the future direction of cocoon I think I could provide some ideas for the future pipeline work, especially on dynamic (content-aware) pipelines, as we are currently having some similar requirements in our projects. For the moment, we solve that problems with a DOM4J based transformer which evaluates some xpath conditions on the pipeline input to decide wether to run a transformation or not, which works but surely is not the best solution. By the way maybe I can get my employer to allow me to provide the stuff to the community... Interesting stuff! Please do contribute anything you can here on the dev list, there's no need to wait until the gettogether to get involved! :-) Is there any final date yet for the get together yet?? I hope it won't be before 12th of october as I am on holidays in Nepal before ;) The currently proposed dates are Monday 2nd, Tuesday 3rd and Wednesday 4th of October, which unfortunately fall during your Nepal vacation. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: Please review changes to WildcardHelper
Andreas Hartmann wrote:
> Carsten Ziegeler wrote:
>> Hi,
>>
>> I just fixed the bug in our wildcard helper. The problem was the
>> following: if a pattern ends with a constant string (like ".xml")
>> and the uri in question contained this constant twice (like
>> ("hello.xml.xml") the pattern did not match.
>
>
> We noticed a problem in Lenya:
>
>
>
>
>
> After the change, this matches all URLs ending with a slash,
> even ones containing slashes. This is not intended, is it?
>
No, it's definitly not. This is a bug, I'll add your test case.
Carsten
> I added a method to the WildcardHelperTestCase:
>
> public void testEndPattern() throws Exception {
> final Map resultMap = new HashMap();
> final String pattern = "*/";
> final int[] expr = WildcardHelper.compilePattern(pattern);
> boolean result = WildcardHelper.match(resultMap, "foo/bar/", expr);
> assertFalse("Url 'foo/bar/' should not match pattern '*/'.", result);
>
> result = WildcardHelper.match(resultMap, "foo/", expr);
> assertTrue("Url 'foo/' should match pattern '*/'", result);
> }
>
> resulting in:
>
> Testcase: testEndPattern took 0,003 sec FAILED
> Url 'foo/bar/' should not match pattern '*/'.
>
>
>
>
> Is this a bug, or do I misinterpret the matching functionality?
>
> Thanks!
>
> -- Andreas
>
>
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
RE: [CForms] Tree widget based on XML document
Bruno Dumon [mailto:[EMAIL PROTECTED] wrote: > > > I think Cocoon only needs one tree model and that is a tree > > model based on > > XML. The selection-list widget has the possibility to > > declare static content > > in the form definition and can also refer to an xml > > document in the src > > attribute. Something like that would be nice for the tree widget. > > I don't see why the tree widget should be limited to XML models only, > the selection list isn't limited to that either (see e.g. the jxpath > selection list). Dictating to use XML would again require needless > conversions from Java to XML when it is not needed. I don't think it should necessarily be the only one, but it definitely should be the default tree. Everything can be converted to XML, and Cocoon is designed around XML. The only reason to use something else is to skip a conversion step and save a bit of time, but unlike the current trees, a good XML tree can do anything. mcv.
Re: Please review changes to WildcardHelper
Carsten Ziegeler wrote:
Hi,
I just fixed the bug in our wildcard helper. The problem was the
following: if a pattern ends with a constant string (like ".xml")
and the uri in question contained this constant twice (like
("hello.xml.xml") the pattern did not match.
We noticed a problem in Lenya:
After the change, this matches all URLs ending with a slash,
even ones containing slashes. This is not intended, is it?
I added a method to the WildcardHelperTestCase:
public void testEndPattern() throws Exception {
final Map resultMap = new HashMap();
final String pattern = "*/";
final int[] expr = WildcardHelper.compilePattern(pattern);
boolean result = WildcardHelper.match(resultMap, "foo/bar/", expr);
assertFalse("Url 'foo/bar/' should not match pattern '*/'.", result);
result = WildcardHelper.match(resultMap, "foo/", expr);
assertTrue("Url 'foo/' should match pattern '*/'", result);
}
resulting in:
Testcase: testEndPattern took 0,003 sec FAILED
Url 'foo/bar/' should not match pattern '*/'.
Is this a bug, or do I misinterpret the matching functionality?
Thanks!
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [2.2] Release?
Niclas Hedhman wrote: > > Could the compromise be that the 'release' == 'alpha/beta/grokmake' with the > README listing '* Examples a,b,c not working,' ?? > Ok, perhaps my wording was not the best :) Of course the samples are not working, but this is a hint that the technology used by the samples is not working and not the sample by itself. So releasing in this state means not only that samples are not working but also core functionality. And the biggest block here is the template block. > Striving for perfection before action, is a paradox as perfection can only be > obtained by fine-tuning the action. :) > > I would +1 a improved release every week. Small steps. Little to consider. > Fast Forward. Done, Next!, Done! ... Anybody still around from the Cocoon 1.0 > times ?? If we have fixed the starting problems mentioned above, then we can release every day if we want and incrementally fix things (though I'm concerned by the implications wrt. legal oversight etc.). So, let's just fix the worst things and release :) I'm currently looking into the template block... Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
On Monday 19 June 2006 14:40, Carsten Ziegeler wrote: > Reinhard Poetz wrote: > > Carsten Ziegeler wrote: > >> Regardless of the name, I think we should take a little bit more time > >> and use the ApacheCon hackathon to "prepare" this first release and then > >> release (or upload) right after the ApacheCon. > > > > Then let's release in the first week of July *whatever* we have by then. > > This should also be the starting signal for a time-based release cycle > > (see my other answer to this mail). > > > :) Sorry to be a little pita here, but I will vote against a release in > > the first week of July *if* the situation with the samples is still the > same. If this is fixed by then I'll be fine :) Could the compromise be that the 'release' == 'alpha/beta/grokmake' with the README listing '* Examples a,b,c not working,' ?? Striving for perfection before action, is a paradox as perfection can only be obtained by fine-tuning the action. I would +1 a improved release every week. Small steps. Little to consider. Fast Forward. Done, Next!, Done! ... Anybody still around from the Cocoon 1.0 times ?? Cheers Niclas
Re: [2.2] Release?
Reinhard Poetz wrote: > > That's the point I want to make in my other mail: With this attitude we > probably > wait forever to get something released as then it's July, holiday time and > maybe > we won't even get 3 +1 votes of PMC members. > Now, currently I see only very few people here talking about a possible release. So it could be very hard to get 3 votes at all! > We have to break this vicious circle _now_ if we want to get quality feedback > from projects that try the migration. > And this is where I disagree. We are developing 2.2 for many years now and if we provide a not-really-running milestone after three years of development, I'm not sure if this will really help. Anyway, we still have two weeks including the hackathon next week, so we should be able to fix the samples and all of us (you and me) will be happy! Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
On 6/19/06, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: ...:) Sorry to be a little pita here, but I will vote against a release in the first week of July *if* the situation with the samples is still the same... Which makes me think, once again, that we should focus the ApacheCon EU Hackathon on getting this release out of the door, including samples and whatever's needed for people to be able to use the release. -Bertrand
Re: [2.2] Release?
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Regardless of the name, I think we should take a little bit more time
and use the ApacheCon hackathon to "prepare" this first release and then
release (or upload) right after the ApacheCon.
Then let's release in the first week of July *whatever* we have by then. This
should also be the starting signal for a time-based release cycle (see my other
answer to this mail).
:) Sorry to be a little pita here, but I will vote against a release in
the first week of July *if* the situation with the samples is still the
same. If this is fixed by then I'll be fine :)
That's the point I want to make in my other mail: With this attitude we probably
wait forever to get something released as then it's July, holiday time and maybe
we won't even get 3 +1 votes of PMC members.
We have to break this vicious circle _now_ if we want to get quality feedback
from projects that try the migration.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: Time based release cylces
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Before we decide what we call the releases exactly I want to draw our attention
to a decision we made long time ago. We agreed that we want to change to
time-based release cycles instead of the feature-driven releases we had up to
now which wasn't helpful in becoming more agile.
Taking this into consideration I think we can stick with giving our releases the
"milestone" postfix. The name "milestone" only says that another period of
development is over ("time-boxing").
We only need to decide how long the periods between releases should be. I guess
this will highly depend on the module. The most important modules (e.g.
cocoon-core, cocoon-forms, cocoon-template, cocoon-javaflow, the archetypes, the
deployment plugin) should be released every 4 weeks, other modules every 3
months and there will be modules that will only be released if required.
Additionally we should coordinate the release cycles so that at least twice a
year, we release everything at the same time (IIUC the Eclipse project wants to
make this happen for their universe with the "Callisto" initiative).
Now, while this really sounds great I fear it's very very difficult. It
was a hugh effort for the Callisto team (and the participating eclipse
projects) to get where they are today. And it's really time/resource
consuming - and as we are short of time/resources anyway, the only way
this would be possible is to automate the release and simply "do it"
after each time frame. But I don't think that this is a good idea as
there is no way to determine the quality of the relese.
So, in general I agree that we should try it, but not with the cost of
quality and tested releases.
We are watching quality all the time and we don't even manage to get our stable!
2.1 branch released. We have to become more agile in our release policy instead
of the opposite. M2 makes this possible and we should take this chance. And we
can always decide how we want to tag a release and here I agree with the quality
argument.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
