[Snippet] eForm - The Electronic form Snippet

• • 
  • 1,010 Posts
  TobyL Reply #251, 20 years ago

  Ok, it is done.. eForm (1.3) has finally been added to the repository http://www.modxcms.com/eForm-1003.html
  
  This is an updated version incorporating eForm and eFormParser into one file and which includes some enhancements:
  

  
  
  • Powerful form validation using custom validation rules.
  • A thank you template so you can add form values to the response page
  • Language support - all eForm message are now stored in a language file so you can easily adapt it to your own language (or the language of your users
  • Some minor tweaks, notably a change in the validation messages
  • Fixes to a few bugs that nobody had noticed yet

  
  
  eForm | eForm support | eForm @ wiki
• • 
  • 1,732 Posts
  xwisdom Reply #252, 20 years ago

  Very nice work TobyL
  
  I’ve looked at it and it’s look great thus far. I’m not so sure I’m for the #EVAL validation option thought.
  
  One other thing...
  
  Wouldn’t it better to use:
  
  

  [description/title]:[datatype]:[required]:[validation rule]:[validation message]

  
  instead of
  
  

  [description/title]:[datatype]:[required]:[validation message]:[validation rule]

  
  so that the validation rule comes before the message?
  xWisdom
  www.xwisdomhtml.com
  The fear of the Lord is the beginning of wisdom:
  MODx Co-Founder - Create and do more with less.
• • 
  • 1,732 Posts
  xwisdom Reply #253, 20 years ago

  Nerver mind the above question about the order of the fields as it would only get tricky with things like:
  
  

  eform="Name:text:1:#EVAL $value==1 ? true : false;: This is required"
  xWisdom
  www.xwisdomhtml.com
  The fear of the Lord is the beginning of wisdom:
  MODx Co-Founder - Create and do more with less.
• • 
  • 1,010 Posts
  TobyL Reply #254, 20 years ago

  I’ve looked at it and it’s look great thus far. I’m not so sure I’m for the #EVAL validation option thought.

  
  I’ve been uhm-ing and ah-ing about that myself quite a bit but decided to put it in and see what the reactions were. I do like to have the option for custom code but perhaps it may be better if it can only receive the name of a function, a bit like the onMailSent event function.
  
  

  Nerver mind the above question about the order of the fields as it would only get tricky with things like:

  
  Yep, that’s exactly why I made it the last one, so that there’s no trouble with any special characters in regular expressions and eval code.
  
  
  eForm | eForm support | eForm @ wiki
• • MODX Staff
  • 12,272 Posts
  Ryan Thrash Reply #255, 20 years ago

  Thanks for doing this indeed! Will this be backwards-compatible with the eForm + Parser existing deployments?
  
  BTW, a really cool client-side validation library that has some really neat pattern matching validation rules amongst other things. Demo here. Might be worth perusing for additional ideas if you haven’t already (sorry but I’ve been tied up in fixing manager shenanigans for the past 40 work hours or so...).
  Ryan Thrash, MODX Co-Founder
  Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
• • 
  • 1,010 Posts
  TobyL Reply #256, 20 years ago

  Thanks for doing this indeed! Will this be backwards-compatible with the eForm + Parser existing deployments?

  
  Yes, it is 100% backwards compatible with the previous version which used the form parser. It should also be mostly compatible with versions before the parser except that the &formats parameter will be ignored. Upgrading in that case should only require adjusting the form template.
  
  

  BTW, a really cool client-side validation library that has some really neat pattern matching validation rules amongst other things. Demo here. Might be worth perusing for additional ideas if you haven’t already

  
  Certainly will have a look at that. Thanks!
  
  eForm | eForm support | eForm @ wiki
• • ☆ A M B ☆
  • 24,524 Posts
  sottwell Reply #257, 20 years ago

  Quote from: rthrash at Sep 28, 2006, 11:51 PM

  
  BTW, a really cool client-side validation library that has some really neat pattern matching validation rules amongst other things. Demo here.
  

  
  Hm... this will make invalid form HTML. Perhaps it could be modified a bit to use classnames instead of custom attributes. That would have the added advantage of being able to style all "required" items differently in the CSS.
  Studying MODX in the desert - http://sottwell.com
  Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
  Join the Slack Community - http://modx.org
• • 
  • 89 Posts
  ed Reply #258, 20 years ago

  San Quentin, I hate every inch of you!
  
  I have wasted the better part of a day dealing with idiotic issues with eForm. I write these comments in the hope that someone will take an interest and fix up the code to make it usable for people who don’t want to spend their time reading the source.
  
  First and foremost - documentation - the old joke that it was difficult to write, it should be difficult to use was not meant as universal guidance. eForm needs proper documentation, Susan’s recent tutorial is a good start but it includes the parser which makes it difficult to use in conjunction with older material.The source code comments and error messages need bringing up to date and the useful stuff from this forum needs to be in the main body of the documentation.
  
  Specific problems I encountered, &formid is now mandatory, if you omit it then you get the benefit of this piece of code
  

  if ($formid=="") return "Invalid Form Id number or name.";

  If you can’t see what is wrong with this then you have no business producing software for use by other people. The code that follows could indicate if an invalid formid was provided but doesn’t
  
  &format is now mandatory unless you want to use the parser, if you don’t provide it and omit parser placeholders you get a baffling runtime error as contained in this post http://modxcms.com/forums/index.php/topic,2122.msg48299.html#msg48299
  
  Finally and most importantly, practically every example of eform usage is incorrect, they all show the [[eForm? ]] (non-cacheing) usage when most times, especially if you use validation, you must use the cacheing form [!eForm? !] This should be lit up in neon at the start of the documentation
  
  The problem I had is that until I got all 3 right I could get no insight into what was wrong with my code. eForm also badly needs a debug mode.
  
  Ed
• • 
  • 89 Posts
  ed Reply #259, 20 years ago

  Preserving previously entered values across validation errors
  
  Obvious when you are familiar with eForm but something I have never seen written down. If you get a validation error your contact form is reloaded with the validation message but if you folllow default advice for writing the form then all your input is lost if you enter the form’s name tag as a value then it is preserved.
  
  I.e. instead of
  

    <input type="text" name="companyname" value="" />

  do this
  

    <input type="text" name="companyname" value="[+companyname+]" />

  
  Ed
  
• • ☆ A M B ☆
  • 24,524 Posts
  sottwell Reply #260, 20 years ago

  No any more. The latest version incorporates the eFormParser mods; your field attributes aren’t in the snippet call any more, but specified in the form field itself (eform="Your Name:text:1", or eform="Email:email:1", etc) and you don’t need to worry about values being maintained. The parser does that for every field with the attribute. Much nicer.
  Studying MODX in the desert - http://sottwell.com
  Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
  Join the Slack Community - http://modx.org

This discussion is closed to further replies. Keep calm and carry on.