Unregister clientside validators from manager if container of validator becomes invisible after callback

[GoogleCodeExporter]

What steps will reproduce the problem?
- add TValidationSummary to TActivePanel
- add TPanel to TActivePanel
- add TTextBox & TRequiredFieldValidator to TPanel
- add TActiveLinkButton with CausesValidation=true to TActivePanel
- add TActiveLinkButton with CausesValidation=false to TActivePanel

- click TActiveLinkButton with CausesValidation=true => TValidationSummary
will be displayed
- click TActiveLinkButton with CausesValidation=false and set
TPanel.Visibile=false on callback

What is the expected output?
No validation message is displayed

What do you see instead?
Validation message is shown.

Solution:
Unregister clientside validators from manager if container of validator
becomes invisible after callback

Original issue reported on code.google.com by GODZilla...@gmail.com on 4 Nov 2009 at 10:00

[GoogleCodeExporter]

It would be probably easier to do the opposite, ie. ask the client side manager 
/ 
registry itself - after an update - to validate each and every validator it has 
registered. This could be done by forcing each rendered and active validator to 
emit 
a <span> with a unique id in-place into the page code, and then asking the 
registry 
to look up the id's of each of it's registered validator in the DOM. If it 
can't 
find any elements with the specified id, it should dispose of the validator 
previously registered into it, as the validator is no more part of the page (or 
is 
disabled).

Just an idea.

Original comment by google...@pcforum.hu on 6 Nov 2009 at 7:36

[GoogleCodeExporter]

Nice idea - much more elegant and more performant on the server side - thanks :D

Original comment by GODZilla...@gmail.com on 6 Nov 2009 at 8:18

[GoogleCodeExporter]

I don't fully get the problem.. since TPanel can't be updated in callback, the 
validators will stay visible. But just calling TActivePanel:.render() in the 
callback would refresh the clientside and clear the validators.
But maybe i just misunderstoodt the issue.. I'm attaching my testcase

Original comment by ctrlal...@gmail.com on 16 Nov 2011 at 9:52

Attachments:

• Home.page
• Home.php

[GoogleCodeExporter]

Since the issue based on an older version of trunk (i guess 3.1.7) and you 
recently did a lot of active control related commits, maybe the issue can be 
set to invalid.
But i'll try to reproduce the problem next weekend to verify if it still exist 
and give you feedback.

Original comment by GODZilla...@gmail.com on 17 Nov 2011 at 7:15

[GoogleCodeExporter]

Hmm, i'm unable to reproduce the problem too. It seems your work on active 
controls already fix the problem. :)
Therefor i suggest to set issue state to invalid!? 
If the problem occur again, we could re-open the ticket.

Original comment by GODZilla...@gmail.com on 20 Nov 2011 at 6:48

[GoogleCodeExporter]

thank you for your feedback

Original comment by ctrlal...@gmail.com on 20 Nov 2011 at 9:03

• Changed state: Invalid