Support/Comments for eForm

• • 
  • 177 Posts
  seventhapex Reply #221, 19 years, 7 months ago

  this will do it.
  

  INPUT.required{ ...}
  

  
  
  I’m not sure because I’ve not used eform’s validation, but it looks like both class names are in the same attribute IE: <input class=" inputfield1 required"/ >
  
  you refer to this as only one or the other classes, this method is most often used to apply miltiple styles to a single element
  
  EXAMPLE:
  

  <style>
  INPUT.inputfeild1{
    border:1px solid #DDD;}
  
  INPUT.required{
    background:#FF5555;}
  </style>
  
  <html>
  
  <input type="text" class="inputfield1 required" value="">
  
  </html>
  

  
  
  if my assumption regarding two classes in a single class attribute is correct, in my opinion you’ve reduced the flexibility of your style by modding it as you have. Please try my style above (assumption) before committing to the mod.
• • MODX Staff
  • 12,272 Posts
  Ryan Thrash Reply #222, 19 years, 7 months ago

  You can indeed put multiple class definitions into a wrapping element. The last one in the CSS file should take precedence over any before it, and not by order in the way they’re listed in the class="blah blah2". This is because they have equal specificity according to the spec for styling that element, so styling source order prevails.
  
  And use lowercase in your css and in your XHTML when you can for HTML elements (INPUT -> input).
  
  
  
  
  Ryan Thrash, MODX Co-Founder
  Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
• • 
  • 177 Posts
  seventhapex Reply #223, 19 years, 7 months ago

  I use CAPITAL letters for my elements in the style sheet so that I can easily seek them out. I use all lowercase <elements> in my markup because it won’t validate otherwise. Capital letters for <element> selectors in a stylesheet will validate. my "assumption" was in regards to weather or not eForm uses this method for output. because if it does padexx had reduced the flexibility of the scripts use with css.
  
  sorry for the confusion.
  
  XHTML
  

  <input class="field required" type="text" value="foo"/>
  

  
  
  CSS
  

  INPUT.field{ ...}
  INPUT.required{ ...}
  
• • 
  • 63 Posts
  padexx Reply #224, 19 years, 7 months ago

  Thanks for your replys!
  
  Got it working... sorry for the confusion.
• • ☆ A M B ☆
  • 1,056 Posts
  pixelchutes Reply #225, 19 years, 7 months ago

  Hmm... is it just me, or do emails such as: [email protected] note seem to validate using the eForm pre-packaged "email" type validation?
  Mike Reid - www.pixelchutes.com
  MODx Ambassador / Contributor
  [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
  ________________________________
  Where every pixel matters.
• • 
  • 1,010 Posts
  TobyL Reply #226, 19 years, 7 months ago

  No, you are not the only one and Yes the plus symbol does not validate in eForm. There are probably a few more (obscure) characters that are officially allowed in email addresses but will not validate in eForm’s standard email validation. The regular expression used for email validation is a couple of years old at least when the + sign wasn’t accepted by most email servers anyway.
  
  With qmail’s (and others) tagging system this obviously needs to be addressed (pardon the pun). I’ll have a look at updating the regular expression for the next version, but that won’t be soon... In the mean time have a look at the reg expression on line 201. If you can work something out let me know.
  eForm | eForm support | eForm @ wiki
• • ☆ A M B ☆
  • 1,056 Posts
  pixelchutes Reply #227, 19 years, 7 months ago

  Nice, once I have time to confirm a new regex, I’ll surely update it.
  
  On another note, I’m getting some unexpected behavior from eform and select menus:
  
  

  <select name="Answer1" eform="Question 1::1">
  <option></option>
  <option value="1">Yes</option>
  <option value="0">No</option>
  </select>
  

  
  
  The following eform validation rules don’t appear to authenticate when user’s select the "No" option: (Value = 0)
  
  

  
  eform="Question 1::1"
  eform="Question 1:integer:1"
  eform="Question 1::1:Must be a number:#REGEX /^[0-9]+$/i"
  eform="Question 1::1:Must be a number:#EVAL return (strlen($value) > 0 and (intval) $value >= 0)"
  

  
  ...I even tried naming the select "Answer1[]" (As are my radios/checkboxes), but no luck. In fact, it actually seems to break the persistence of previously filled out form elements on eform error...so I stayed away from Answer1[] on this <select>...(which makes sense, as it’s not multi select, right?)
  
  However, the weirdest part is that I also have questions in the form of radios with zero values and those work fine...?
  
  I know from the eform docs it states this is automatic, and validated against actual values from the original <select>, which should be fine...but am I missing something?
  
  

  
  Select boxes, radio options and checkbox fields
  Select boxes, radio options and checkbox fields now have working automatic validation. Any input for these fields is validated against the values set in your form template. This avoids anyone tampering with the form by adding their own values to these fields
  

  
  I’m starting to wonder if it’s a bug, or simply a limitation, but of course there’s always "User Error"
  Mike Reid - www.pixelchutes.com
  MODx Ambassador / Contributor
  [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
  ________________________________
  Where every pixel matters.
• • 
  • 1,010 Posts
  TobyL Reply #228, 19 years, 7 months ago

  I’ve put it on my list to check! Probably won’t be able to look into it until late next week though.
  
  I’ll be off line for nearly a week from Friday onwards and until then I’ll be packing boxes.. Moving house!
  eForm | eForm support | eForm @ wiki
• • ☆ A M B ☆
  • 1,056 Posts
  pixelchutes Reply #229, 19 years, 7 months ago

  I tried adding value="" to the empty option, but witnessed no change, however I did noticed that in the code/REGEX, it implicitly looks for <option ...> (the space after <option) ...In adding it, it becomes part of the $matches array for possible valid matches.
  
  Unfortunately, added or not, this is my list of $validValues according to eForm:
  
  

  Array
  (
      [0] => 1
  )
  

  
  
  See, the above array is created by evaluating to values, and ensuring data exists:
  
  

  //<?php
  $value = substr($attr['value'],1,-1); //strip outer quotes
  if($value) $validValues[] = $value; 
  

  
  
  I believe it’s possible that since my value is 0, that it never makes it into $validValues per not passing the if($value) clause...
  
  By changing the If-clause to the following, my problem was solved (~ Line # 746 ):
  
  

  //<?php
  if(strlen($value)>0) $validValues[] = $value;
  

  
  
  @TobyL, can you confirm if changing if($value) to if(strlen($value)>0) (or similar) will not break something unknown to me?
  Mike Reid - www.pixelchutes.com
  MODx Ambassador / Contributor
  [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
  ________________________________
  Where every pixel matters.
• • 
  • 1,010 Posts
  TobyL Reply #230, 19 years, 7 months ago

  @TobyL, can you confirm if changing if($value) to if(strlen($value)>0) (or similar) will not break something unknown to me?

  Confirmed! In fact in my local working copy I had changed this to if( trim($value)!=’’ ) $validValues[] = $value; which basically does the same except for stripping whitespace chars.
  
  Time for a small incremental release I think. As soon as I find the time I’ll post an updated version.
  
  
  eForm | eForm support | eForm @ wiki

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