Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Jason Johnston wrote: On Mon, 2005-08-01 at 16:38 +0200, Sylvain Wallez wrote: ? The fi:validation-errors element is described here: http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors Yes, sure. Where I'm lost is about knowing *what* produces this fi:validation-errors element (it's not a widget, isn't it?). I never used it, and a quick search did not revealed how it is produced. You are correct, it is not produced by anything besides the template author. It's simply a styling hint, much like fi:group, which is handled entirely by the XSLT. Ok, I see. Unfortunately this means that it is never included in the AJAX browser- update XML since there's nothing to ensure it's wrapped in a bu:update element. (Hmm, would manually wrapping it in a bu:update in the template do the trick? I wonder. Yes, wrapping it with a bu:update would definitely update it. But that would occur at each and every form roundtrip. It would definitely need an id attribute though.) Yep. I think there's a definite usefulness in having it AJAX-enabled, so perhaps it needs to be handled further upstream, e.g. in FormsTemplateTransformer. Should it become an ft-namespaced element instead like ft:validation-errors id=someId /? Thoughts? I'm willing to take a whack at putting together a patch, with guidance. AFAIU its purpose, that would be a widget that collects validation errors from a set of other widgets. Its validate() method would check the if the collected validation errors have changed, and if yes trigger the page refresh. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
[EMAIL PROTECTED] wrote: Author: ugo Date: Sat Jul 30 04:01:10 2005 New Revision: 226493 URL: http://svn.apache.org/viewcvs?rev=226493view=rev Log: Don't output div if there are no errors and give it a class attribute Ugo, Tags with an @id is an essential piece of the Ajax stuff, which is based on partial updates of page areas found by their id. Your update removes the @id on the enclosing tag, and removes the placeholder that is necessary when no error exist to later replace it by something visible if error appear. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Il giorno 01/ago/05, alle 15:24, Sylvain Wallez ha scritto: Tags with an @id is an essential piece of the Ajax stuff, which is based on partial updates of page areas found by their id. Your update removes the @id on the enclosing tag, and removes the placeholder that is necessary when no error exist to later replace it by something visible if error appear. If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Also, if this is the case, the div element should be output regardless of whether there are validation errors or not, right? Not that putting it back is a problem, I am just trying to understand. The only real issue I had was with the div not having a class attribute, but while I was at it, I tried to optimize away a useless element and an empty attribute. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Ugo Cei wrote: Il giorno 01/ago/05, alle 15:24, Sylvain Wallez ha scritto: Tags with an @id is an essential piece of the Ajax stuff, which is based on partial updates of page areas found by their id. Your update removes the @id on the enclosing tag, and removes the placeholder that is necessary when no error exist to later replace it by something visible if error appear. If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Actually, I'm a bit lost here: what template instruction or widget produces this fi:validation-errors element? Also, if this is the case, the div element should be output regardless of whether there are validation errors or not, right? Yes. Have a look at the template for fi:placeholder, which is what is produced by hidden fields in order to mark their place in the page if an event-listener changes their state. Not that putting it back is a problem, I am just trying to understand. The only real issue I had was with the div not having a class attribute, but while I was at it, I tried to optimize away a useless element and an empty attribute. I understand. But actually, they _are_ useful (in the general cases, as I don't know where validation-errors come from). Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Il giorno 01/ago/05, alle 15:57, Sylvain Wallez ha scritto: If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Actually, I'm a bit lost here: what template instruction or widget produces this fi:validation-errors element? I'm not sure where I lost you ;-). Weren't we talking about the template in forms-field-styling.xsl that I modified: xsl:template match=fi:validation-errors ? The fi:validation-errors element is described here: http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors Otherwise, it's me who's lost. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Ugo Cei wrote: Il giorno 01/ago/05, alle 15:57, Sylvain Wallez ha scritto: If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Actually, I'm a bit lost here: what template instruction or widget produces this fi:validation-errors element? I'm not sure where I lost you ;-). Weren't we talking about the template in forms-field-styling.xsl that I modified: xsl:template match=fi:validation-errors ? The fi:validation-errors element is described here: http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors Yes, sure. Where I'm lost is about knowing *what* produces this fi:validation-errors element (it's not a widget, isn't it?). I never used it, and a quick search did not revealed how it is produced. Or maybe I need new glasses... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Il giorno 01/ago/05, alle 16:38, Sylvain Wallez ha scritto: Yes, sure. Where I'm lost is about knowing *what* produces this fi:validation-errors element (it's not a widget, isn't it?). I never used it, and a quick search did not revealed how it is produced. It's not produced. You have to put it yourself in your form template, if you want to display all your validation errors in a single block. At least according to http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors. And it works as expected, too, in the ajax=false case. Now, what you're telling me is that for it to be correctly show up in the ajax=true case, the resulting HTML element must have an id attribute. Then, since the original template did something like: xsl:template match=fi_validation-errors div id=[EMAIL PROTECTED] ... you need to put something like fi:validation-errors id=whatever/ in the form template. Is that right? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
On Mon, 2005-08-01 at 16:38 +0200, Sylvain Wallez wrote: ? The fi:validation-errors element is described here: http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors Yes, sure. Where I'm lost is about knowing *what* produces this fi:validation-errors element (it's not a widget, isn't it?). I never used it, and a quick search did not revealed how it is produced. You are correct, it is not produced by anything besides the template author. It's simply a styling hint, much like fi:group, which is handled entirely by the XSLT. Unfortunately this means that it is never included in the AJAX browser- update XML since there's nothing to ensure it's wrapped in a bu:update element. (Hmm, would manually wrapping it in a bu:update in the template do the trick? I wonder. It would definitely need an id attribute though.) I think there's a definite usefulness in having it AJAX-enabled, so perhaps it needs to be handled further upstream, e.g. in FormsTemplateTransformer. Should it become an ft-namespaced element instead like ft:validation-errors id=someId /? Thoughts? I'm willing to take a whack at putting together a patch, with guidance. --Jason
