[jira] [Commented] (COCOON-2330) Release separate source and dependencies packages
[ https://issues.apache.org/jira/browse/COCOON-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506416#comment-13506416 ] Daniele Madama commented on COCOON-2330: Cocoon 2.1.x is ant based, is possible to integrate Ivy and let him to download the jars in lib directory (or download normally and then with an ant task move in the right place)? > Release separate source and dependencies packages > - > > Key: COCOON-2330 > URL: https://issues.apache.org/jira/browse/COCOON-2330 > Project: Cocoon > Issue Type: Improvement > Components: - Build System: Ant >Affects Versions: 2.1.11 >Reporter: Francesco Chicchiriccò > Fix For: 2.1.12-dev (Current SVN) > > > As recently reported by David Corssley [1] the 2.1.X release must comply with > ASF policies about releases, in particular providing a separate source code > package (without any external JAR file inside) and dependencies package (with > all external JAR files) for distribution. > [1] http://markmail.org/message/f6rm2ca35eiraf7i -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-2037) New DynamicGroup widget
[ https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniele Madama updated COCOON-2037: --- Attachment: dynamicgroup-patch-v2.txt new version that resolve some hierarchy issues > New DynamicGroup widget > --- > > Key: COCOON-2037 > URL: https://issues.apache.org/jira/browse/COCOON-2037 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Forms >Affects Versions: 2.1.11-dev (Current SVN) > Reporter: Daniele Madama > Fix For: 2.1.11-dev (Current SVN) > > Attachments: dynamicgroup-patch-v2.txt, dynamicgroup_patch.txt > > > I created a new DynamicGroup widget, with it you can replace all the children > of the group, so you can simply create a *dynamic form* without recreate the > form each time. Usefull for a very huge form that need to show only some > widget at time. > This approach is a little different with the CForms standard because every > time that you replace the children of the dynamic-group you must do a > bindLoad()/bindSave() if you need to preserve the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2037) New DynamicGroup widget
[ https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486663 ] Daniele Madama commented on COCOON-2037: We have a very huge entity, with hundreds of different fields, but we need to show only some of they each time, with this widget we can *split* the different view in each "form snippet" without load the full form on startup (many widget have some logic during the "on-create" phase and so on). Take a look at the patch, it has a sample that can explain the case better of my english ;). > New DynamicGroup widget > --- > > Key: COCOON-2037 > URL: https://issues.apache.org/jira/browse/COCOON-2037 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Forms >Affects Versions: 2.1.11-dev (Current SVN) >Reporter: Daniele Madama > Fix For: 2.1.11-dev (Current SVN) > > Attachments: dynamicgroup_patch.txt > > > I created a new DynamicGroup widget, with it you can replace all the children > of the group, so you can simply create a *dynamic form* without recreate the > form each time. Usefull for a very huge form that need to show only some > widget at time. > This approach is a little different with the CForms standard because every > time that you replace the children of the dynamic-group you must do a > bindLoad()/bindSave() if you need to preserve the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2037) New DynamicGroup widget
[ https://issues.apache.org/jira/browse/COCOON-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniele Madama updated COCOON-2037: --- Attachment: dynamicgroup_patch.txt > New DynamicGroup widget > --- > > Key: COCOON-2037 > URL: https://issues.apache.org/jira/browse/COCOON-2037 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Forms >Affects Versions: 2.1.11-dev (Current SVN) > Reporter: Daniele Madama > Fix For: 2.1.11-dev (Current SVN) > > Attachments: dynamicgroup_patch.txt > > > I created a new DynamicGroup widget, with it you can replace all the children > of the group, so you can simply create a *dynamic form* without recreate the > form each time. Usefull for a very huge form that need to show only some > widget at time. > This approach is a little different with the CForms standard because every > time that you replace the children of the dynamic-group you must do a > bindLoad()/bindSave() if you need to preserve the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2037) New DynamicGroup widget
New DynamicGroup widget --- Key: COCOON-2037 URL: https://issues.apache.org/jira/browse/COCOON-2037 Project: Cocoon Issue Type: New Feature Components: Blocks: Forms Affects Versions: 2.1.11-dev (Current SVN) Reporter: Daniele Madama Fix For: 2.1.11-dev (Current SVN) I created a new DynamicGroup widget, with it you can replace all the children of the group, so you can simply create a *dynamic form* without recreate the form each time. Usefull for a very huge form that need to show only some widget at time. This approach is a little different with the CForms standard because every time that you replace the children of the dynamic-group you must do a bindLoad()/bindSave() if you need to preserve the data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1180) OO samples don't work any longer
[ http://issues.apache.org/jira/browse/COCOON-1180?page=comments#action_12439454 ] Daniele Madama commented on COCOON-1180: I tested it with 2.1.10-dev and current 2.2 trunk on MacOSX and NeoOffice2.0b3 and all the cases (four) works perfectly. I think that this bug can be closed. > OO samples don't work any longer > > > Key: COCOON-1180 > URL: http://issues.apache.org/jira/browse/COCOON-1180 > Project: Cocoon > Issue Type: Bug > Components: - Samples >Affects Versions: 2.2-dev (Current SVN) > Environment: Operating System: other > Platform: Other >Reporter: Jörg Heinicke > Assigned To: Cocoon Developers Team > Attachments: hello.sxc, hello.sxw > > > http://127.0.0.1:/samples/hello-world/hello.sxw (writer) > http://127.0.0.1:/samples/hello-world/hello.sxc (calc) > both crash my OO 1.1.1 > while > http://127.0.0.1:/samples/hello-world/hello.sxi (impress) > http://127.0.0.1:/samples/hello-world/hello.sxd (draw) > still work. > Stephan Meinl mentions at > http://marc.theaimsgroup.com/?t=10868122679&r=1&w=4 that there is a > different behaviour with the older Xalan 2.5.2 (i.e. it works) instead of > 2.6.0. -- 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-1416) JXTemplate Bug List(For Refactoring info)
[
http://issues.apache.org/jira/browse/COCOON-1416?page=comments#action_12439260
]
Daniele Madama commented on COCOON-1416:
I tried this and work for me, can you give us a simple test or check if the bug
is already fixed?
> JXTemplate Bug List(For Refactoring info)
> -
>
> Key: COCOON-1416
> URL: http://issues.apache.org/jira/browse/COCOON-1416
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Templating
>Affects Versions: 2.2-dev (Current SVN)
> Environment: Operating System: Linux
> Platform: Other
>Reporter: Tibor Katelbach
> Assigned To: Cocoon Developers Team
>
> The any string
> ${myvar} will be empty when used.
>
> hack is to pass by jx:macros
--
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-905) JXTemplate evaluates expressions in comments, need jx:comment?
[ http://issues.apache.org/jira/browse/COCOON-905?page=comments#action_12439140 ] Daniele Madama commented on COCOON-905: --- I think this was related with bug #1866, so this can be closed or reported as duplicate. > JXTemplate evaluates expressions in comments, need jx:comment? > -- > > Key: COCOON-905 > URL: http://issues.apache.org/jira/browse/COCOON-905 > Project: Cocoon > Issue Type: Bug > Components: - Components: Sitemap >Affects Versions: 2.1.8 > Environment: Operating System: All > Platform: PC >Reporter: Mariusz Sieraczkiewicz > Assigned To: Cocoon Developers Team > > The code like this > > > > > > > throws > Original Exception: org.apache.commons.jxpath.JXPathException: No value for > xpath: .[4] > at org.apache.cocoon.generation.JXTemplateGenerator. > characters(JXTemplateGenerator.java:2820) at > org.apache.cocoon.generation.JXTemplateGenerator.execute(JXTemplateGenerator. > java:3495) at > org.apache.cocoon.generation.JXTemplateGenerator.execute(JXTemplateGenerator. > java:3179) at > org.apache.cocoon.generation.JXTemplateGenerator.generate(JXTemplateGenerator. > java:2790) > what means that commented out part of code is evaluated. -- 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-1866) jx:comment doesn't work
[
http://issues.apache.org/jira/browse/COCOON-1866?page=comments#action_12439132
]
Daniele Madama commented on COCOON-1866:
I try to reproduce the problem but I've no success. I'm using 2.1.10-dev
version, but the template block should be the same of 2.2. If I try to use
http://apache.org/cocoon/templates/jx/1.0";>test for
jx:comment
I receive in output only one empty comment
Lookin at the code I find a solution, but I don't know if it is correct
Index:
src/blocks/template/java/org/apache/cocoon/template/instruction/Comment.java
===
---
src/blocks/template/java/org/apache/cocoon/template/instruction/Comment.java
(revision 451947)
+++
src/blocks/template/java/org/apache/cocoon/template/instruction/Comment.java
(working copy)
@@ -59,8 +59,7 @@
for (int i = 0; i < len; i++) {
try {
String str = XMLUtils.serializeNode(nodeList.item(i), omit);
-buf.append(StringUtils.substringAfter(str, ">")); // cut
-// the XML header
+buf.append(str);
} catch (ProcessingException e) {
throw new SAXParseException(e.getMessage(), getLocation(), e);
}
with this *simple* patch if I write:
http://apache.org/cocoon/templates/jx/1.0";>
test element
http://apache.org/cocoon/templates/jx/1.0";>test for
jx:comment
the result is
so it seems that it work with text and also with nested elements.
I don't know if before there is some cases in which we need to remove the
header element.
> jx:comment doesn't work
> ---
>
> Key: COCOON-1866
> URL: http://issues.apache.org/jira/browse/COCOON-1866
> Project: Cocoon
> Issue 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.xal
Re: [jira] Commented: (COCOON-1314) Validation on HTMLArea fields doesn't work correctly
> > Hi, > > instead of replacing the space with nothing, should it not be replaced > by ' ' instead of no space? Yep, but this case we lost the possibility to use the required="true" constaint, that may be useful in some cases. You can remove current paragraph nodes > ( ) now that are wanted by a user. > > Since HTMLArea is no longer a living project anymore, submitting this > patch to the cocoon code seems fine to me. > > Regards, > > Jeroen Reijn > -- Daniele Madama (http://www.danysoft.org) Sourcesense - making sense of Open Source: (http://www.sourcesense.com)
[jira] Commented: (COCOON-942) [Roadmap] Default values for fields
[ http://issues.apache.org/jira/browse/COCOON-942?page=comments#action_12439092 ] Daniele Madama commented on COCOON-942: --- Is not the fd:initial-value enough? Do you mean a default value if the field was leaved null? > [Roadmap] Default values for fields > --- > > Key: COCOON-942 > URL: http://issues.apache.org/jira/browse/COCOON-942 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Forms >Affects Versions: 2.1.8 > Environment: Operating System: other > Platform: Other >Reporter: Reinhard Poetz > Assigned To: Cocoon Developers Team >Priority: Minor > > Make it possible to set default values for fields. -- 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-1314) Validation on HTMLArea fields doesn't work correctly
[
http://issues.apache.org/jira/browse/COCOON-1314?page=comments#action_12439086
]
Daniele Madama commented on COCOON-1314:
Hi,
I try with the actual 2.1.10-dev (Revision: 451904) and I check the htmlarea
sample at http://localhost:/samples/blocks/forms/htmlarea; I don't get the
'' tag but a 'nbsp;' in the data1 response.
Lookin for where it get this value, I see at
src/blocks/forms/resources/org/apache/cocoon/forms/resources/htmlarea/htmlarea.js,
changing in the follow way
Index:
src/blocks/forms/resources/org/apache/cocoon/forms/resources/htmlarea/htmlarea.js
===
---
src/blocks/forms/resources/org/apache/cocoon/forms/resources/htmlarea/htmlarea.js
(revision 451904)
+++
src/blocks/forms/resources/org/apache/cocoon/forms/resources/htmlarea/htmlarea.js
(working copy)
@@ -2038,7 +2038,7 @@
case 3: // Node.TEXT_NODE
// If a text node is alone in an element and all spaces,
replace it with an non breaking one
// This partially undoes the damage done by moz, which
translates ' 's into spaces in the data element
- if ( !root.previousSibling && !root.nextSibling &&
root.data.match(/^\s*$/i) ) html = ' ';
+ if ( !root.previousSibling && !root.nextSibling &&
root.data.match(/^\s*$/i) ) html = '';
else html = HTMLArea.htmlEncode(root.data);
break;
case 8: // Node.COMMENT_NODE
So I can check the correct value of the form and use the required attribute of
the widget.
I don't know in this modify has other side-effect.
With the above and following patch the sample work correctly
Index: src/blocks/forms/samples/flow/htmlarea.js
===
--- src/blocks/forms/samples/flow/htmlarea.js (revision 451948)
+++ src/blocks/forms/samples/flow/htmlarea.js (working copy)
@@ -22,9 +22,10 @@
form.showForm("htmlarea-display-pipeline");
var model = form.getModel();
+var data2 = model.data2 != null ? new
Packages.org.apache.cocoon.xml.StringXMLizable(model.data2) : null;
var htmldata = {
"data1" : model.data1,
- "data2" : new
Packages.org.apache.cocoon.xml.StringXMLizable(model.data2)
+ "data2" : data2
}
cocoon.sendPage("htmlarea-success-pipeline", htmldata);
}
Tnks
> Validation on HTMLArea fields doesn't work correctly
>
>
> Key: COCOON-1314
> URL: http://issues.apache.org/jira/browse/COCOON-1314
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Forms
>Affects Versions: 2.2-dev (Current SVN)
> Environment: Operating System: other
> Platform: Other
>Reporter: Reinhard Poetz
> Assigned To: Cocoon Developers Team
>
>
--
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: using Cocoon in a existing project
Hola, first of all: welcome! I think that the easier thing is to develop a separate webapplication that get the data from the same db and produce the xmlformat that you want. For the integration if you don't have some security policy you can simply link the cocoon match from the struts application. Bye. > > Hi, > > i am new to Cocoon. > > So, i started in a company and they already have a webapplication where > usres can get information from a database. > They want me to export data from the databse in an xml-file and also users > should get the possibility to download data from the the db in an > xml-file. > > So, my first question, do you also think, that cocoon will be usefull for > this task. Or ist it to "big", means "powerfull"? > And, if yes, how do i integrate cocoon in the project? we are developing > with eclipse and yousing struts. > > Thanks for your help, > Werz > -- > View this message in context: > http://www.nabble.com/using-Cocoon-in-a-existing-project-tf2227359.html#a6172455 > Sent from the Cocoon - Dev forum at Nabble.com. > > -- Daniele Madama (http://www.danysoft.org) Sourcesense - making sense of Open Source: (http://www.sourcesense.com)
Re: Dynamically activating/disabling/hiding and requiring fields
> Ciao Daniele, > I've implemented it, but it should be cleaned up, commented, and adapted > to the cocoon source tree. It was just a proposal, I'll wait after the > code freeze to propose it again. > > Which one of the possible solutions do you like? All! Conditionally-required and conditionally-state are common use cases, now I use flowscript in the event-handler, but the xml-declaration is more clean and not api-aware, so it result more easy for non-developer users. Bye, Daniele -- Daniele Madama (http://www.danysoft.org) Pro-netics S.r.l. (http://www.pronetics.it)
Re: Dynamically activating/disabling/hiding and requiring fields
Ciao Simone, I suppose that there's no time to add this nice features into the imminent 2.1.9, but I think that this way of setting widget's state is very usefull (I need it now ;) ). Do you think to commit it after the release? TIA, -- Daniele Madama (http://www.danysoft.org) Pro-netics S.r.l. (http://www.pronetics.it)
Build error on current svn version
Hola,
I've the follow build problem:
C:\Project\Cocoon\BRANCH_2_1_X\src\blocks\forms\java\org\apache\cocoon\forms\sam
ples\bindings\CustomValueWrapBinding.java:29:
org.apache.cocoon.forms.samples.bindings.CustomValueWrapBinding is not
abstract and does not override abstract method
setEnclosingLibary(org.apache.cocoon.forms.binding.library.Library) in
org.apache.cocoon.forms.binding.Binding
public class CustomValueWrapBinding extends AbstractCustomBinding {
^
BUILD FAILED
I'm the only?
TIA
--
Daniele Madama (http://www.danysoft.org)
Pro-netics S.r.l. (http://www.pronetics.it)
[jira] Commented: (COCOON-1736) NPE in forms library when extend field
[ http://issues.apache.org/jira/browse/COCOON-1736?page=comments#action_12363252 ] Daniele Madama commented on COCOON-1736: Yes, your patch work. Tnks > NPE in forms library when extend field > -- > > Key: COCOON-1736 > URL: http://issues.apache.org/jira/browse/COCOON-1736 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Daniele Madama > Assignee: Jean-Baptiste Quenot > Attachments: 20060119-COCOON-1736, AbstractWidgetDefinition.patch > > As reported on my mail [1] I've a NPE in forms library when extend a field, > follow stacktrace: > ... > Caused by: java.lang.NullPointerException > at > org.apache.cocoon.forms.formmodel.AbstractWidgetDefinition.initializeFrom(AbstractWidgetDefinition.java:92) > at > org.apache.cocoon.forms.formmodel.AbstractDatatypeWidgetDefinition.initializeFrom(AbstractDatatypeWidgetDefinition.java:61) > at > org.apache.cocoon.forms.formmodel.FieldDefinition.initializeFrom(FieldDefinition.java:41) > ... > Look at the simple patch attached. > [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113759470531201&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1736) NPE in forms library when extend field
NPE in forms library when extend field -- Key: COCOON-1736 URL: http://issues.apache.org/jira/browse/COCOON-1736 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Daniele Madama Attachments: AbstractWidgetDefinition.patch As reported on my mail [1] I've a NPE in forms library when extend a field, follow stacktrace: ... Caused by: java.lang.NullPointerException at org.apache.cocoon.forms.formmodel.AbstractWidgetDefinition.initializeFrom(AbstractWidgetDefinition.java:92) at org.apache.cocoon.forms.formmodel.AbstractDatatypeWidgetDefinition.initializeFrom(AbstractDatatypeWidgetDefinition.java:61) at org.apache.cocoon.forms.formmodel.FieldDefinition.initializeFrom(FieldDefinition.java:41) ... Look at the simple patch attached. [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113759470531201&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
NPE in AbstractWidgetDefinition when using library
Hola,
I'm using forms library from svn updated some minutes ago, if I extend a
field from library I got a NPE at row 92 of AbstractWidgetDefinition
because the property attributes is null, probably this map was never
initialized.
My library is this:
...
label.account
...
and my definition:
...
print("on-value-changed");
...
other widget work correctly and if I expand this instead of extend it work.
Any hint?
TIA
--
Daniele Madama (http://www.danysoft.org)
Pro-netics S.r.l. (http://www.pronetics.it)
Re: Flowscript debugger doesn't work
> version? SVN version of today, now I'm not on my notebook, so I can tell you the correct revision. > > Best Regards, > > Antonio Gallardo -- Daniele Madama http://www.pronetics.it http://www.danysoft.org/blogs/
Flowscript debugger doesn't work
Hola, from a lot of time (3 months of course) the flowscipt debugger doesn't work, if I try to enable it in cocoon.xconf ed execute the forms sample, It broke the flow esecution. I'm not a rhino expert, so I can say if It depends from new version of rhino or not. But I think that it could be useful, so is possible to have this nice feature to work? If not, I think that we should remove it from cocoon.xconf (remove the commented element). Regards Daniele -- The box said "Requires Windows 95/98/Me/Nt/2k/XP or better" so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
> Upayavira wrote: > ... >> Do we need to include a libary to achieve a better L&F? What is the >> current way in the Java world? If we do, we need to make sure that we >> choose one that is licenced in a compatible way to ASL. Thus, [2], which >> is LGPL, is not compatible. I know JGoodies is BSD, but don't know if it >> is any good. >> >> Any Java Swing gurus here who can give a little guidance? > > IMHO, if a GUI feels ugly, the first thing to do is to rethink the > layout. From teh screenshots I saw here it's not qhat I would call a > "standard" layout. > > Then set the look and feel of the native platform (please no metal), add > icons, set the spacing between components, use SwingWorker to manage > long-running actions... and thing will start to look nice. > > Other things can be done like setting rollover images for buttons, using > more advanced components for some parts of the UI (swinglabs and > l2fprod), using progress bars and statusbar for more info to the user, > add a splash, tweak font, etc. > > Only *then* one can think of changing the l&f, but usually it's not > needed. Make sense, I'm new on UI programming and for me is more easy to change l&f than think a good layout :D. Thanks for the lesson ;) > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - >(discussions get forgotten, just code remains) > --------- > > -- The box said "Requires Windows 95/98/Me/Nt/2k/XP or better" so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
> > The application has the default Java swing look, which isn't very > exciting. So, anything that looks a little prettier... > > Windows look and feel, Metal, GTK+, whatever, I'm no expert, I just know > that Java apps can look prettier. And it is important that it look > reasonably pretty if this is going to be someone's first sight of Cocoon. > > Regards, Upayavira > I'm surfing the web looking for more look&feel layout, I found this site [1] with lot of free l&f. I'd like many liquid [2], but there are many themes very nice. Can we go ahead for this way? WDYT? [1] http://javootoo.l2fprod.com/ [2] https://liquidlnf.dev.java.net/ -- The box said "Requires Windows 95/98/Me/Nt/2k/XP or better" so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
> On 9/22/05, Upayavira <[EMAIL PROTECTED]> wrote: >> Daniele Madama wrote: >> Idea is simple, but works. I like the fact that it respects the >> dependency information. That will ease people's lives a lot. My Ant >> based installer didn't do that. >> >> Here's a few thoughts: >> >> 1. Could you show the dependency information in the right hand pane? >> It >> isn't always clear as to why a block's tick is grayed out. >> 2. Could you add a page/tab for the basic options in build.properties? >> 3. Could you add a pane that actually invokes Ant? If you could do >> that, and added a 'welcome' pane, you'd have written a full >> installer, which would be excellent. All it would need to do is set >> stdout to an output stream that gets written to a list box or text >> box, and has a cancel button. >> 4. Could you make it use a more modern UI style? > > I'll add #5 then: adding a Jetty control pane to start/stop the webapp. Yeah! And launch the rocket too. :D Seriously, with this feature it became a complete installer. I will start the coding of points 2 and 3, and then add this feature ;) I'm very happy that this little application like to the community (2 people for this time :D) Daniele > > -- > Gianugo Rabellino > Pro-netics s.r.l. - http://www.pro-netics.com > Orixo, the XML business alliance: http://www.orixo.com > (blogging at http://www.rabellino.it/blog/) > -- The box said "Requires Windows 95/98/Me/Nt/2k/XP or better" so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
> > Idea is simple, but works. I like the fact that it respects the > dependency information. That will ease people's lives a lot. My Ant > based installer didn't do that. > > Here's a few thoughts: > > 1. Could you show the dependency information in the right hand pane? It > isn't always clear as to why a block's tick is grayed out. > 2. Could you add a page/tab for the basic options in build.properties? > 3. Could you add a pane that actually invokes Ant? If you could do > that, and added a 'welcome' pane, you'd have written a full > installer, which would be excellent. All it would need to do is set > stdout to an output stream that gets written to a list box or text > box, and has a cancel button. > 4. Could you make it use a more modern UI style? Points 2 and 3 already are in my TODO list :D. For point 4 I think that any people with a little of SWING experience (isn't my case) could do a very well work. Any volunteer? :D > > I like the idea of what we have here. I'd be all for adding it to the > Cocoon 2.1.X codebase. > > What do others think? > > Regards, Upayavira > > P.S. My (Unix) command to invoke it was: > > java -cp > lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar:lib/endorsed/xml-apis.jar:lib/endorsed/xercesImpl-2.7.1.jar:cbuilder-0.1-idea.jar > org.apache.cocoon.builder.CocoonBuilder > > Windows would be: java -cp > lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar;lib/endorsed/xml-apis.jar;lib/endorsed/xercesImpl-2.7.1.jar;cbuilder-0.1-idea.jar > org.apache.cocoon.builder.CocoonBuilder > -- The box said "Requires Windows 95/98/Me/Nt/2k/XP or better" so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
> Daniele Madama wrote: >>>* Gianugo Rabellino: >>> >>> >>>>I think so, Cocoon 2.1 is here to stay for a while. FWIW, a >>>>colleague of mine (Daniele Madama) wrote a small GUI to manage >>>>blocks selection (think make xconfig for the linux kernel). If >>>>you deem it useful, my take is Daniele would be glad to >>>>contribute it. >>> >>>On FreeBSD, there is a Cocoon installer that has such a GUI. See >>>attached screenshot. This is based on a BSD Makefile. >> >> My installer is similar to this, but it is written in SWING. It has a >> selection of blocks (read and pre-selected from >> [local.]blocks.properties) >> with their description (read from gump.xml) and it will have a selection >> from principal build.properties (like samples, javadoc, and more). >> >> I hope to have time to finish some feature and donate it, if you want >> and >> if you think that it was useful. ;) > > Since the scope of the work required of the AntInstaller and yours isn't > that different, I'd be interested to see yours. Thanks for your interest, I really hope this small application might serve the needs of the cocoon community. If you think the application might suit your needs, I'll gladly post the source to bugzilla. To try it out: http://www.pronetics.it/transfer/cbuilder-0.1-idea.jar For execute: 1) put the jar in $COCOON_HOME 2) backup your local.blocks.properties ;) 3) java -jar cbuilder-0.1-idea.jar this work only on BRANCH_2_1_X version, if you have an older version, execute it with 'java -cp lib/endorsed/x*.jar org.apache.cocoon.builder.CocoonBuilder'. I'm waiting for your hints or opinion. Regards Daniele > > Interesting to see that you use the descriptions from gump.xml. I put > those there when I was planning to do build this installer, for the very > purpose you are using them for! > > Regards, Upayavira > -- The box said "Requires Windows 95/98/Me/Nt/2k/XP or better" so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
> * Gianugo Rabellino: > >> I think so, Cocoon 2.1 is here to stay for a while. FWIW, a >> colleague of mine (Daniele Madama) wrote a small GUI to manage >> blocks selection (think make xconfig for the linux kernel). If >> you deem it useful, my take is Daniele would be glad to >> contribute it. > > On FreeBSD, there is a Cocoon installer that has such a GUI. See > attached screenshot. This is based on a BSD Makefile. My installer is similar to this, but it is written in SWING. It has a selection of blocks (read and pre-selected from [local.]blocks.properties) with their description (read from gump.xml) and it will have a selection from principal build.properties (like samples, javadoc, and more). I hope to have time to finish some feature and donate it, if you want and if you think that it was useful. ;) Daniele > -- > Jean-Baptiste Quenot > Systèmes d'Information > ANYWARE TECHNOLOGIES > Tel : +33 (0)5 61 00 52 90 > Fax : +33 (0)5 61 00 51 46 > http://www.anyware-tech.com/ > -- The box said "Requires Windows 95/98/Me/Nt/2k/XP or better" so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Fixing i18n required messages
> I found that, and yes of course I have the message keys added.. You
> should try it, practice is usually better than theory. I've seen this
> mentioned elsewhere, if its a bug I'd prefer to submit a patch when i
> enter it rather than just joining a que.
If you see the form-instance you can found the declaration of
validation-message
general.field-required
so this message must be in the 'forms' catalogue, if you want to have the
message in the same file of other message you can simply add another
catalogue on the declaration of I18nTransformer that point on the same
file
false
in this code both catalogue point to the same file.
Is this all or your sitatuion is different?
TIA,
Best regards
>
> On Thu, 17 Feb 2005 11:40:37 +0100 (CET), Daniele Madama
> <[EMAIL PROTECTED]> wrote:
>>
>> > Hello
>> >
>> > Could someone nudge me in the right direction (i.e. where to start
>> > looking) if i wanted to get a patch in to fix this annoying i18n
>> > required messages problem.
>> >
>> > Thanks
>> >
>> > Mark
>> >
>>
>> If you are looking for the i18n of the cforms required message, is
>> already
>> done in the o.a.c.forms.formmodel.Field class
>>
>>
>>if (this.value == null && getFieldDefinition().isRequired())
>> {
>>// Field is required
>>this.validationError = new ValidationError(new
>> I18nMessage("general.field-required",
>> Constants.I18N_CATALOGUE));
>>} else {
>>
>>
>> So the only things is to add the correct message entry in the i18n
>> catalog.
>>
>> I hope this is what you need.
>>
>> Best regards
>>
>> --
>> Daniele Madama
>>
>> Pro-netics s.r.l.
>> Via Elio Lampridio Cerva 127/c
>> Roma
>> Tel. 0651530849
>> http://www.pro-netics.com
>>
>
--
Daniele Madama
Pro-netics s.r.l.
Via Elio Lampridio Cerva 127/c
Roma
Tel. 0651530849
http://www.pro-netics.com
Re: Fixing i18n required messages
> Hello
>
> Could someone nudge me in the right direction (i.e. where to start
> looking) if i wanted to get a patch in to fix this annoying i18n
> required messages problem.
>
> Thanks
>
> Mark
>
If you are looking for the i18n of the cforms required message, is already
done in the o.a.c.forms.formmodel.Field class
if (this.value == null && getFieldDefinition().isRequired()) {
// Field is required
this.validationError = new ValidationError(new
I18nMessage("general.field-required",
Constants.I18N_CATALOGUE));
} else {
So the only things is to add the correct message entry in the i18n catalog.
I hope this is what you need.
Best regards
--
Daniele Madama
Pro-netics s.r.l.
Via Elio Lampridio Cerva 127/c
Roma
Tel. 0651530849
http://www.pro-netics.com
Re: Problem with jxtg and sax
Hi,
sorry for this mail-spamming :D, but I'm trying to search the cause of
this problem, and I'm going more in deep in the code, so I arrived on
o.a.c.util.jxpath.DOMFactory, that was the factory passed on JXPathContext
when create a context for binding. In createObject() the node parent has
getPrefix() = null and the node name has correct prefix, now or there is a
problem in jxpath that doesn't take node in the rigth way, or I dont'
known where could be the problem.
As possible solution (delete the code on the previuos mail) I can only
suggest in DOMFactory.getNamespaceURI() somethings like this patch:
@@ -100,13 +100,19 @@
while (tmp != null && tmp.getNodeType() == Node.ELEMENT_NODE) {
element = (Element)tmp;
+
+String elementPrefix = element.getPrefix();
+int pos = element.getNodeName().indexOf(":");
+if (elementPrefix == null && pos != -1) {
+elementPrefix = element.getNodeName().substring(0, pos);
+}
// First test element prefixes
if (prefix == null) {
-if (element.getPrefix() == null) {
+if (elementPrefix == null) {
return element.getNamespaceURI();
}
-} else if(prefix.equals(element.getPrefix())) {
+} else if(prefix.equals(elementPrefix)) {
return element.getNamespaceURI();
}
WDYT?
TIA
--
Daniele Madama
Pro-netics s.r.l.
Via Elio Lampridio Cerva 127/c
Roma
Tel. 0651530849
http://www.pro-netics.com
Re: Problem with jxtg and sax
Hi,
after a lot of time on JXTG and DOMStreamer I see where the really problem
is. The namespace was declared in the rigth way, the Document is correct
and streaming it does'n create any problem.
On this DOM I apply a cforms binding, and I create some node using
jxpathContext.createPathAndSetValue(), passing first parameter like
qualified name "puei:id" as specified on jxpath documentation [1]. The
createPathAndSetValue() method use AbstractFactory.createObject(). I think
that jxpat use the same node to get the namespaceURI or pointer setted
through jxpathContext.setNamespaceContextPointer().
So I set the root pointer (see xml in the previous mail) as pointer for
namespace, after serializing the document it seems well, but in
DOMStreamer$NamespaceNormalizingDOMStreamer.startNode() the namespaceURI
variable was never setted. In this way the contentHandler.startElement()
with a qName having a prefix e without namespaceURI throw the exception in
respect of w3c XML specification.
The suspect is that jxpath don't find the namespace declaration and so it
create element using qname as name without namespace.
Now I must to find a solution:
- Instead of use createPathAndSetValue() create a Node with a namespace,
and set it as value of the pointer.
- Add this code to DOMStreamer before startElement() at line 446
if (namespaceURI.equals("")) {
NamedNodeMap attrs =
node.getOwnerDocument().getDocumentElement().getAttributes();
for (int i=0; ihttp://jakarta.apache.org/commons/jxpath/apidocs/org/apache/commons/jxpath/AbstractFactory.html
--
Daniele Madama
Pro-netics s.r.l.
Via Elio Lampridio Cerva 127/c
Roma
Tel. 0651530849
http://www.pro-netics.com
Problem with jxtg and sax
Hi to all,
I have a little problem (if it's a problem) with JXTG and Sax, I try to
resume the behaviour.
My transfomer build a Document with a structure like this:
http://www.foo.com/";>
test
XML
xyz
http://www.w3.org/2001/XMLSchema-instance";
xsi:type="puei:service-id">
http://www.bar.com/";>06
http://www.bar.com/";>XYZ_zyx
http://www.bar.com/";>modify
...
...
this is well-formed and it's correct, but I need to validate it with a XSD
Schema, so I must add a namespace declaration for prefix "puei" in
or parent element otherwise It cannot *known* the prefix
specified in "xsi:type" attribute.
I add a namespace declaration with this code:
Attr nameSpace =
newDoc.createAttributeNS("http://www.w3.org/2000/xmlns/";, "xmlns:" +
newPrefix);
nameSpace.setValue(newNS);
((Element) root).setAttributeNode(nameSpace);
where newPrefix's value is "puei" and "http://www.bar.com/"; for newNS.
If I serialize the document it seems ok, with namespace declared in the
right way.
The result of this transformer is taken from a flow, that call a match
with sendPage(), this match has a jxtg with a jx:out dealing with a
Document received from flow. But this generate an Exception:
DOMException: NAMESPACE_ERR: An attempt is made to create or change an
object in a way which is incorrect with regard to namespaces.
following the stacktrace it was throw when JXTG try to serialize it with
DOMStreamer.stream().
Now I don't know if I missing something when add namespace declaration (is
it the correct mode?) or if there is a problem in DOMStreamer.
Any hint?
TIA
--
Daniele Madama
Pro-netics s.r.l.
Via Elio Lampridio Cerva 127/c
Roma
Tel. 0651530849
http://www.pro-netics.com
