You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Kamal <bh...@tt.com.au> on 2008/04/27 10:29:59 UTC
[2.2] CForms - div around group and other Cforms issues
Hi,
I have been struggling with CForms, trying to work out what I did wrong.
I think I found a couple of bugs in CForms.
I have a form that dynamically reveal sets of fields based on whether a
tick box has been checked. Because I was using a very old version of
CForms (2.1.7), I couldn't use the group method, so I had to reveal/hide
each field separately. I found out that this approach is not compatible
with CForms + Ajax because the labels are not updated. Also, the Cocoon
website says to put a div around all fields in a ft:group for Ajax. I
did this, but it kept failing. I had a look at the code and I found this:
<xsl:template match="fi:group[@id and count(*) = 1 and not(fi:*)]">
<xsl:apply-templates mode="copy-parent-id"/>
</xsl:template>
<xsl:template match="fi:group">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="fi:group" mode="copy-parent-id">
<xsl:copy>
<xsl:attribute name="id"><xsl:value-of
select="../@id"/></xsl:attribute>
<xsl:copy-of select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
I changed it to this:
<!--+
| fi:group - has no visual representation by default
| If the fi:group contains an id and has only one child that is
not in the fi: namespace,
| then copy the id to the child. This is needed for ajax when
grouping is just used to group
| widgets.
+-->
<xsl:template match="fi:group[@id and count(*) = 1 and not(fi:*)]">
<xsl:apply-templates mode="copy-parent-id"/>
</xsl:template>
<xsl:template match="fi:group">
<xsl:apply-templates/>
</xsl:template>
*<xsl:template match="*" mode="copy-parent-id"> *
<xsl:copy>
<xsl:attribute name="id"><xsl:value-of
select="../@id"/></xsl:attribute>
<xsl:copy-of select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
and it all works. Is my fix correct? If so, should I create a patch
and/or Jira ticket?'
Also, the booleanfield no longer works the way it used to in 2.1.
Namely, I used to be able to do this:
if (widget.value == 'false')
{
// Do something.
}
Now, it is returning a Boolean object (maybe it always did, I don't
know) and I now have to do this:
if (widget.value.toString().equals('false'))
Any thoughts? Is it a good idea to return a string instead?
Finally, my previous post (BTW, sorry for all the emails) mentioned
javascript files that are missing/in the wrong spot. I had a look at the
logs and these files are still being requested, but they are not
impacting on the rendering of the page. However, for the life of me, I
cannot find the references to these files on my page.
Also, I know we have an ongoing issue with tabs and validation errors
not working. I was wondering about the rationale for not using
bu:replace on the appropriate divs to fix these issues?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms - div around group and other Cforms issues
Posted by Kamal <bh...@tt.com.au>.
Kamal wrote:
> Grzegorz Kossakowski wrote:
>> Kamal pisze:
>>>
>>> I put the patch in: https://issues.apache.org/jira/browse/COCOON-2204,
>>>
>>> However, as I mention in the issue, this has been registered
>>> previously, and probably one of our issues should be closed
>>> (considering the advice given above, I am thinking the other issue
>>> needs to be closed).
>>>
>>> Now, because of the nature of the bug and the previous JIRA issue, I
>>> am not certain if I have correctly diagnosed the problem. Now the
>>> JIRA issue is up, hopefully, someone can confirm.
>>
>> I'll try to have a look.
>>
>>>> if (widget.value == false)
>>> Hmmm... Thanks, that worked. Trust me to choose the most convoluted
>>> solution first :) I guess the question is this a Rhino bug? My
>>> inclination is yes, because in the browser "if (widget.value ==
>>> 'false')" should work, right?
>>
>> I'm not a Javascript expert but I guess you are right that it may be
>> a Rhino bug. Reporting this to Rhino folks wouldn't hurt.
>>
>>> Yes, because firebug tells me they are (or aren't). Actually, after
>>> I put the i18n transformer in (that is what I meant by enabling
>>> i18n), they have changed:
>>>
>>>
>>> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi/manifest.js
>>>
>>> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi.js
>>> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js
>>>
>>>
>>> Now, as you may know, I am not following the rules regarding blocks
>>> (ie I am using mounts, see previous posts), so I am more than
>>> willing to accept responsibility for this. FYI, I cannot see any
>>> discernable functional issue with them not being there.
>>
>> Before we start to dig into issue I would like to ask you if you have
>> followed this instructions:
>> http://cocoon.apache.org/2.2/blocks/forms/1.0/1351_1_1.html
> Actually, there is one thing at the end of that that I may not have
> done (the servletLinkWriter transformer). When I am less tired. I
> will have a look.
>
> Thanks.
>
OK, I tried this. The issue still persist. Also, I might add, there
seems to be small contradiction the page you mention and this page:
http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html .
Namely, there is no mention of the servletLinkRewriter or the far more
complex serialisation step.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms - div around group and other Cforms issues
Posted by Kamal <bh...@tt.com.au>.
Grzegorz Kossakowski wrote:
> Kamal pisze:
>>
>> I put the patch in: https://issues.apache.org/jira/browse/COCOON-2204,
>>
>> However, as I mention in the issue, this has been registered
>> previously, and probably one of our issues should be closed
>> (considering the advice given above, I am thinking the other issue
>> needs to be closed).
>>
>> Now, because of the nature of the bug and the previous JIRA issue, I
>> am not certain if I have correctly diagnosed the problem. Now the
>> JIRA issue is up, hopefully, someone can confirm.
>
> I'll try to have a look.
>
>>> if (widget.value == false)
>> Hmmm... Thanks, that worked. Trust me to choose the most convoluted
>> solution first :) I guess the question is this a Rhino bug? My
>> inclination is yes, because in the browser "if (widget.value ==
>> 'false')" should work, right?
>
> I'm not a Javascript expert but I guess you are right that it may be a
> Rhino bug. Reporting this to Rhino folks wouldn't hurt.
>
>> Yes, because firebug tells me they are (or aren't). Actually, after I
>> put the i18n transformer in (that is what I meant by enabling i18n),
>> they have changed:
>>
>>
>> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi/manifest.js
>>
>> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi.js
>> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js
>>
>>
>> Now, as you may know, I am not following the rules regarding blocks
>> (ie I am using mounts, see previous posts), so I am more than willing
>> to accept responsibility for this. FYI, I cannot see any discernable
>> functional issue with them not being there.
>
> Before we start to dig into issue I would like to ask you if you have
> followed this instructions:
> http://cocoon.apache.org/2.2/blocks/forms/1.0/1351_1_1.html
Actually, there is one thing at the end of that that I may not have
done (the servletLinkWriter transformer). When I am less tired. I will
have a look.
Thanks.
>
>>>> Also, I know we have an ongoing issue with tabs and validation
>>>> errors not working. I was wondering about the rationale for not
>>>> using bu:replace on the appropriate divs to fix these issues?
>>>
>>> Can you elaborate here?
>> In non-ajax mode, if you have a validation error on a particular tab,
>> the tab will have a little icon indicating a validation error. This
>> icon does not appear in ajax mode because (from my understanding) it
>> is not wrapped in an appropriate bu:replace tag. Similarly for
>> validation-errors. I have discussed this previously[1] (as have
>> others [2]), and the issue remains unresolved [3]. I might add, that
>> in [1] I came up with a really dodgy hack to get around this problem,
>> but I am assuming that hack would have been univerally frowned upon
>> (basically, I turned off ajax for submisson). I guess a less dodgy
>> solution (hack?) is to put bu:replace tags into those divs, but I no
>> one seems to have done this, so I am assuming it is frowned upon. I
>> want clarification as why.
>
> Ah, I see. The problem in its core is that bu:replace tags are being
> generated by JX macros for Forms and fi:validation-errors are handled
> by XSLs. If you are in AJAX mode, everything that is outside
> bu:replace tags is being stripped of so XSLs won't handle them. The
> same goes for validation errors on particular tab.
>
> I'm not sure what should be the best solution but since I'll be
> playing with Forms quite heavily these days I'll think about this
> problem too.
>
Right now, for the validation-errors, I am hard coding the bu:replace.
Also, what generates the bu:replace tags for all the widgets?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms - div around group and other Cforms issues
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Kamal pisze:
>
> I put the patch in: https://issues.apache.org/jira/browse/COCOON-2204,
>
> However, as I mention in the issue, this has been registered previously,
> and probably one of our issues should be closed (considering the advice
> given above, I am thinking the other issue needs to be closed).
>
> Now, because of the nature of the bug and the previous JIRA issue, I am
> not certain if I have correctly diagnosed the problem. Now the JIRA
> issue is up, hopefully, someone can confirm.
I'll try to have a look.
>> if (widget.value == false)
> Hmmm... Thanks, that worked. Trust me to choose the most convoluted
> solution first :) I guess the question is this a Rhino bug? My
> inclination is yes, because in the browser "if (widget.value ==
> 'false')" should work, right?
I'm not a Javascript expert but I guess you are right that it may be a Rhino bug. Reporting this to
Rhino folks wouldn't hurt.
> Yes, because firebug tells me they are (or aren't). Actually, after I
> put the i18n transformer in (that is what I meant by enabling i18n),
> they have changed:
>
>
> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi/manifest.js
> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi.js
> http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js
>
>
> Now, as you may know, I am not following the rules regarding blocks (ie
> I am using mounts, see previous posts), so I am more than willing to
> accept responsibility for this. FYI, I cannot see any discernable
> functional issue with them not being there.
Before we start to dig into issue I would like to ask you if you have followed this instructions:
http://cocoon.apache.org/2.2/blocks/forms/1.0/1351_1_1.html
>>> Also, I know we have an ongoing issue with tabs and validation errors
>>> not working. I was wondering about the rationale for not using
>>> bu:replace on the appropriate divs to fix these issues?
>>
>> Can you elaborate here?
> In non-ajax mode, if you have a validation error on a particular tab,
> the tab will have a little icon indicating a validation error. This icon
> does not appear in ajax mode because (from my understanding) it is not
> wrapped in an appropriate bu:replace tag. Similarly for
> validation-errors. I have discussed this previously[1] (as have others
> [2]), and the issue remains unresolved [3]. I might add, that in [1] I
> came up with a really dodgy hack to get around this problem, but I am
> assuming that hack would have been univerally frowned upon (basically, I
> turned off ajax for submisson). I guess a less dodgy solution (hack?) is
> to put bu:replace tags into those divs, but I no one seems to have done
> this, so I am assuming it is frowned upon. I want clarification as why.
Ah, I see. The problem in its core is that bu:replace tags are being generated by JX macros for
Forms and fi:validation-errors are handled by XSLs. If you are in AJAX mode, everything that is
outside bu:replace tags is being stripped of so XSLs won't handle them. The same goes for validation
errors on particular tab.
I'm not sure what should be the best solution but since I'll be playing with Forms quite heavily
these days I'll think about this problem too.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms - div around group and other Cforms issues
Posted by Kamal <bh...@tt.com.au>.
>> <xsl:template match="fi:group[@id and count(*) = 1 and not(fi:*)]">
>> <xsl:apply-templates mode="copy-parent-id"/>
>> </xsl:template>
>>
>> <xsl:template match="fi:group">
>> <xsl:apply-templates/>
>> </xsl:template>
>>
>> <xsl:template match="fi:group" mode="copy-parent-id"> <xsl:copy>
>> <xsl:attribute name="id"><xsl:value-of
>> select="../@id"/></xsl:attribute>
>> <xsl:copy-of select="@*"/>
>> <xsl:apply-templates/>
>> </xsl:copy>
>> </xsl:template>
>>
>> I changed it to this:
>>
>> <!--+
>> | fi:group - has no visual representation by default
>> | If the fi:group contains an id and has only one child that is
>> not in the fi: namespace,
>> | then copy the id to the child. This is needed for ajax when
>> grouping is just used to group
>> | widgets.
>> +-->
>> <xsl:template match="fi:group[@id and count(*) = 1 and not(fi:*)]">
>> <xsl:apply-templates mode="copy-parent-id"/>
>> </xsl:template>
>>
>> <xsl:template match="fi:group">
>> <xsl:apply-templates/>
>> </xsl:template>
>>
>> *<xsl:template match="*" mode="copy-parent-id"> * <xsl:copy>
>> <xsl:attribute name="id"><xsl:value-of
>> select="../@id"/></xsl:attribute>
>> <xsl:copy-of select="@*"/>
>> <xsl:apply-templates/>
>> </xsl:copy>
>> </xsl:template>
>>
>> and it all works. Is my fix correct? If so, should I create a patch
>> and/or Jira ticket?'
>
> Yep, creating issue in JIRA is the best option. If you attach a patch,
> could you please provide a more detailed explanation why you need
> match="*" here? I'm not sure if I understand your problem correctly.
I put the patch in: https://issues.apache.org/jira/browse/COCOON-2204,
However, as I mention in the issue, this has been registered previously,
and probably one of our issues should be closed (considering the advice
given above, I am thinking the other issue needs to be closed).
Now, because of the nature of the bug and the previous JIRA issue, I am
not certain if I have correctly diagnosed the problem. Now the JIRA
issue is up, hopefully, someone can confirm.
>
> Returning a String is not a good idea for several reasons (e.g. API
> change).
You are probably right.
>
> Have you tried:
>
> if (widget.value == false)
Hmmm... Thanks, that worked. Trust me to choose the most convoluted
solution first :) I guess the question is this a Rhino bug? My
inclination is yes, because in the browser "if (widget.value ==
'false')" should work, right?
> Are you sure that request for these files are coming from browser and
> not from a block?
Yes, because firebug tells me they are (or aren't). Actually, after I
put the i18n transformer in (that is what I meant by enabling i18n),
they have changed:
http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi/manifest.js
http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi.js
http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js
Now, as you may know, I am not following the rules regarding blocks (ie
I am using mounts, see previous posts), so I am more than willing to
accept responsibility for this. FYI, I cannot see any discernable
functional issue with them not being there.
>
>> Also, I know we have an ongoing issue with tabs and validation errors
>> not working. I was wondering about the rationale for not using
>> bu:replace on the appropriate divs to fix these issues?
>
> Can you elaborate here?
In non-ajax mode, if you have a validation error on a particular tab,
the tab will have a little icon indicating a validation error. This icon
does not appear in ajax mode because (from my understanding) it is not
wrapped in an appropriate bu:replace tag. Similarly for
validation-errors. I have discussed this previously[1] (as have others
[2]), and the issue remains unresolved [3]. I might add, that in [1] I
came up with a really dodgy hack to get around this problem, but I am
assuming that hack would have been univerally frowned upon (basically, I
turned off ajax for submisson). I guess a less dodgy solution (hack?) is
to put bu:replace tags into those divs, but I no one seems to have done
this, so I am assuming it is frowned upon. I want clarification as why.
[1] http://www.nabble.com/Tabs-and-CForms-td13222772.html
[2] http://marc.info/?l=xml-cocoon-dev&m=117269621604981&w=2
[3] https://issues.apache.org/jira/browse/COCOON-1570
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [2.2] CForms - div around group and other Cforms issues
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Kamal pisze:
> Hi,
> I have been struggling with CForms, trying to work out what I did wrong.
> I think I found a couple of bugs in CForms.
>
> I have a form that dynamically reveal sets of fields based on whether a
> tick box has been checked. Because I was using a very old version of
> CForms (2.1.7), I couldn't use the group method, so I had to reveal/hide
> each field separately. I found out that this approach is not compatible
> with CForms + Ajax because the labels are not updated. Also, the Cocoon
> website says to put a div around all fields in a ft:group for Ajax. I
> did this, but it kept failing. I had a look at the code and I found this:
>
> <xsl:template match="fi:group[@id and count(*) = 1 and not(fi:*)]">
> <xsl:apply-templates mode="copy-parent-id"/>
> </xsl:template>
>
> <xsl:template match="fi:group">
> <xsl:apply-templates/>
> </xsl:template>
>
> <xsl:template match="fi:group" mode="copy-parent-id"> <xsl:copy>
> <xsl:attribute name="id"><xsl:value-of
> select="../@id"/></xsl:attribute>
> <xsl:copy-of select="@*"/>
> <xsl:apply-templates/>
> </xsl:copy>
> </xsl:template>
>
> I changed it to this:
>
> <!--+
> | fi:group - has no visual representation by default
> | If the fi:group contains an id and has only one child that is not
> in the fi: namespace,
> | then copy the id to the child. This is needed for ajax when
> grouping is just used to group
> | widgets.
> +-->
> <xsl:template match="fi:group[@id and count(*) = 1 and not(fi:*)]">
> <xsl:apply-templates mode="copy-parent-id"/>
> </xsl:template>
>
> <xsl:template match="fi:group">
> <xsl:apply-templates/>
> </xsl:template>
>
> *<xsl:template match="*" mode="copy-parent-id"> * <xsl:copy>
> <xsl:attribute name="id"><xsl:value-of
> select="../@id"/></xsl:attribute>
> <xsl:copy-of select="@*"/>
> <xsl:apply-templates/>
> </xsl:copy>
> </xsl:template>
>
> and it all works. Is my fix correct? If so, should I create a patch
> and/or Jira ticket?'
Yep, creating issue in JIRA is the best option. If you attach a patch, could you please provide a
more detailed explanation why you need match="*" here? I'm not sure if I understand your problem
correctly.
> Also, the booleanfield no longer works the way it used to in 2.1.
> Namely, I used to be able to do this:
>
> if (widget.value == 'false')
> {
> // Do something.
> }
>
> Now, it is returning a Boolean object (maybe it always did, I don't
> know) and I now have to do this:
>
> if (widget.value.toString().equals('false'))
>
> Any thoughts? Is it a good idea to return a string instead?
Returning a String is not a good idea for several reasons (e.g. API change). I guess that the
changed behavior may come from the upgraded Rhino version.
Have you tried:
if (widget.value == false)
?
> Finally, my previous post (BTW, sorry for all the emails) mentioned
> javascript files that are missing/in the wrong spot. I had a look at the
> logs and these files are still being requested, but they are not
> impacting on the rendering of the page. However, for the life of me, I
> cannot find the references to these files on my page.
Are you sure that request for these files are coming from browser and not from a block?
> Also, I know we have an ongoing issue with tabs and validation errors
> not working. I was wondering about the rationale for not using
> bu:replace on the appropriate divs to fix these issues?
Can you elaborate here?
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org