cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamal <>
Subject Re: [2.2] CForms - div around group and other Cforms issues
Date Sun, 27 Apr 2008 14:20:05 GMT
Grzegorz Kossakowski wrote:
> Kamal pisze:
>> I put the patch in:,
>> 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:
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.

>>>> 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:
For additional commands, e-mail:

View raw message