Add ability to have validation field error messages inserted into the document by FormPopulationFilter

[david]

Idea: one specifies an XPath expression that is used to find a position in the DOM, plus an "inside", "before" and "after" command and the HTML to insert along with placeholders that are then replaced. The last missing piece in the form handling puzzle.

[david]

Ross is working on this atm, also see #427 (closed as dupe), two patches so far: attachment:ticket:427:AgaviFormPopulationFilter.class.php.patch and attachment:ticket:427:AgaviFormPopulationFilter.class.php.2.patch

[david]

Another idea: the XPath expressions used to determine the location in the markup where the error fragment should be inserted can again be specified per element etc, in fact, per any arbitrary condition, by simply making that an XPath expression, too! Cool! woot! So to have a different HTML fragment or a different XPath locator for checkboxes, one would have a condition in the style of /input[@type=checkbox] or so (you get the idea).

Also: we can allow people to specify their HTML chunk to insert in a CDATA section and then use  http://php.net/manual/en/function.dom-domdocumentfragment-appendxml.php - cool!

[RossC0]

David - can you remove the first patch - it messes with the whitespace

[ross]

FPF Patch has been updated to be a diff from the latest FPF

[ross]

Removed Duplicated 'error' class

[ross]

Updated Patch and removed the SPF patch as FPF was updated [2066]

[david]

(In [2096]) Added prototype ability to have validation field error messages inserted into the document by FormPopulationFilter?, refs #303

[david]

(In [2099]) added "replace" to possible insert locations for form error messages, refs #303

[david]

(In [2101]) Refactored FPF error insertion a bit, now uses ${errorMessage}?\194?\160instead of %s as placeholder for the message. Each parameter with xpath expression as key can now either be just the message markup, or have child parameters "markup", "location" (one of "before", "after", "replace" and "child", default is "after") and "container", which can have markup for a container to wrap all messages. It is inserted at the given (or default) location instead of the indidivual elements, and can have a ${errorMessages} placeholder for all error messages combined into a string. As with the main or "markup" parameter, a callback is possible, which in case of the container receives an array of error messages as the second arg instead of just the message (erroneous element node is the first one), in case you'd like to do something more advanced. Refs #303.

[david]

(In [2102]) in addition to ${errorMessage}, error message markup snippets now also support ${elementId} and ${elementName} variables with the element id and name, respectively. refs #303

[david]

(In [2103]) as a followup to [2102] and in addition to ${errorMessage}, error container markup snippets now also support ${elementId} and ${elementName} variables with the element id and name, respectively. refs #303

[david]

(In [2106]) larger refactoring of FPF to clean up some parts, and ability to insert validation error messages into the form - for "normal" field errors, multi field errors, and generic errors (i.e. those that did not have a matching field in the form, or those that could not be inserted into the document because no xpath rule matched), each also acts as a fallback for the following. docs and samples to follow. closes #303

[ross]

Suggestion: Adding an extra location: 'after_parent'

As currently after will put it directly after an element if there is a sibling, or after the parent if there isn't.

For example 'after' can't cater very well for forms like:

  <li><input type="text" name="1" /></li>
  <li><input type="text" name="2" /><input type="submit" value="go"/></li>

Patch incoming Patch incoming

[david]

no need for that, can be done using xpath by selecting the parent node and having "after" as location

[david]

(In [2121]) Fixed an issue where FPF would not fall back to more generic error message insertion rules, refs #303

[ross]

Ensure there are incidents to process before adding any markup!

Patch updated!

[ross]

Ensures incidents exist before inserting any markup and attributes incidents to the form from whence they came

[ross]

Patch updated - Handles multiple forms for error_messages

[david]

(In [2122]) Fixed an issue where forms with the same action would both get error messages inserted under certain circumstances, thanks Ross for the hint. Also, errors that could ultimately not be inserted are now stored in request attribute "orphaned_errors", namespace "org.agavi.filter.FormPopulationFilter?". Refs #303

[david]

Thanks for the patch. I did it a little different now, but I think you still deserve your "fifteen minutes" in the CHANGELOG for this whole feature ;) Cheers mate.