fValidation flexibility. about flourish-classes

[Tatsh]

From my last comment on the original issue:

A method like fValidation::addCSRFField() would be awesome.

#49

[wbond]

Comment by @netcarver:

Hello Andrew,

Thank you for taking the time to post in such detail. As you pointed out in your reply to my first idea, it is possible to use the fValidation::validate() method without having it throw an exception. In fact, externally defining additional conditions is what I have resorted to doing in the absence of a more flexible way of having the error messages defined via fValidation::addCallbackRule() itself.

In regard to your second reply, I think you are probably correct in saying that another method would be better than another signature to fValidation::setRequiredFields().

Originally I had envisaged a patch to fValidation that opened the internal rule storage and check* methods so that I could subclass fValidation and provide my own solutions to these two issues without touching fValidation any further. However, having read your replies, I now see that it would be equally acceptable (to me at least) to simply have two new methods that added these features right into fValidation without loosening the access controls on the members and methods.

If I do work up a patch for this I intend to submit it to Will.

[wbond]

Ticket #54 addresses the issue that callback rules should be able to set a message. There is also the discussion at http://flourishlib.com/discussion/2/572 which has got me thinking about ways to handle customizing messages.

Let's talk a little bit more about this before writing any code. I feel like we need to get down to a more core level decision related to custom validation messages for other more complex validation. This should also affect the whole ORM validation system since fValidation and the ORM are based on the same principles, albeit not currently sharing any code (for historical reasons).

[wbond]

Comment by @Tatsh:

Might I also suggest not outputting HTML if fJSON::sendHeader() or fXML::sendHeader() has been called? Currently my solution to that is to add a callback for fText that just strips HTML 'post' fText::compose() if the request is made via AJAX (fRequest::isAjax()).

[wbond]

Comment by @Tatsh:

Another thought came to mind on 'extending'. If all you want are preconfigured fValidation objects, I would make a class aptly named somethingValidation like (bValidation if your site classes were regarding a blog). It would just have static methods that return pre-configured fValidation objects.

class bValidation extends fValidation {
  const checkCSRF = 'bValidation::checkCSRF';

  /**
   * @param string $csrf
   * @param string $url
   * @return boolean
   */
  public static function checkCSRF($csrf, $url = NULL) {
    try {
      fRequest::validateCSRFToken($csrf, $url);
    }
    catch (fValidationException $e) {}
    return FALSE;
  }

  /**
   * @param string $csrf_field_name
   * @param string $printed_name
   * @return fValidation
   */
  public static function initWithCSRF($csrf_field_name, $printed_name = 'Csrf') {
    $validation = new self;
    $validation->addRequiredField($csrf_field_name);
    $vaildation->addCallbackRule($csrf_field_name, bValidation::checkCSRF, __('Unknown error occurred. Please try again.'));
    $validation->overrideFieldName($csrf_field_name, $printed_name);
    return $validation;
  }
}

Most if not all of my forms have a CSRF token to validate. Typing to add the callback rule over and over is a bit annoying.

A method like fValidation::addCSRFField() would be awesome.