zem_contact_reborn v4.5.0.0: contact mail form processing

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”?

maverick · 2016-05-25 00:26:37

gomedia wrote #299264:

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.

Perhaps it has been covered before. I vaguely recall some of those discussions. That doesn’t mean the outcome to stay with the name was inherently the best outcome :)

Respectfully, I disagree that “zem_contact” is as descriptive as it gets. That says “zem” has a plugin that “offers a contact form. Except zem isn’t the person maintaining it, and I suspect zem is not the person who has contributed the majority of the code these days. More importantly, it is much more advanced than what most people consider a contact form. It can be pressed into use for a variety of services.

As for backward compatibility, I appreciate that, but I think as a community we came to the realization that we had over emphasized backward compatibility and have moderated a bit on that value. It was holding us back. I don’t see the issue of updating the front side as a particularly major deterrent. A good search and replace function goes a long way. And if the plugin ceased development, as so many other plugins have over the years, we would change our code to use whatever new alternative was available. It’s the same basic principle.

I believe it’s simple marketing. I love the txp community. But marketing isn’t about serving the insiders of the community who share the history. Even if it was, I doubt a majority of us care about the historical aspect of zcr. Certainly new people checking out Txp don’t care. What they care about is – “can I make x kind of form?” If they see a plugin that says “form maker” they immediately have their answer. No need to read a plugin forum thread to find out that it can do radio buttons and check boxes and mail chimp and form validation, etc.

But as Bloke so kindly pointed out – its easy to say – let’s rename it, when that means a lot of work for someone that’s not me. It’s a big job. It seems to me that when a plugin has its own api for other plugins to build off it, it has gone beyond a typical plugin. It begins to echo the “module” concept of crockery.

Perhaps a better suggestion is for a 5.0 road map goal that moves the form creation platform aspect of zem_contact into a core add-on module, designed from the ground up to interact with the new unlimited custom fields that will have been added. This then would allow multiple plugins that create specific forms – contact forms, mail chimp forms, user registration forms, upload forms, and perhaps even the base for commenting and/or forums. The level of change would merit the effort to make the change. Perhaps we could even tackle the issue of changing the current “form” nomenclature to something more intuitive as well. If I recall correctly no one particularly argued for retention of forms. It was more the size of the undertaking to make the change.

Anyhow. Just threw out the suggestion because I think there are better options.

Bloke · 2016-05-25 09:07:24

maverick wrote #299266:

That says “zem” has a plugin that “offers a contact form.

Trueish. It means that at some point in the past or present, zem was or is maintainer of said plugin. When people take over a plugin they don’t necessarily automatically rename it, out of respect for the work put in by those in the past. Plus, it avoids upgrade hassles for those that rely upon it.

The prefix is mainly there to help protect Txp from function name clashes, which harks back to its ‘global namespace-centric’ history. If Txp was more namespaced, the prefix wouldn’t be as important, which might eliminate the owner hurdle. Although it does aid branding, up to a point, of a particular plugin author. e.g. “Those damn smd_* plugins: functional, but so insecure!”

I don’t see the issue of updating the front side as a particularly major deterrent.

Tell that to those people who run fifty sites off a variety of codebases on a single server and use ZCR on each one! There are people that do that kind of thing. But yes, it’s not rocket science in ZCR’s case, just grunt work.

when a plugin has its own api for other plugins to build off it, it has gone beyond a typical plugin. It begins to echo the “module” concept of crockery.

Yes. Plugins like mem_form and now zcr allow a lot of additional functionality to be bolted on.

Perhaps a better suggestion is for a 5.0 road map goal that moves the form creation platform aspect of zem_contact into a core add-on module

Maybe. The argument has always been that contact form functionality is not a core feature. Just for a change, I’m on the fence.

etc · 2016-05-25 09:26:03

Bloke wrote #299270:

it avoids upgrade hassles for those that rely upon it.

This could avoid upgrade hassles too:

Txp::get('\Textpattern\Tag\Registry')
	->register('new_name', 'old_name');

Who knows what hides itself behind <txp:article /> now…

Bloke · 2016-05-25 09:27:54

etc wrote #299271:

This could avoid upgrade hassles too

Neat! Forgot about that.

maverick · 2016-05-25 13:41:17

Bloke wrote #299270:

When people take over a plugin they don’t necessarily automatically rename it, out of respect for the work put in by those in the past.

I get that. But once it’s evolved long enough and far enough . . .

Bloke wrote #299270:

Tell that to those people who run fifty sites off a variety of codebases on a single server and use ZCR on each one! There are people that do that kind of thing.

I stand properly admonished on that point. There are situations where it would be a boatload of time and effort, and fairly, some people view that as a show stopper.

Over the years, those who value backward compatibility have usually been the loudest voices, and more often than not, to the benefit of Txp and the community. I appreciate that greatly. However, some of the time its also been to our detriment.

My intention was to offer another viewpoint – that there are those of us who come from a different perspective in our discussions on backward compatibility. – which is we don’t object to those types of change, and even expect change . . . that sometimes you have to break with the past to move ahead.

Finding the right balance – that’s where the fun is :P

Bloke wrote #299270:

The argument has always been that contact form functionality is not a core feature.

Having a way for someone to make contact with the person in charge of a website seems pretty basic these days. Even so, if I viewed zrc (and its potential) as a simple contact form (say three fields – name, email, message) that sends an email to the webmaster, I agree it probably does not belong in the core.

But if one steps back from the concept of a simple contact form, and thinks in terms of generalized form creation, I believe the broader use case and functionality argues for a more elegant integration.

Ultimately in managing content we have at least four core functions: adding content, organizing content, search and retrieval of content, acting on content (in Textpattern’s case this is most often publishing content as html).

The ability to elegantly create forms addresses the core functionality of adding content. Perhaps it might be a simple contact form that by passes adding content to Txp proper, emailing it instead. That would not be a core function in my opinion. A contact form that puts the message into the database in CMS would speak to core function, but weakly at best.

However, the generic ability to create all kinds of forms that add content for Txp to manage – imo that speaks directly to a core function. Perhaps it a user self-registration form. Perhaps it is front side article editing or a new article submission form. Perhaps it is a forum post, Perhaps it is an e-commerce order form. Perhaps it is a job application form. Or perhaps it is a simple contact form. Perhaps it is used on the front side. Perhaps it is used on smd_tabber on the backside. When the functionality is viewed as a whole, rather than as a specific use case, I think the argument for core capability becomes very strong.

All the more so with the advent of unlimited custom fields. More fields is likely to lead to more people wanting more ways to interact with those fields. :D

Obviously – just my perspective.

Last edited by maverick (2016-05-25 13:44:48)

Bloke · 2016-05-25 13:46:52

maverick wrote #299277:

Finding the right balance – that’s where the fun is :P

And that’s Textpattern all over! Trying to offload ~~bloat~~ non-essential functionality to plugins and keep the core lightweight and fast. Obviously errors have been made in the past *cough* Comments.

if one steps back from the concept of a simple contact form, and thinks in terms of generalized form creation, I believe the broader use case and functionality argues for a more elegant integration.

I like your thinking. Definitely something to bear in mind as work on unlimited custom fields progresses.

Textpattern CMS support forum

#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:

#85 2016-05-25 00:26:37

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

gomedia wrote #299264:

#86 2016-05-25 09:07:24

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

maverick wrote #299266:

#87 2016-05-25 09:26:03

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299270:

#88 2016-05-25 09:27:54

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

etc wrote #299271:

#89 2016-05-25 13:41:17

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

Bloke wrote #299270:

Bloke wrote #299270:

Bloke wrote #299270:

#90 2016-05-25 13:46:52

Re: zem_contact_reborn v4.5.0.0: contact mail form processing

maverick wrote #299277:

Board footer