Ticket #145: Some improvements to flourish...

Patch to better describe the proposed changes: http://pastebin.com/fe4b9c37

Awesome, thanks for the patch!

I'm not sure how long pastebin entries stay around, so I'm going to also attach a file with the patch.

I'll probably adapt the fValidation custom rules a little so that a custom error message can be added. I'm thinking the syntax would be nicer to have one custom rule added at a time so that the field, regex and message can all be specified as parameters instead of having to use nested arrays. What are your thoughts?

I think wrapping the field names in some sort of HTML is a good call. I'll need to adapt that to all of the ORM validation stuff too.

With the fActiveRecord method, how do you use it? Most of the time I end up populating the record and then using the record to provide the input values. I'm guessing you are pushing the values back into fRequest and then using fRequest to provide the input values?

Patch pulled from pastebin

- The pastebin should last forever :) - I agree on your idea to provide a single rule at a time! Much readable! - For the ActiveRecord?: this is how I write the form fillup:

$user = new User($id);
if (isPost) {
  // this pushes the form fields within $user 
  $user->populate();
} else {
  // this pulls $user values outside to fill the fRequest
  $user->populateRequest();
}
 
<form>
  <input type="text" name="last_name" value="<?= fRequest::get("name") ?>" />
</form>

So that if it's the first time you're seeing the page, the form will be filled with the current $user values. Hope to be clear :)

I apologize this has been sitting stagnant for so long. The Oracle improvements I've been working on have tied up a little too much of my time.

Also, I need to finish putting together a contributor license agreement (CLA). It is a document that you'll need to sign that basically says you confirm you have the proper rights to license this code as MIT, that you are licensing it as MIT and that you retain the copyright to the code.

If you don't want to, or can't sign such a document, we can file some of these as enhancement requests and I'll implement them.

I'm obviously willing to sign the CLA :) Let me know when it's ready. In the meantime, thanks for your beautiful work. Really. I enjoy every single minute spent with your framework.

Yesterday I posted the PDFs for the CLAs. If you wrote the patch independently, I would need an individual one, if you wrote it while employed by someone else, I would need a corporate CLA.

Thanks!

If I have to be sincere, all this signing thing is kinda slow, I'm pretty sure this will have as a direct effect a decrease of submitted suggestions/patches. Anyway, when I'll be able to print and scan that paper, I'll mail it to you.

I definitely know what you are saying. Unfortunately this seems as though it is the generally accepted best-practice for open source development. Luckily it only has to be done once.

Sorry for the inconvenience.

As of r596 I implemented the '*' and array of names support for fMessaging::check().

In r598 I added a method fValidationException::setFieldFormat() that allows customizing how field names look in error messages. Here's an example to add strong tags like you requested:

fValidationException::setFieldFormat('<strong>%s:</strong> ');

This ticket has finally been completed with the addition of fValidation::addRegexRule() in r833.