Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Go to End


6 Posts   979 Views

Avatar
mi32dogs

Community Member, 75 Posts

8 March 2015 at 11:28am

Hi, I’m new to silverstripe, and I’m trying to evaluate if I want to use silverstripe for my next projects.

I love it so far but I’m running into a problem with the DataObject validation. I have to build a lot of DataObjects (and building them so far is great and fast) but I need a way to validate everything that the customer is going to input. So far I have found that you can use the getCMSValidator to set the required fields but that is it.

I have seen some people extend the RequiredFields class I will have to do that of every time I build a new DataObject (I have about 25 of them).

Is there a way to validate dataobjects preferable client side with something similar to jQuery.Validate or if that is not an option something that is reusable? So you have a RequiredFields class and a UniqueFields class etc.

Thanks

Avatar
Pyromanik

Community Member, 419 Posts

8 March 2015 at 11:50am

Edited: 08/03/2015 11:52am

It depends on what you mean by 'validate'.
But it sounds like you want to ensure that numbers are number, and emails are emails (as per your 'frontend' comment).

This is all built in. Simply ensure you've defined the correct field type.

This can be done with DataObject in two ways:
1. Relying on the scaffolder
2. Implmeneting getCMSFeilds
The latter usually leverages the first.

To leverage the scaffolder, ensure you have the correct data type set when defining private static $db.
This is however limited as Varchar cannot tell the scaffolder whether you intend the field to be an email or not.

So implement getCMSFields. $fields = parent::getCMSFields(); will leverage the scaffolder. You can then just modify the results.
eg. $fields->push(EmailField::create('Email')); (where email is the name of your $db field).

Email Field will parse and ensure that the input value is actually an email.
Similarly you can do the same for numbers, etc.
This is better and much more secure than simple front end validation (as a savvy user can simply get around that).
Error messgaes are automated in the CMS, similar to the 'front end' style you're referencing.

See the docs for more info:
http://api.silverstripe.org/3.1/class-FormField.html
(see Direct/Indirect known subclasses at the top of the page)

Avatar
mi32dogs

Community Member, 75 Posts

8 March 2015 at 12:43pm

Thanks Pyromanik,

I’m not too worried about the simple numbers, dates and email fields it is more things like credit cards, registration numbers all stuff that does not comes out of the box and chaining validation like: if dateA > dateB then fieldC is mandatory. is there any way i can do this?

I’m not talking about frontend I like this validated in the CMS with my customer I mean the company I’m building this site for.

Avatar
Pyromanik

Community Member, 419 Posts

8 March 2015 at 1:05pm

You mentioned doing it client side and jquery.validate, which is possible.
You'll need to read up on entwine for this though (the JS library that the CMS uses). It seems complicated at first, but it's not really.
There's a good intro here: http://takeaway.bigfork.co.uk/a-beginners-introduction-to-using-entwine-in-silverstripe

This is the easiest way to handle conditionally required fields (well, the most instantaneously responsive).
For things like credit card numbers (which you really should not be storing in your silverstripe database anyway, for security reasons) you can either create a new validator for the form field (textfield) or subclass textfield and implement the check directly (much like emailfield does).

To handle conditional requirements server side, you'll probably have to rely on DataObject::validate(). This is run before a dataobject is written to the database, and cancelles the write if it fails.

Other methods include: using onBeforeWrite to make a check (and handle the result without blocking the write), or using a setter (public function setThatFieldName) which can of course handle checks when the dataobject is updated (without any need for a write).

Avatar
mi32dogs

Community Member, 75 Posts

10 March 2015 at 5:04pm

Thank you, when I looked into entwine I found this page http://doc.silverstripe.org/en/developer_guides/customising_the_admin_interface/javascript_development/ it states that you choose to use regular jQuery or entwine so I tried the regular jQuery.validate and it works like a charm. And for the conditional stuff I tested to see if I could extent the RequiredFields class and that was very easy to do, so I think I’m in good shape.

Just out of curiosity, did you advise me to use entwine because it is a better way to do it? ( I do not know anything about entwine)

Thanks

Avatar
Pyromanik

Community Member, 419 Posts

12 March 2015 at 3:58am

entwine is a library for jQuery that binds methods to the element/selector to allow a bit more of an object oriented approach.
similar to jquery.effen

$(definingSelector).entwine({
doThing: function(){/*thing*/}
})

then you can just run:
$(selector).doThing()

directly, and so long as the selector includes elements that also match the defining selector, then they will have thing done to them.

Sounds more complicated than it is, but it does take a bit of getting ones head around.