We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 13428 ☆ A M B ☆
    • 1,031 Posts
    Hello,

    is there any special reason why $vMsg and $rMsg are ’numeric’ (indexed) arrays in the eForm code? If they were ’named’ (associative) arrays (by fieldname) I could set own placeholders for each field not validated in eFormOnValidate but without I can’t tell from $rMsg and $vMsg which field caused the message.

    Hope my english is not that bad and this problem is understandable.

    Regards
    Jako
      • 30223
      • 1,010 Posts
      No, this is for historic reasons only,.. targeted to change in the future, mind you they may not be there as such in the future if I ever get finish the next version.
        • 13428 ☆ A M B ☆
        • 1,031 Posts
        mind you they may not be there as such in the future if I ever get finish the next version

        But they are used in eFormOnValidate, so if the event system of eForm won’t be changed in future they should stay. I’ll try to get them ’named’ and send you the diff or the code.
          • 3749
          • 24,544 Posts
          I think if you test them with is_numeric() ( or is_string() ) before use and act accordingly, it shouldn’t break older code.

            Did I help you? Buy me a beer
            Get my Book: MODX:The Official Guide
            MODX info for everyone: http://bobsguides.com/modx.html
            My MODX Extras
            Bob's Guides is now hosted at A2 MODX Hosting
            • 30223
            • 1,010 Posts
            Quote from: Jako at Oct 14, 2008, 09:21 AM

            mind you they may not be there as such in the future if I ever get finish the next version

            But they are used in eFormOnValidate, so if the event system of eForm won’t be changed in future they should stay. I’ll try to get them ’named’ and send you the diff or the code.
            Please do.  I’ll see if I can incorporate it from your patch.

            As far a the next major version is concerned,.. it’s going to be class based and will have substantial benefits for extending and customizing it to each ’s own needs. It comes at the cost of, in some cases, having to adapt older event code. I am however working on a legacy class that will in most cases work I hope smiley
              • 13428 ☆ A M B ☆
              • 1,031 Posts
              The arrays should be associative by patching these lines:

              177c177
              < 				$vMsg[count($vMsg)]=$_lang['ef_failed_vericode'];
              ---
              > 				$vMsg['vericode']=$_lang['ef_failed_vericode'];
              191c191
              < 					$rMsg[count($rMsg)]="$desc";
              ---
              > 					$rMsg[$name]="$desc";
              195c195
              < 					$value = validateField($value,$fld,$vMsg,$isDebug);
              ---
              > 					$value = validateField($value,$fld,$vMsg,$isDebug,$name);
              206c206
              < 								$vMsg[count($vMsg)]=$desc . $_lang["ef_invalid_number"];
              ---
              > 								$vMsg[$name]=$desc . $_lang["ef_invalid_number"];
              215c215
              < 								$vMsg[count($vMsg)]=$desc . $_lang["ef_invalid_date"];
              ---
              > 								$vMsg[$name]=$desc . $_lang["ef_invalid_date"];
              223c223
              < 								$vMsg[count($vMsg)] = isset($formats[$name][4]) ? $formats[$name][4] : $desc . $_lang["ef_invalid_email"];
              ---
              > 								$vMsg[$name] = isset($formats[$name][4]) ? $formats[$name][4] : $desc . $_lang["ef_invalid_email"];
              229c229
              < 								$vMsg[count($vMsg)]=$desc . $_lang['ef_upload_exceeded'];
              ---
              > 								$vMsg[$name]=$desc . $_lang['ef_upload_exceeded'];
              232c232
              < 								$rMsg[count($rMsg)]=$desc;
              ---
              > 								$rMsg[$name]=$desc;
              235c235
              < 								if( substr($fld[5],0,5)!="#LIST" || validateField($_FILES[$name]['name'],$fld,$vMsg,$isDebug) )
              ---
              > 								if( substr($fld[5],0,5)!="#LIST" || validateField($_FILES[$name]['name'],$fld,$vMsg,$isDebug,$name) )
              883c883
              < function validateField($value,$fld,&$vMsg,$isDebug=false){
              ---
              > function validateField($value,$fld,&$vMsg,$isDebug=false,$name=''){
              893c893
              < 		$vMsg[count($vMsg)] = "$desc »" . $_lang['ef_error_validation_rule'];
              ---
              > 		$vMsg[$name] = "$desc »" . $_lang['ef_error_validation_rule'];
              1005c1005
              < 			$vMsg[count($vMsg)] = $errMsg;
              ---
              > 			$vMsg[$name] = $errMsg;


              After that it is possible to set own validation placeholders for each field via this eFormOnValidate function:

              <?php
              function validationplaceholder(&$fields, &$vMsg, &$rMsg) {
              
                foreach ($rMsg as $rField => $rMessage) {
                    $fields['validate_'.$rField] = 'Please fill this field!';
                }
                foreach ($vMsg as $vField => $vMessage) {
                    $fields['validate_'.$vField] = 'Field not valid!';
                }
              return true;
              }
              // Return empty string
              return '';
              ?>


              If there is a placeholder ’validate_fieldname’ for an input called ’fieldname’ it will be filled with a message for the user.


                • 36805
                • 354 Posts
                Taking a look at the current docs these arrays are apparently still numeric. This makes it counter-intuitive and very very high maintenance to have your own validation in place. Even slight changes to the form will certainly break things.This was based on a missconception. I thought the index has to be in order of the field occurrences on the form. However it works differently. Index 0 holds built-in validation messages and higher indices hold custom ones. The final [+validationmessage+] is a concatenation of all array elements seperated by a

                Quote from: TobyL at Oct 14, 2008, 02:26 AM

                No, this is for historic reasons only,.. targeted to change in the future, mind you they may not be there as such in the future if I ever get finish the next version.
                Now, more than 2 years later, the eForm code is probably very different. Why hasn’t it changed? Would it be too difficult? Were there issues? Couldnt we somehow make it associative?

                EDIT: I did some digging around apparently the eForm code has not changed much at all. It never got class based. I could find the lines and apply the patch Jako posted. I’ll play around with it and report back.
                I feel it is a pity the fix never made it in the official version. I think eForm can be *much* more useful this way. Messages can be more easily associated with the cause. This is a best practice we see everywhere on the web.

                EDIT2: Testing confirms this works for custom as well as eForm core validation. For those who are interested see post attachment for modded eForm. Only Jako’s patch was applied and some very minor code formatting.

                NOTE: A further refinement could be done to remove all the hardcoded "$desc &raquo;" which get appended to all messages. Its purpose is to flag which input the message concerns. It looks nicer without. For the time being I decided to keep things as they are. That way it does not change its behavior where it is not desired (when you don’t use individual messages but the single [+validationmessage+]).
                  • 16278
                  • 928 Posts
                  It seems to me that eForm, like Jot, MaxiGallery and Ditto, reached a plateau some time ago - the developers responded to initial concerns and suggestions, something imperfect but adequate for the great majority of cases resulted, loads of people have very gratefully used and adapted to what is there, and would be fearful of changes in case they break the existing installed base.

                  Given that some of the original developers have moved on or are unlikely to develop things further for whatever reason, support and development come down to others in the community, who can:

                  - delve into the code when they are aware of problems, and fix them for themselves and others

                  - use their own and others’ experience with the existing key extras to develop alternatives that aim to exceed their benefits, carrying over the aspects that have made them so popular

                  - take on development of the originals

                  The first is a maintenance option which, combined with the inadequacy of the forum search facilities, makes it very time consuming to fix problems. The wiki might offer a way to crystallize the most frequent fixes -- though I’m not quite clear on the old wiki’s status these days. Or the new one’s, for that matter.

                  Developing your own is a daunting task, but trying to update NewsPublisher soon convinced me of the benefit, out of which pkBlog and then PubKit were born. Trying to improve on someone else’s comprehensive and well-established opus is definitely "angels fear to tread" territory, whether you love or loathe their programming style!

                  laugh KP
                    • 36805
                    • 354 Posts
                    Quote from: kp52 at Feb 08, 2011, 06:27 AM

                    It seems to me that eForm, like Jot, MaxiGallery and Ditto, reached a plateau some time ago - the developers responded to initial concerns and suggestions, something imperfect but adequate for the great majority of cases resulted [...] Given that some of the original developers have moved on or are unlikely to develop things further for whatever reason, support and development come down to others in the community [...]
                    Your observations seem accurate to me. In some cases a snippet/plugin pioneer moved on and notified the community about it (DirectResize and YAMS). I wish that would be the case here too.

                    In this case it was like: sure go ahead and show me the patch I’ll use it soon. Then a few words of ambition of a rewrite to class codebase and then silence. I know it is all community driven. However, because of that communication is important.

                    Old wiki versus new wiki compares very well, communication-wise. Why do we have 2? Is one for evo and one for revo? Will the old one be made readonly or removed?

                    Sorry about the rant and in any case thanks to Raymond Irving, TobyL for making an indeed robust snippet with above average documentation.
                      • 26931
                      • 2,314 Posts
                      there’s some progress on an updated version of eForm here: http://modxcms.com/forums/index.php/topic,60756.msg345513.html