Validation issues with dinamically rendered controls

[GoogleCodeExporter]

What steps will reproduce the problem?
http://code.google.com/p/prado3/issues/detail?id=181#c14
What is the expected output? What do you see instead?

I'm opening this ticket because this is a separate issue. Will investigate in 
detail.

I've already found a workaround, but will try to come up with a fix for it. The 
workaround is to add a 

  <com:TCustomValidator ControlToValidate="Page" ValidationGroup="DummyValidationGroup" />

control to the _fixed_ or by default visible are of your page. This dummy 
validator won't ever be actually used by the client-side (so it won't interfere 
with anything and won't ever fail), but it will ensure that you won't get the 

 Form 'undefined' is not registered with Prado.Validation

JavaScript exception (described in the linked OP) when trying to issue 
callbacks on the page.

Original issue reported on code.google.com by google...@pcforum.hu on 13 Jul 2011 at 3:35

[GoogleCodeExporter]

"by default visible are of your page" = "by default visible _area_ of your page"

Original comment by google...@pcforum.hu on 13 Jul 2011 at 3:54

[GoogleCodeExporter]

OK, I found the problem. TBaseValidator obviously rendered the client script 
validator (in its registerClientScriptValidator() method) regardless of whether 
the control was actually visible, but did not do so with the validation manager 
itself, which was only constructed if there was at least one validator actually 
visible and rendered during generation of the page. 

That meant, that when you had some validators on your page, but none of them 
was visible initially, then you'd get the above described client-side 
exception, because of the missing registration of the validation manager for 
the main form.

The fix was simply to make sure that both the invidual client script 
registrations for each validator and the creation/registration of the 
validation manager itself happens at the same place, under the same conditions. 
I move them to a new registerClientScripts() method which is called from the 
OnPreRender() method for now. If issue 348 will be resolved, the call can be 
moved to the ::render() method, thus preventing unneccessary inclusion of the 
validation3.js script when no validation is actually needed yet.

Fixed TBaseValidator attached.

Original comment by google...@pcforum.hu on 13 Jul 2011 at 4:24

Attachments:

• prado-issue-347-fix.zip

[GoogleCodeExporter]

> If issue 348 will be resolved, the call can be moved to the ::render() 
method, thus preventing unneccessary inclusion of the validation3.js script 
when no validation is actually needed yet.

If one would make a control and its validator visible in callback, should not 
validation3.js be included to make it work?

Original comment by uaca...@gmail.com on 13 Jul 2011 at 8:45

[GoogleCodeExporter]

I just explained in issue 348, that extra scripts required by dynamically added 
controls (or controls initially not visible, but made visible later) are not 
loaded at all by Prado in callbacks (yet), which is a major flaw. Until that 
issue is fixed, inclusion of validation3.js (through a 
TClientScriptManager::registerPradoScript('validator') call) can't be move to 
code that's called only then if/when the control is visible, as that would mean 
that if there are validators on the page, but none of them is initially 
visible, they couldn't function when made visible either (because of 
validation3.js not being loaded properly in callbacks when needed).

Even with this implementation you can run into issue 348, but only then if you 
have no validator controls at all on your page initially (not even hidden 
ones), and create them only dynamically. In this situation validator3.js will 
be omitted from the original <script> references in the page, and won't be 
obviously loaded from the callbacks where they are being added to the control 
tree either because of issue 348, thus leading to validators not working at all 
on the client-side.

(This bug of course doesn't affect server-side validation, only 
"pre-validation" on the client side, even though with the missing validator3.js 
Prado will raise missing class exceptions on the client-side, thus leading to 
unpredictable behaviour in the browser, and to probably falling back to use of 
postbacks instead of callbacks, to handle control actions, where available.)

Original comment by google...@pcforum.hu on 13 Jul 2011 at 11:06

[GoogleCodeExporter]

after pushing yout patch for #348 i made some tests on callback-generated 
validators and they seems to work now even not applying your patch for #347 
(the ValidationManager gets correctly initialized on callback). I've attached 
my testcase, does it work for you, too?

Original comment by ctrlal...@gmail.com on 16 Jul 2011 at 10:49

Attachments:

• testcase_347.tar.gz

[GoogleCodeExporter]

Issue 242 has been merged into this issue.

Original comment by ctrlal...@gmail.com on 16 Jul 2011 at 10:47

[GoogleCodeExporter]

Closing after 4 months as invalid.

Original comment by ctrlal...@gmail.com on 19 Nov 2011 at 5:06

• Changed state: Invalid