Regula Validation

[abed alrahman Almkhieber]

Hi,
I want to apply Regula in my case.But I wonder if it can be applied to html elements that is not form neither form input?
Take this case,

•  A table used for data entry.
• This table has two columns.
• In the first one,every cell contains "<input type='text'>".
• In the second one,every cell contains jquery plugin replacement for the select.
• for every row,the user type some data in the first cell and select some option in the other.
• After finishing the user asks for saving entries.
• The system tries to validate every cell.
• and then apply a validation on the whole table.

Note that

• Not all cell elements are form inputs(the second column).
  
• The table is not contained in a from.
  

So this is my case??Any help...

[Troy Ingram]

* Regula does not care if your input fields are wrapped with a form or not.

* Third party input controls will boil down to plain input fields when they get rendered on the page.  The tricky part is to find a way to inject the Regula constraints after the controls have been rendered.  You may be able to do this through options on the control, or you may have to run your own script after the control is rendered to find it and inject the constraints   You will also need to bind Regula to the new controls after you inject the constraints.  Also note that some controls will destroy and recreate its rendered parts under certain scenarios.  You would need to manage those states and update the Regula bindings accordingly.

--
You received this message because you are subscribed to the Google Groups "Regula" group.
To unsubscribe from this group and stop receiving emails from it, send an email to regula-validat...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Vivin Paliath]

(Google didn't post my reply to the group so I'm re-posting it here)

You are only able to apply regula validation-constraints to input elements. This is because input elements have a well-defined way for value retrieval. This is not the case for other DOM elements. This is why I made the restriction because it doesn't make sense to define a "value" for a div or a table. 

For your case, I can suggest the following:

• Attach the constraints on the un-decorated SELECT element. I am assuming that the jQuery plugin decorates an existing SELECT element. So if this is the case, you should be able to attach the constraints to that element.
• If you are unable to attach it on the SELECT, or if there is no SELECT element, perhaps you can include an INPUT element of type HIDDEN which contains the value that is selected from the jQuery plugin. Regula constraints can then be attached to this INPUT element.

I don't quite follow what you mean by validating the "entire" table. In any case, you should be able to wrap the table in FORM tags and that shouldn't alter your presentation. So you should be able to attach a form-specific constraint to the form. Hope this helps!

Vivin

[Vivin Paliath]

(Google Groups didn't post my message here to the group, so re-posting it here)

Hello Abed,

Correct. For a custom constraint, theoretically a developer could do whatever he/she wanted, because he/she provides the validator. However, allowing custom constraints to be attached to non-input and non-form elements would create a difference in the way default and custom constraints behave. One of the hallmarks of a good API is orthogonality; making custom constraints work on non-form and non-input elements would violate that principle. It also violates the "principle of least surprise". Secondly, adding that sort of functionality to custom constraints also creates inconsistencies in the behavior between default and custom constraints, which is extremely undesirable in an API.

Another reason is the 80/20 rule. 80% of the users use 20% of the features. Most people are not going to want to attach constraints to non-form and non-input elements; it is a very rare use-case, and so in addition to the reasons mentioned above, it doesn't make sense to spend development cycles on a feature that not many people are going to be use, especially if such a feature is going to be a bit of a maintenance nightmare and would also make the API more confusing.

Hope this helps! :)

Vivin

On Wed, Mar 6, 2013 at 1:53 AM, abed alrahman Almkhieber <REDACTED> wrote:

Hello Vivin,
Thanks a lot for your help.I agree with you:

This is because input elements have a well-defined way for value retrieval

for INPUT,SELECT and TEXTAREA when constraint is predefined.But for custom constraint,it's the developer responsibility to define the logic of retrieving the value.

On Tuesday, March 5, 2013 1:52:42 AM UTC-7, abed alrahman Almkhieber wrote:

[abed alrahman Almkhieber]

Just to be clear:
I meant by

and then apply a validation on the whole table.

and by

 The table is not contained in a from.

That there is some sort of validation don't belong to a certain element but to many elements in the table.This sort of validation -in Regula- now is named form constraint.To apply this sort of validation,you have to wrap the table with a form and add your custom constraint to it.