[jira] Created: (COCOON-2219) springRequestContextFilter
springRequestContextFilter -- Key: COCOON-2219 URL: https://issues.apache.org/jira/browse/COCOON-2219 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2 Reporter: Barbara Slupik Priority: Minor There is a problem with running cocoon application in tomcat. The symptoms are that for some requests it just stops and does not do anything. I had it with tomcat authentication when tomcat was trying to call login page in my application. Other users reported similar problems. I think that the problem happens when tomcat is trying to access cocoon application. The problem seems to affect tomcat only, everything works fine with jetty. The problem can be fixed by adding this: filter filter-namespringRequestContextFilter/filter-name filter-classorg.springframework.web.filter.RequestContextFilter/filter-class /filter filter-mapping filter-namespringRequestContextFilter/filter-name url-pattern/*/url-pattern dispatcherFORWARD/dispatcher dispatcherREQUEST/dispatcher /filter-mapping to the application web.xml file. Perhaps it can be added to default application web.xml which is generated with mvn archetype:create? The change does not seem to affect jetty in any way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Client-side validation in CForms
Dear Kamal Many thanks for your response. On 9 Jul 2008, at 23:18, Kamal Bhatt wrote: Jeremy Quinn wrote: Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) On re-examination, the list of validators that could have an equivalent client-side validator auto-generated is probably shorter . as I am not sure ATM how to implement the expressions possible in some of them . eg. assert, length, range etc. Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. Yes, this is an issue that needs addressing. However, there may be an answer . both Cocoon and Dojo are i18n capable, even though they both use different i18n catalogue formats, Cocoon i18n files could be provided to Dojo via a special transformation. Or maybe I am still being naive ; ) The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. Could you expand on what you mean by a hook function? That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? thanks regards Jeremy
[OT] Side project: GuitarToolkit for iPhone
Hello all, We've been working on a fun side project, check out the screencast here: http://guitartoolkit.com/ If you like what you see, feel free to digg it over here: http://digg.com/apple/GuitarToolkit_Essential_guitar_utilities_on_your_iPhone GuitarToolkit is already available on the iTunes App Store for those of you who have managed to get the 2.0 iPhone OS -- be the first Cocoon developer to write a review! ;-) Thanks everyone! Jack Ivers Agile Partners http://agilepartners.com
[jira] Assigned: (COCOON-1822) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms
[ https://issues.apache.org/jira/browse/COCOON-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-1822: Assignee: Antonio Gallardo MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms Key: COCOON-1822 URL: https://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Simone Gianni Assignee: Antonio Gallardo Priority: Critical Attachments: dojo-doublelist_patch.tar.gz The multi value field with fi:styling list-type=double-listbox relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : xsl:choose xsl:when test=@ajax = 'true' xsl:attribute name=dojoTypeCFormsForm/xsl:attribute xsl:if test=@ajax = 'true' script type=text/javascriptcocoon.forms.ajax = true;/script /xsl:if /xsl:when xsl:otherwise xsl:attribute name=onsubmitforms_onsubmit(); xsl:value-of select=@onsubmit//xsl:attribute /xsl:otherwise /xsl:choose I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1822) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms
[ https://issues.apache.org/jira/browse/COCOON-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612678#action_12612678 ] Antonio Gallardo commented on COCOON-1822: -- Patch applied to 2.1.12-dev. MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms Key: COCOON-1822 URL: https://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Simone Gianni Assignee: Antonio Gallardo Priority: Critical Attachments: dojo-doublelist_patch.tar.gz The multi value field with fi:styling list-type=double-listbox relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : xsl:choose xsl:when test=@ajax = 'true' xsl:attribute name=dojoTypeCFormsForm/xsl:attribute xsl:if test=@ajax = 'true' script type=text/javascriptcocoon.forms.ajax = true;/script /xsl:if /xsl:when xsl:otherwise xsl:attribute name=onsubmitforms_onsubmit(); xsl:value-of select=@onsubmit//xsl:attribute /xsl:otherwise /xsl:choose I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Client-side validation in CForms
Jeremy Quinn wrote: Dear Kamal Many thanks for your response. On 9 Jul 2008, at 23:18, Kamal Bhatt wrote: Jeremy Quinn wrote: Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) On re-examination, the list of validators that could have an equivalent client-side validator auto-generated is probably shorter . as I am not sure ATM how to implement the expressions possible in some of them . eg. assert, length, range etc. Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. Yes, this is an issue that needs addressing. However, there may be an answer . both Cocoon and Dojo are i18n capable, even though they both use different i18n catalogue formats, Cocoon i18n files could be provided to Dojo via a special transformation. Or maybe I am still being naive ; ) I don't know enough about i18n to say. The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. Could you expand on what you mean by a hook function? When you get a client side error, you pass information to a function that will indicate what the error is and the field it is associated with. This function will then manipulate the HTML to give you the effect you want (new class, change in the tabbing, etc...). Maybe this doesn't quite work with Dojo, I don't know. That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? thanks regards Jeremy -- Kamal Bhatt
