zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke · 2016-05-24 00:14:58

phiw13 wrote #299229:

In the situation of the third point above, the required attribute is still useful for flagging the required fields: AT (screenreader) uses it

Good point about screen readers. So leaving the required attributes in the form fields on the page is a useful hint to screen readers, helping prevent unnecessary trips to the server for people who use them. But the browser itself will silently let anything be posted if novalidate is on. Handy.

I think just adding support for a novalidate attribute on the zem_contact tag might please everyone. Hurrah!

phiw13 · 2016-05-24 00:15:25

Bloke wrote #299230:

So, to get this straight in my head: even though adding novalidate incapacitates the browser from checking required status and min/max constraints, etc, you still want all that validation to be done server side and display any errors in the error box that appears above the form?

As far as can tell, browsers will (try) to satisfy min/max constrains (e.g. prevent the user from inputting “11” if the max-range is “10”), that has nothing to do with form validation. And yes, the point is to do all validation by script, server-side and display errors if needed.

gomedia · 2016-05-24 00:21:29

Bloke wrote #299231:

I think just adding support for a novalidate attribute on the zem_contact tag might please everyone. Hurrah!

Looks like way to go. Easy peasy, lemon squeezy.

Bloke · 2016-05-24 00:34:11

phiw13 wrote #299232:

As far as can tell, browsers will (try) to satisfy min/max constrains (e.g. prevent the user from inputting “11” if the max-range is “10”), that has nothing to do with form validation.

That’s interesting. I noticed earlier when I tried <txp:zem_contact_text type="number" min="1" max="10" /> that Chrome rendered a spinner that was constrained to integer values between 1 and 10. As one would expect: implicit validation by virtue of the control itself not permitting values outside a range.

Similarly with <txp:zem_contact_text min="1" max="10" /> (i.e. default type="text") the browser renders a standard text input box and Chrome imposes a character limit of between 1 and 10 in length. Again, implicit validation. Short of hacking the form, the server will not receive invalid input.

But <txp:zem_contact_email /> uses solely browser-based validation to check the email address. So novalidate will have a definite effect. The first (number spinner) case can submit bogus information if novalidate is present. The spinner controls won’t allow you to go outside the range if you operate them with a mouse, but you can manually type in a bad value. With novalidate it’ll submit and ZCR catches the rogue value instead. Without novalidate, the browser whinges first and prevents form submission.

So, yep, simply adding support for novalidate will help massively. I’ll do that once I’ve fixed the bugs in the radio elements. Thanks to you all for helping.

uli · 2016-05-24 11:58:03

I would not exactly name that attribute novalidate as this implies zem_cr won’t validate that field. Maybe somthing like omit_browser_validation or something in that direction.

Bloke · 2016-05-24 12:09:32

uli wrote #299243:

I would not exactly name that attribute novalidate as this implies zem_cr won’t validate that field. Maybe somthing like omit_browser_validation or something in that direction.

I deliberated for a short while over renaming it. And I probably will still do so, but I couldn’t think of anything better for the time being. I really dislike ‘no_something’ attributes at the best of times because they’re counter-intuitive, and difficult to debug. (no-widow="0", anyone? Turn off no-widowing, so, ummm, permit dangling last words… argh!)

Since in this case the HTML attribute begins with ‘no’, switching it around requires some backwards code logic, and to make the attribute true by default. I feel this is preferable to a “negative” attribute. What do you think?

I considered:

validate: 1 = default, 0 = add novalidate to <form>.
browser_validate (with the same options).
do_validation (ditto).
no_validaton: 0 = default, 1 = add novalidate to @<form>. Yucky.

Any other, snappier options?

maverick · 2016-05-24 16:26:16

Bloke wrote #299244:

I considered:

browser_validate (with the same options).

If you are going to rename it, I think this wins the KISS award.

Tangent:

Speaking of clear communication, could I suggest that it is time to rename zem_contact_reborn?

Reason:

zem is long, long gone from the txp community. He has nothing to do with the plugin any longer. The original zem_reborn was already a new maintainer with major code changes. Now we are onto yet another maintainer with yet more major code changes.
The plugin today is so much more advanced than the original version. It is no longer a simple contact form. It is a robust front side form creation/submission module used for multiple purposes.
Because of it’s importance, core developers have taken the lead on overhauling and updating it.

May I suggest a name along the lines of txp_form communicates more clearly what exactly it is/does and that the core devs are maintaining it?

Last edited by maverick (2016-05-24 16:30:25)

uli · 2016-05-24 17:07:01

Bloke wrote #299244:

validate: 1 = default, 0 = add novalidate to <form>.

browser_validate (with the same options).

do_validation (ditto).

no_validaton: 0 = default, 1 = add novalidate to @<form>. Yucky.

From these four I’d vote for browser_validate as, with the term browser, it’s the one that best describes what’s meant.

Last edited by uli (2016-05-24 17:07:56)

Bloke · 2016-05-24 19:15:35

Then browser_validate it is. Thanks for your votes.

maverick wrote #299250:

Speaking of clear communication, could I suggest that it is time to rename zem_contact_reborn?

Normally I’m resistant to such upheaval — moreso for admin-side plugins like ied_plugin_composer — because it’s a hassle to:

rename and migrate all the prefs over to the new prefix;
make sure the two plugins can coexist temporarily and not blow up your admin-side in case they’re both unwittingly activated at the same time;
get supporting plugin authors who hook into the callbacks to change their code to use the new prefixes; and
inconvenience end-users into changing all tags to use the new naming convention.

Now, ZCR is a public-side plugin so the only real annoyances are the last two items on the list. But they are a significant hurdle, and for no real material gain aside from a clean start.

It is a bit of a bizarre plugin title, I’ll give you that. But the ‘zcr’ moniker is so ingrained in the community that most people use it, and even the callback return codes use the prefix; as do two recent supporting modules, zcr_mailchimp and zcr_file_upload.

I’m not dismissing the idea outright, because rebranding could be a good move. I’m just saying there’s a lot more to it than a simple rename.

May I suggest a name along the lines of txp_form

We’ve reserved the txp_ prefix for that purpose. But until we rename Forms inside Textpattern into something less… well, you know… then that ‘form’ terminology along with the official prefix might give the impression it’s something to do with admin side Forms.

I dunno. txp_contact, maybe? Or to indicate its wider scope as a customer relationship enabling platform, txp_crm :-p

jakob · 2016-05-24 21:28:57

I understand the backward-compatibility argument obviously, but, like Maverick, I think this has long been one of the most ridiculously-named plugin in the plugin-menagerie.

Is it possible to use alias function names and callbacks to transition to a new plugin name while retaining backward-compatibility?

I like the txp_ prefix but could that lead to confusion errors with txp:txp_contact. Maybe your zcr_ prefix can stay?

Bloke · 2016-05-24 22:02:35

jakob wrote #299259:

Is it possible to use alias function names

Yes. As long as you don’t have this and the new plugin installed side-by-side. You must deactivate the
existing one or it’ll throw a wobbly. Not so bad in this instance that it’ll kill your admin experience, but if you visit the front-of-house then things would break.

and callbacks to transition to a new plugin name while retaining backward-compatibility?

Yes, but the more callbacks that are listening, the slower things are.

I like the txp_ prefix but could that lead to confusion errors with txp:txp_contact.

Yeah, not good. Hadn’t thought of that. We do have 18 other prefixes reserved :-)

gomedia · 2016-05-24 23:22:10

maverick wrote #299250:

Speaking of clear communication, could I suggest that it is time to rename zem_contact_reborn?

It’s been covered already but … “zem_contact” is as descriptive as it gets, “form” was misappropriated by TXP a long time ago & it’s off-limits, and leave the tag names alone – backward-compatibility is essential.

“zem_contact_reborn” is only really the name of the plugin anyway. If you want to retain a sense of history, with a descriptive name, but acknowledge change … how about “zem_contact_redux”?

Textpattern CMS

Textpattern CMS support forum

#73 2016-05-24 00:14:58

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #299229:

#74 2016-05-24 00:15:25

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299230:

#75 2016-05-24 00:21:29

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299231:

#76 2016-05-24 00:34:11

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

phiw13 wrote #299232:

#77 2016-05-24 11:58:03

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#78 2016-05-24 12:09:32

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

uli wrote #299243:

#79 2016-05-24 16:26:16

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299244:

#80 2016-05-24 17:07:01

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299244:

#81 2016-05-24 19:15:35

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

maverick wrote #299250:

#82 2016-05-24 21:28:57

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

#83 2016-05-24 22:02:35

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

jakob wrote #299259:

#84 2016-05-24 23:22:10

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

maverick wrote #299250:

Board footer