[jira] Reopened: (COCOON-1682) Custom headers for Sendmail Action/Logicsheet/Transformer needed

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1682?page=all ]

Antonio Gallardo reopened COCOON-1682:
--

  Assignee: Cocoon Developers Team
 
It is a user wish. We should not close it.

> Custom headers for Sendmail Action/Logicsheet/Transformer needed
> 
>
> Key: COCOON-1682
> URL: http://issues.apache.org/jira/browse/COCOON-1682
> Project: Cocoon
>  Issue Type: Wish
>  Components: Blocks: Mail
>Affects Versions: 2.1.7
>Reporter: Lauri Pitkänen
> Assigned To: Cocoon Developers Team
>Priority: Minor
>
> Possibility to add multiple custom headers to messages from Sendmail
> Action/Logicsheet/Transformer would eliminate the need for adding
> missing fixed optional headers like ReplyTo one by one.
> This is something that is already available in the AxKit XSP tag library::
> http://search.cpan.org/~kjetilk/AxKit-XSP-Sendmail/Sendmail.pm#%3Csendmail:header%3E
> Configuration example:
> bulk
> Something
> Headers in the message:
> Precedence: bulk
> X-My-Header: Something

-- 
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-1825) Ajax errror when an active state widget become invisible state widget

[Antonio Gallardo (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1825?page=comments#action_12442267 
] 

Antonio Gallardo commented on COCOON-1825:
--

IN the first part of the patch, there is: 

+ 
+  

I don't think it is a good idea to have the same id in 2 different elements. It 
seems like it might blow somewhere else.

how we can fix this?

> Ajax errror when an active state widget become invisible state widget
> -
>
> Key: COCOON-1825
> URL: http://issues.apache.org/jira/browse/COCOON-1825
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Forms
>Affects Versions: 2.1.9
>Reporter: vincent Demay
> Assigned To: Antonio Gallardo
>
> Some widget (field with selection-list and styling=radio, group, etc...)  can 
> not be hidden (state=invisible)in ajax mode.
> I declare some widgets without state attribute in the form definition, my 
> form is in ajax mode, when I set the widget state to INVISIBLE, the ajax 
> response can not be applied to the form because  id="widget-name">... is not available in source code.
> I think about 2 patches : 
> *putting a  in forms-field-styling.xsl where is not set
> *or modifing abstractWidgetDefinition.java in ordre to generate a placeholder 
> around each widget (but patch seems to need a lot of modification in 
> forms-field-styling.xsl too)
> Here is the patch for first 
> --- forms-field-styling.orig  2006-04-13 15:37:06.590221200 +0200
> +++ forms-field-styling.xsl   2006-04-13 15:38:22.525291200 +0200
> @@ -198,8 +198,9 @@
>  
>   select="string(fi:styling/@list-orientation) != 'horizontal'"/>
>  
> -  
> - title="{fi:hint}">
> +  
> +   
> +   title="{fi:hint}">
>
>  
>  
> @@ -224,6 +225,7 @@
>  
>
>  
> +
>
>
>  
> @@ -682,22 +684,24 @@
>| know where to insert the widget if it becomes visible
>+-->
>
> -
> +
>
>
>
>
> -
> + 
>
>  
>
>
> -
> +
>
> +  
> +  
>  
>
>  
> Here for the second
> --- AbstractWidget.orig   2006-04-13 15:31:07.851701200 +0200
> +++ AbstractWidget.java   2006-04-13 15:30:31.446616200 +0200
> @@ -483,6 +483,10 @@
>  public void generateSaxFragment(ContentHandler contentHandler, Locale 
> locale)
>  throws SAXException {
>  
> + AttributesImpl placeHolderAttrs = new AttributesImpl();
> + placeHolderAttrs.addCDATAAttribute("id", getRequestParameterName());
> +contentHandler.startElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", 
> placeHolderAttrs);
> +
>  if (getCombinedState().isDisplayingValues()) {
>  // FIXME: we may want to strip out completely widgets that 
> aren't updated when in AJAX mode
>  String element = this.getXMLElementName();
> @@ -497,15 +501,9 @@
>  
>  generateItemSaxFragment(contentHandler, locale);
>  
> -contentHandler.endElement(FormsConstants.INSTANCE_NS, element, 
> FormsConstants.INSTANCE_PREFIX_COLON + element);
> -
> -} else {
> -// Generate a placeholder that can be used later by AJAX updates
> -AttributesImpl attrs = new AttributesImpl();
> -attrs.addCDATAAttribute("id", getRequestParameterName());
> -contentHandler.startElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder", attrs);
> -contentHandler.endElement(FormsConstants.INSTANCE_NS, 
> "placeholder", FormsConstants.INSTANCE_PREFIX_COLON + "placeholder");
> +contentHandler.endElement(FormsConstants.INSTANCE_NS, element, 
> FormsConstants.INSTANCE_PREFIX_COLON + element); 
>  }
> +contentHandler.endElement(FormsConstants.INSTANCE_NS, "placeholder", 
> FormsConstants.INSTANCE_PREFIX_COLON + "placeholder");
>  }
>  
>   public Object getAttribute(String name) {

-- 
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-1894) Added support for the SQL:XML tag in SQLTransformer

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1894?page=all ]

Antonio Gallardo updated COCOON-1894:
-


Thanks for the patch.

> Added support for the SQL:XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Assigned To: Antonio Gallardo
> Attachments: SQLTransformer.java, SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
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-1894) Added support for the SQL:XML tag in SQLTransformer

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1894?page=all ]

Antonio Gallardo updated COCOON-1894:
-

Summary: Added support for the SQL:XML tag in SQLTransformer  (was: Added 
support for the SQL;XML tag in SQLTransformer)

Fix a typo on the summary.

> Added support for the SQL:XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Assigned To: Antonio Gallardo
> Attachments: SQLTransformer.java, SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
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] Assigned: (COCOON-1894) Added support for the SQL;XML tag in SQLTransformer

[Antonio Gallardo (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1894?page=all ]

Antonio Gallardo reassigned COCOON-1894:


Assignee: Antonio Gallardo

> Added support for the SQL;XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Assigned To: Antonio Gallardo
> Attachments: SQLTransformer.java, SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
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-1894) Added support for the SQL;XML tag in SQLTransformer

[Geurt Wisselink (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1894?page=comments#action_12442205 
] 

Geurt Wisselink commented on COCOON-1894:
-


   [[ Old comment, sent by email on Sun, 27 Aug 2006 20:02:15 +0200 ]]

Antonio,

Is there anything I need to do before it can be changed in cocoon 2.2?

Regards Geurt



> Added support for the SQL;XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Attachments: SQLTransformer.java, SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
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-1894) Added support for the SQL;XML tag in SQLTransformer

[Geurt Wisselink (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1894?page=comments#action_12442204 
] 

Geurt Wisselink commented on COCOON-1894:
-


   [[ Old comment, sent by email on Wed, 23 Aug 2006 20:54:45 +0200 ]]

I added it as patch in Jira.
But here it is via email.

Regards Geurt 



> Added support for the SQL;XML tag in SQLTransformer
> ---
>
> Key: COCOON-1894
> URL: http://issues.apache.org/jira/browse/COCOON-1894
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Databases
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Geurt Wisselink
> Attachments: SQLTransformer.java, SQLTransformer.java.patch
>
>
> It adds support for the SQL:XML tag, this makes it possible to write XML 
> inside a SQL database.

-- 
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-1876) XMLDBTransformer blows up Saxon

[Don Grodecki (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1876?page=comments#action_12442172 
] 

Don Grodecki commented on COCOON-1876:
--


   [[ Old comment, sent by email on Tue, 11 Jul 2006 07:42:25 -0500 ]]

Thank you! - Don



> XMLDBTransformer blows up Saxon
> ---
>
> Key: COCOON-1876
> URL: http://issues.apache.org/jira/browse/COCOON-1876
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: XML-DB
>Affects Versions: 2.1.9
>Reporter: Don Grodecki
> Assigned To: Antonio Gallardo
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
>
> The XMLDBTransformer blows up Saxon, which does not like null URIs. The
> following fix seems to work, replacing null in the first parameter to
> addAttribute with "".
> // Report result
> AttributesImpl attrs = new AttributesImpl();
> attrs.addAttribute("", XMLDB_QUERY_OID_ATTRIBUTE,
> XMLDB_QUERY_OID_ATTRIBUTE, "CDATA", this.key);
> attrs.addAttribute("", XMLDB_QUERY_TYPE_ATTRIBUTE,
> XMLDB_QUERY_TYPE_ATTRIBUTE, "CDATA", this.operation);
> attrs.addAttribute("", XMLDB_QUERY_RESULT_ATTRIBUTE,
> XMLDB_QUERY_RESULT_ATTRIBUTE, "CDATA", result);
> The API being called is the SAX org.xml.sax.ContentHandler.createElement().
> From the Interface definition at http://www.saxproject.org/apidoc/index.html:
> "Parameters:
> uri - the Namespace URI, or the empty string if the element has no Namespace 
> URI or if Namespace processing is not being performed
> ..."
> Note that a null value is not specified as one of the options:
> Both the versions that I have, which are saxon8 (jar contents dated
> 4/7/2005) and saxonB-8.7.3 (the latest), blow out with a
> NullPointerException.
> I have used Saxon quite a bit, for XSLT 2.0, and the only calls to Saxon
> with null URIs have been from the XMLDBTransformer.

-- 
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-1815) CopySourceAction generate NPE

[JIRA]

[ 
http://issues.apache.org/jira/browse/COCOON-1815?page=comments#action_12442125 
] 

Frédéric Glorieux commented on COCOON-1815:
---


   [[ Old comment, sent by email on Mon, 29 May 2006 11:00:54 +0200 ]]


Thanks for others, but for testing, sorry, I can't find time for now, 
I'm on other projects (in PHP :o( )




-- 
FrC)dC)ric Glorieux (AJLSM, http://ajlsm.com)


> CopySourceAction generate NPE
> -
>
> Key: COCOON-1815
> URL: http://issues.apache.org/jira/browse/COCOON-1815
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.1.8
>Reporter: Frédéric Glorieux
> Assigned To: Antonio Gallardo
>Priority: Minor
> Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
>
>
> 
> In some circumstances, with internal sources (cocoon:/), 
> org/apache/cocoon/acting/copySource.java 
> 
> copy-source action generate NPE in Console (nothing seems broken)
> Source objects needs to be released
> Code may be shorter with usage of excalibur SourceUtil to copy sources
> try {
> org.apache.excalibur.source.SourceUtil.SourceUtil.copy(src, dest);
> } finally {
> resolver.release(src);
> resolver.release(dest);
> }

-- 
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-1933) [Patch] Automatic loading of flow scripts in "flow/" must not load directories

[Carsten Ziegeler (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12442085 
] 

Carsten Ziegeler commented on COCOON-1933:
--

I think this wouldn't help us in this case as even the Excalibur source 
resolver can't tell if a resource is a directory or a file in the case of an 
unexpanded war.
I checked in a fix yesterday which should solve most of the problems when 
running unexpanded, but the file/directory detection is still an issue. I guess 
we could use getFile() first and if that fails use getInputStream() for testing?

> [Patch] Automatic loading of flow scripts in "flow/" must not load directories
> --
>
> Key: COCOON-1933
> URL: http://issues.apache.org/jira/browse/COCOON-1933
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Klimetschek
> Attachments: cocoon-flow-only-files.patch
>
>
> The automatic loading of everything inside flow/ also tries to load 
> directories, which cannot be compiled like files. Happens typically when you 
> have a subversion directory (.svn) or other version-control directory inside.
> The stacktrace for the problem:
> Caused by: org.apache.excalibur.source.SourceNotFoundException: 
> file:/Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn/
>  doesn't exist.
> at 
> org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150)
> at 
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:502)
> at 
> org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.getScript(CompilingInterpreter.java:112)
> at 
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:453)
> at 
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:572)
> at 
> org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109)
> ... 43 more
> Caused by: java.io.FileNotFoundException: 
> /Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn
>  (No such file or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:106)
> at 
> org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146)
> ... 48 more 

-- 
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: various cforms issues

[Vadim Gritsenko]

Marc Portier wrote:


Vadim Gritsenko wrote:

Marc Portier wrote:

1/ fd:output is ignoring fd:initial-value
this one is quite obvious I think: anybody adding a fd:initial-value to
a fd:output can wait for eternity for it to ever get applied.

Proposed fix: initialize() should do it like Field.java does.

+1


I still think the fix should be applied, but given the current
widget-states I guess the same can be achieved through a proper 'field'


That's what I said: +1, meaning "I agree", "Yes, it should be fixed.". Even if 
you could hack field to act as output, output itself should function correctly.







since you skipped issue 2/ and 3/, the ones concerning union, I'm
compelled to attracd again some attention to it: those are the real
important bugs IMHO


I skipped union just 'cause I've not used it and hence have no opinion on it.



4/ field should not turn to 'null' when the matching parameterName was
not present in the request.

I'm not convinced we should change this. I suppose you need it only
because 1/ does not work.


nope, this has nothing to do with initial-values on read-only widgets,
if you handle them with 'fd:field' then it will ignore reading the
request when it's not in an enabled state

from Field.java:
public void readFromRequest(FormContext formContext) {
if (!getCombinedState().isAcceptingInputs()) {
return;
}

and if you'ld handle it through output, and use flow to set the value
there is no request reading at all:

from Output.java:
public void readFromRequest(FormContext formContext) {
// do nothing
}



actually I noticed this because of the union issues (2/ and 3/)

currently a 'fd:field' that is added through a selected case-group will
first properly initialize (and get its initial-value), and then gets
instructed to read-from-request (making no sense IMHO)

since that request couldn't be holding any value for this newly added
widget, the field changes its value back to null (cool he :-))




Given the way browsers work I believe that BooleanField is the only
exception to this. (html-checkboxes will not be present in the

Multi-value field also will not have a parameter in the request if
nothing was chosen.



ah, didn't know, thx for clarifying...

anyway, this 'multivalue' (like the  'boolean') aspect is something the
field would now, and could thus properly react upon, no?

I'm still compelled to ensure we're correctly interpreting missing
request-parameters, assuming it means 'setValue(null)' by default seems
a bit weird.  By default I think it should mean 'no change'.

(in fact that is precisely what is happening when those widgets are not
on the form because they're in a parallel union-case-group)


You are probably right, but I'm not sure. I think there were some discussion 
about skipping reading of fields missing on the template, which sounds related 
to what you are talking about.


Vadim

Re: various cforms issues

[Marc Portier]

Vadim Gritsenko wrote:
> Marc Portier wrote:
>>
>> 1/ fd:output is ignoring fd:initial-value
>> this one is quite obvious I think: anybody adding a fd:initial-value to
>> a fd:output can wait for eternity for it to ever get applied.
>>
>> Proposed fix: initialize() should do it like Field.java does.
> 
> +1

I still think the fix should be applied, but given the current
widget-states I guess the same can be achieved through a proper 'field'

> 
> 
> 

since you skipped issue 2/ and 3/, the ones concerning union, I'm
compelled to attracd again some attention to it: those are the real
important bugs IMHO

>> 4/ field should not turn to 'null' when the matching parameterName was
>> not present in the request.
> 
> I'm not convinced we should change this. I suppose you need it only
> because 1/ does not work.
> 

nope, this has nothing to do with initial-values on read-only widgets,
if you handle them with 'fd:field' then it will ignore reading the
request when it's not in an enabled state

from Field.java:
public void readFromRequest(FormContext formContext) {
if (!getCombinedState().isAcceptingInputs()) {
return;
}

and if you'ld handle it through output, and use flow to set the value
there is no request reading at all:

from Output.java:
public void readFromRequest(FormContext formContext) {
// do nothing
}



actually I noticed this because of the union issues (2/ and 3/)

currently a 'fd:field' that is added through a selected case-group will
first properly initialize (and get its initial-value), and then gets
instructed to read-from-request (making no sense IMHO)

since that request couldn't be holding any value for this newly added
widget, the field changes its value back to null (cool he :-))



> 
>> Given the way browsers work I believe that BooleanField is the only
>> exception to this. (html-checkboxes will not be present in the
> 
> Multi-value field also will not have a parameter in the request if
> nothing was chosen.
> 

ah, didn't know, thx for clarifying...

anyway, this 'multivalue' (like the  'boolean') aspect is something the
field would now, and could thus properly react upon, no?

I'm still compelled to ensure we're correctly interpreting missing
request-parameters, assuming it means 'setValue(null)' by default seems
a bit weird.  By default I think it should mean 'no change'.

(in fact that is precisely what is happening when those widgets are not
on the form because they're in a parallel union-case-group)

-marc=
-- 
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

[jira] Commented: (COCOON-556) incorrect script tags in xhtml (and missing newlines)

[JIRA]

[ 
http://issues.apache.org/jira/browse/COCOON-556?page=comments#action_12442014 ] 

Jörn Nettingsmeier commented on COCOON-556:
---

ok. in order to serve xhtml that also uses the correct xhtml namespace, one 
needs to apply post-processing anyways, since iiuc the cforms sheets produce 
tags without a ns.

> incorrect script tags in xhtml (and missing newlines)
> -
>
> Key: COCOON-556
> URL: http://issues.apache.org/jira/browse/COCOON-556
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.0.5-dev (Current CVS)
> Environment: Operating System: other
> Platform: Other
>Reporter: Ralf Hauser
> Assigned To: Cocoon Developers Team
> Attachments: cforms-avoid_empty_script_tags.diff
>
>
> When viewing the forrest myprojects sample site with xhtml, but Mozilla (Build
> 2003010808) and MSIE 6 are unable to render it properly.
> The reason appears to be
>  /> where both browsers mentioned thereafter no longer parse all subsequent 
> code
> until the next  is encountered (unfortunately this is only at the 
> very
> end of the page afer the LastModified script.).
> When serializing it as html, proper  end tags are used even if the
> script is empty like the above "breadcrumb".
> A further little nuisance is that the xhtml serializers do not add newlines
> while the regular html serializer does. The effect is that view source of
> browsers is almost unreadable and also in emacs, such source is very hard to
> look at when basically all in one line wrapped dozens of times. This, however
> doesn't seem to have impacted the rendering by the browsers.

-- 
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

[GT2006] Missing Presentations

[Vadim Gritsenko]

Hi,

Many presentations are already uploaded to the wiki [1], but some are missing. 
Any chance of getting them all up?


Jeremy, last slide of your presentation on [1] seems to be not finished. Do you 
have a complete version? :)


Gianugo, can you upload your presentation as well? With audio? If not text will 
do as well :)


Thanks,
Vadim

[1] http://wiki.apache.org/cocoon/GT2006Notes

[jira] Closed: (COCOON-556) incorrect script tags in xhtml (and missing newlines)

[JIRA]

 [ http://issues.apache.org/jira/browse/COCOON-556?page=all ]

Jörg Heinicke closed COCOON-556.


Resolution: Won't Fix

Hmm, I want to re-close this issue immediately. Sorry, but I don't want to fix 
buggy browser behavior. There was a thread about this topic on the users list 
lately: http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=116064735010872&w=4. 
So are you talking about *real* XHTML or anything that looks like XHTML or HTML 
4?

I think Cocoon behaves absolutely correct and you should not fix it in the 
source document or stylesheet at all. If you want to influence it, adapt the 
*serializer*. I know both the standard XMLSerializer and HTMLSerializer don't 
provide many possibilities to adapt their behaviour. But there are alternatives 
in the serializer block.

Another possibility is to add a further transformation step (xslt) and to add a 
non-breaking space to each empty script element. This would also prevent other 
sources of empty script elements breaking your site.

Jörg

> incorrect script tags in xhtml (and missing newlines)
> -
>
> Key: COCOON-556
> URL: http://issues.apache.org/jira/browse/COCOON-556
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.0.5-dev (Current CVS)
> Environment: Operating System: other
> Platform: Other
>Reporter: Ralf Hauser
> Assigned To: Cocoon Developers Team
> Attachments: cforms-avoid_empty_script_tags.diff
>
>
> When viewing the forrest myprojects sample site with xhtml, but Mozilla (Build
> 2003010808) and MSIE 6 are unable to render it properly.
> The reason appears to be
>  /> where both browsers mentioned thereafter no longer parse all subsequent 
> code
> until the next  is encountered (unfortunately this is only at the 
> very
> end of the page afer the LastModified script.).
> When serializing it as html, proper  end tags are used even if the
> script is empty like the above "breadcrumb".
> A further little nuisance is that the xhtml serializers do not add newlines
> while the regular html serializer does. The effect is that view source of
> browsers is almost unreadable and also in emacs, such source is very hard to
> look at when basically all in one line wrapped dozens of times. This, however
> doesn't seem to have impacted the rendering by the browsers.

-- 
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: various cforms issues

[Vadim Gritsenko]

Marc Portier wrote:


1/ fd:output is ignoring fd:initial-value
this one is quite obvious I think: anybody adding a fd:initial-value to
a fd:output can wait for eternity for it to ever get applied.

Proposed fix: initialize() should do it like Field.java does.


+1




4/ field should not turn to 'null' when the matching parameterName was
not present in the request.


I'm not convinced we should change this. I suppose you need it only because 1/ 
does not work.




Given the way browsers work I believe that BooleanField is the only
exception to this. (html-checkboxes will not be present in the


Multi-value field also will not have a parameter in the request if nothing was 
chosen.


Vadim

Re: Cocoon 2.2 build errors for cocoon-dist-samples

[Jorg Heymans]

Fred Vos wrote:

Dear developers,

This afternoon I did a fresh download of the Cocoon 2.2 trunk and tried to
build it. Unfortunately I'm getting build errors. Here's the output from
maven. I replaced the actual path to the trunk with '/path/to/cocoon/trunk':

[INFO] Generating war
/path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples.war
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error assembling WAR

Embedded error: Deployment descriptor:
/path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples/WEB-INF/web.xml
does not exist.

This cocoon-dist-samples also couses troubles on another machine where I've
tried to build cocoon earlier. After an update to the same revision as in the
previous example and a build attempt, I get the following errors:

[INFO] Assembling webapp cocoon-dist-samples in
/path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] There are at least two artifacts with the ID 'xmlParserAPIs':
xerces:xmlParserAPIs:jar:2.6.2:compile
org.apache.cocoon:cocoon-dist-samples:war:2-SNAPSHOT
org.apache.cocoon:cocoon-batik-sample:jar:1.0.0-SNAPSHOT
org.apache.cocoon:cocoon-batik-impl:jar:1.0.0-SNAPSHOT
batik:batik-ext:jar:1.6-1
xml-apis:xmlParserAPIs:jar:2.0.2
xerces:xmlParserAPIs:jar:2.6.2:compile
org.apache.cocoon:cocoon-dist-samples:war:2-SNAPSHOT
org.apache.cocoon:cocoon-forms-sample:jar:1.0.0-SNAPSHOT
org.apache.cocoon:cocoon-forms-impl:jar:1.0.0-M2-SNAPSHOT
xom:xom:jar:1.1
xerces:xmlParserAPIs:jar:2.6.2

I removed both directories ~/.m2/repository/xerces and ~/.m2/repository/xml-apis
from my local repository, since these both contain this artifact called
'xmlParserAPIs', hoping one of these was related to another project. But after
a rebuild, both directories are restored again and the problem reappears. Do
you have any clues?

Thanks for your attention,

Fred



I can't reproduce this. What does your maven commandline look like?

Jorg

[jira] Updated: (COCOON-556) incorrect script tags in xhtml (and missing newlines)

[JIRA]

 [ http://issues.apache.org/jira/browse/COCOON-556?page=all ]

Jörn Nettingsmeier updated COCOON-556:
--

Attachment: cforms-avoid_empty_script_tags.diff

please consider this for inclusion.

btw, this issue still applies to cocoon-2.1.x (svn trunk), but i could not 
figure how to edit that information.

> incorrect script tags in xhtml (and missing newlines)
> -
>
> Key: COCOON-556
> URL: http://issues.apache.org/jira/browse/COCOON-556
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.0.5-dev (Current CVS)
> Environment: Operating System: other
> Platform: Other
>Reporter: Ralf Hauser
> Assigned To: Cocoon Developers Team
> Attachments: cforms-avoid_empty_script_tags.diff
>
>
> When viewing the forrest myprojects sample site with xhtml, but Mozilla (Build
> 2003010808) and MSIE 6 are unable to render it properly.
> The reason appears to be
>  /> where both browsers mentioned thereafter no longer parse all subsequent 
> code
> until the next  is encountered (unfortunately this is only at the 
> very
> end of the page afer the LastModified script.).
> When serializing it as html, proper  end tags are used even if the
> script is empty like the above "breadcrumb".
> A further little nuisance is that the xhtml serializers do not add newlines
> while the regular html serializer does. The effect is that view source of
> browsers is almost unreadable and also in emacs, such source is very hard to
> look at when basically all in one line wrapped dozens of times. This, however
> doesn't seem to have impacted the rendering by the browsers.

-- 
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-556) incorrect script tags in xhtml (and missing newlines)

[JIRA]

 [ http://issues.apache.org/jira/browse/COCOON-556?page=all ]

Jörn Nettingsmeier reopened COCOON-556:
---

 
the problem seems to be that firefox and other browsers do not play nice with 
empty  tags when in "strict" or "standards compliant" mode. as 
described before, firefox will incorrectly parse everything after an emtpy 
 up to the next closing .

the problems in reproducing are probably caused by the reviewer not using 
namespaced xhtml output (which, strangely enough, puts browsers in quirks mode 
where they behave).

a slightly ugly but effective workaround is to add a unicode non-breaking space 
to keep the xslt transformer from collapsing the  elements. i will 
attach a patch.


> incorrect script tags in xhtml (and missing newlines)
> -
>
> Key: COCOON-556
> URL: http://issues.apache.org/jira/browse/COCOON-556
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.0.5-dev (Current CVS)
> Environment: Operating System: other
> Platform: Other
>Reporter: Ralf Hauser
> Assigned To: Cocoon Developers Team
>
> When viewing the forrest myprojects sample site with xhtml, but Mozilla (Build
> 2003010808) and MSIE 6 are unable to render it properly.
> The reason appears to be
>  /> where both browsers mentioned thereafter no longer parse all subsequent 
> code
> until the next  is encountered (unfortunately this is only at the 
> very
> end of the page afer the LastModified script.).
> When serializing it as html, proper  end tags are used even if the
> script is empty like the above "breadcrumb".
> A further little nuisance is that the xhtml serializers do not add newlines
> while the regular html serializer does. The effect is that view source of
> browsers is almost unreadable and also in emacs, such source is very hard to
> look at when basically all in one line wrapped dozens of times. This, however
> doesn't seem to have impacted the rendering by the browsers.

-- 
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-1933) [Patch] Automatic loading of flow scripts in "flow/" must not load directories

[Alexander Klimetschek (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1933?page=comments#action_12441964 
] 

Alexander Klimetschek commented on COCOON-1933:
---

Why don't use Excalibur Sources for retrieving the contents?

> [Patch] Automatic loading of flow scripts in "flow/" must not load directories
> --
>
> Key: COCOON-1933
> URL: http://issues.apache.org/jira/browse/COCOON-1933
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Alexander Klimetschek
> Attachments: cocoon-flow-only-files.patch
>
>
> The automatic loading of everything inside flow/ also tries to load 
> directories, which cannot be compiled like files. Happens typically when you 
> have a subversion directory (.svn) or other version-control directory inside.
> The stacktrace for the problem:
> Caused by: org.apache.excalibur.source.SourceNotFoundException: 
> file:/Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn/
>  doesn't exist.
> at 
> org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:150)
> at 
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.compileScript(FOM_JavaScriptInterpreter.java:502)
> at 
> org.apache.cocoon.components.flow.CompilingInterpreter$ScriptSourceEntry.getScript(CompilingInterpreter.java:112)
> at 
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:453)
> at 
> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:572)
> at 
> org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109)
> ... 43 more
> Caused by: java.io.FileNotFoundException: 
> /Users/alex/Mindquarry/hack/mindquarry-teamspace-web/mindquarry-teamspace-block/src/main/resources/COB-INF/flow/.svn
>  (No such file or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:106)
> at 
> org.apache.excalibur.source.impl.FileSource.getInputStream(FileSource.java:146)
> ... 48 more 

-- 
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] Lars Trieloff as a new Cocoon committer

[Bertrand Delacretaz]

On 10/6/06, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:

Congratulations Lars, you are elected with 21 +1s


Are you following up to get Lars' account created?

I see that his CLA has been recorded already, but I don't remember
seing the account request.

-Bertrand