cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamal <bh...@tt.com.au>
Subject Re: [2.2] CForms - div around group and other Cforms issues
Date Sun, 27 Apr 2008 12:44:15 GMT

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


Mime
View raw message