12 replies to this topic

[gcaplan]

Hi folks

Excited to find Processwire - a much needed breath of fresh thinking!

The only downer I've spotted so far is the apparent lack of any way to constrain data entry in the admin area fields. For example to limit an integer between 1 an 32.

I realise that this is a CMS and not a RDBMS, but the other option on my short-list, Symphony, seems to offer more here.

Am I missing something? Or is there a practical workaround (I'm fluent in PHP & regexes and have basic JQuery)?

Any advice much appreciated.

[Soma]

Edit: oh hi and welcome gcplan, glad you found us!

I think you'll have no problems to make a custom integer fieldtype/inputfieldtype module, that would check for a certain range and output an error when saved. It's possible to create field setting you would be able with 2 integer fields to enter a upper-lower bound.

You could even implement jquery script to check on runtime before saving.

Jut have a look at how the PW integer,float,text fieldtype/inputfieldtypes are done.

I think you'll have no problem if you're fluent in php. PW makes it very easy to do what ever you like in that regard.

[apeisa]

FieldtypeInteger actually has this commented function:

/* TO ADD BACK LATER
public function ___getConfigInputfields(Field $field) {
  $inputfields = parent::___getConfigInputfields($field);
  $field = $this->modules->get('InputfieldInteger');
  $field->setAttribute('name', 'minValue');
  $field->label = 'Minimum Allowed Value';
  $field->setAttribute('value', $field->minValue);
  $field->setAttribute('size', 20);
  $field->description = 'The smallest number allowed by this field.';
  $inputfields->append($field);
  $field = $this->modules->get('InputfieldInteger');
  $field->setAttribute('name', 'maxValue');
  $field->label = 'Maximum Allowed Value';
  $field->setAttribute('value', $field->maxValue);
  $field->setAttribute('size', 20);
  $field->description = 'The largest number allowed by this field (may not exceed ' . PHP_INT_MAX . ")";
  $inputfields->append($field);
  return $inputfields;
}
*/

[gcaplan]

Thanks guys

Rolling my own fields isn't ideal, but the other advantages are compelling enought that it's worth considering.

I come from the RDBMS world, so the idea of allowing uncontrained imput is rather scary. You folks have a lot of hands on experience with CMS projects - do you really find that there's no need for validation? Symphony does offer some facilities - basic, but better than nothing.

A quick fix would be to add a couple of fields to the advanced tab of the field definitions (where relevant) where you could add a regex and an error message. Basic but useful?

[ryan]

I like your idea of a regex, that would be easy to implement and very powerful. I agree on the importance of input limits. Though the need for that level of specificity in limits is pretty rare in my own projects. And this is the first time it's come up here. As a result, it's not been at the top of the priority list, but it's something that Fieldtypes are built to support (and already do in many instances). Actually, I think the number fields are probably one of the few that don't yet have many options for setting boundaries. It's not that the boundaries aren't useful, it's that I'm very cautious about enforcing any rules that could put a page in a state where one couldn't save. If I have an integer field that I know has to be between 1 and 3, then I'm usually enforcing that in my template code, where the need for the boundary exists. Longer term, I still think it's better to have it in the admin. Now that it's come up (via your message) that builds momentum for doing it sooner rather than later. Beyond a min/max in the integer and float fields, are there any other fields you think specifically additional validations would be worthwhile? I do like the idea of adding the regex option to the single line text field, though I'm not sure how many will use it (beyond us).

[Soma]

How about a slider you could configure to go from 1-3

Maybe different types of input slider with ranges would make a cool new inputfieldtype like my colorpicker. I will consider maybe doing one soon.

[apeisa]

Little OT: just realized that InputfieldInteger doesn't allow negative values. Not sure why? It saves negative values ok, but sanitizeValue changes them to positive. So in database I have -10 but edit field shows 10. Maybe a setting for this?

[ryan]

I think it's time for some upgrades to InputfieldInteger. I'm adding this to my list.

[gcaplan]

Ryan

Great to hear from the developer!

I'm very cautious about enforcing any rules that could put a page in a state where one couldn't save.

Don't really follow you here, as surely the idea is to prevent users from saving bad data? So long as you provide clear error messages how is this a problem? With jQuery it's pretty easy to provide the message as soon as users tab out of the field.

I'm usually enforcing that in my template code, where the need for the boundary exists. Longer term, I still think it's better to have it in the admin. Now that it's come up (via your message) that builds momentum for doing it sooner rather than later. Beyond a min/max in the integer and float fields, are there any other fields you think specifically additional validations would be worthwhile?

Don't understand much about PW yet, but doesn't doing this in the template mean that issues will only show up at runtime?

I suggested the regex idea as a quick and dirty fix, but obviously it's going to restrict use of the feature to sad geeks like us. Plus, on thinking it through, a single field for an error message would hit problems with your back-end internationalisation.

Years ago I developed a flexible declarative approach and it has served me well. Some of the modern PHP frameworks use a similar idea. You develop an easily extended utility library of validations, and each validation has an error string in all active languages. The string can use template-like placeholders for parameters: "Number should be between {1} and {2}." Then you develop a simple declarative syntax for setting validations and any relevant parameters. Here's a couple of examples:

is_greater_than,10

is_between,1,365

is_alphanumeric;is_max_length,256

As a catchall, you can offer access to regexes:

matches_pattern,

^\$(\d{1,3}(\,\d{3})*|(\d+))(\.\d{2})?$,"Must be a valid USD price"

Another useful feature, I find, is filters that clean up input. These are run before the validations and ensure consistent presentation.

For example, for a city or postal code you might use:

to_uppercase

For a field in which you are entering, say, architects, you can tidy up capitalisation with:

to_pretty_name

If input isn't entirely trusted, you can offer a range of sanitation filters to eliminate cross-site scripting etc. This would open up the possibility of using PW for, say, social content management.

The actual plumbing for this is just a few lines of code, and there are plenty validation and filter libraries to plunder. You'd be getting a lot of functionality for a small investment! I guess you'd tuck this out of the way on the advanced tab. For types with limited validation options such as numeric fields you could improve usability by offering the validation options as fields on the form instead of declarations. For text fields, the declarative string would be the most flexible, I think. You could offer popup help so users could check their options without leaving the form.

Personally, I would find this pretty useful. Why not help content creators achieve consistency and correctness?

[ryan]

It really depends on the fieldtype, but for text fieldtypes the idea is to be flexible. There is no bad data with trusted input, just bad output. If you don't want to allow HTML for instance, then you would select textformatters such as 'strip tags' and 'html entities'. But we avoid modifying what the user enters as we don't want to limit PW to one use over another. Specific validations are for specific fieldtypes. PW's basic fieldtypes are meant to be open-ended, as much as possible. For specific data needs, the intention is that you would use (or create) a specific fieldtype rather than expecting it from a general purpose one. Taking that zip code example, that's a pretty specific input -- if we are taking a zip code as input, we'd ideally use a zip code fieldtype so that it knows how to validate zip codes and doesn't take up any more storage space in the DB than what is needed for a zip code. However, I'm not at all against adding more validation capabilities to the basic fieldtypes, and like the examples in your approach. It certainly can't hurt anything so long as it's optional, so will plan to continue adding more validation possibilities to the basic fieldtypes.

[MatthewSchenker]

Greetings,
I'm now turning to validation for my ProcessWire sites and this seems like a good discussion on the matter.

...I'm very cautious about enforcing any rules that could put a page in a state where one couldn't save. If I have an integer field that I know has to be between 1 and 3, then I'm usually enforcing that in my template code, where the need for the boundary exists.

If the user is a fellow admin, I can see that validation is less of a worry. But for sites where I am allowing submissions from a wider audience, I definitely think the priority shifts from "make sure the page can be saved" to "make sure the data is correct."

I'm fine doing validation in the templates, as Ryan suggested. But is this for front-end forms (i.e., not for the admin interface)?

Thanks,
Matthew

[ryan]

Quite a bit of validation options have been added to the Inputfield types since Form Builder was introduced. For instance, InputfieldInteger now supports min/max values and HTML5 number type. Text fields now support regex validation. Most of this is in the dev branch though.

[MatthewSchenker]

Hey Ryan,
It's always very reassuring to see your name and face in a discussion!

I'm very glasd to know that these validation elements are in the development branch. I'm going to start testing/using that one some more!

I guess this is one more reason to be excited about the next version.

Thanks,
Matthew