Custom Field Input Tag

maverick · 2015-07-07 02:53:32

With the looming Custom Fields, I have this dream (pipe dream?) of a new set of textpattern tags (or less desirable, a plugin) that allow us to created custom input forms for entering data straight into these new fields (or existing fields).

A crude example, but something like:

<txp:input form>
<txp:input field=“data field” />
<txp:input_submit_button/> (or better yet, the input form tag has the submit button baked in)
</txp:input_form>

Then behind the scenes a new record is appropriately created for each field and related as appropriate.

A broad, generic set of tags like these would allow the creation of admin type pages on the front (obviously there would be a need for user permissions in such a use case). Or article submission. Or a roll your own commenting system. Or a contact form. Or users could create/update their own user profiles, or a purchase form for an eCommerce site. Any data field or set of data fields could be exposed for use – on the front side or on smd_tabber

Last edited by gaekwad (2015-07-07 10:19:15)

Bloke · 2015-07-07 08:58:07

maverick wrote #292701:

allow us to created custom input forms for entering data straight into these new fields (or existing fields).

We share the same dream (hmm, isn’t that a song lyric?!)

My (albeit sketchy) plan is to try and utilise the power of the custom_field tag itself to render widgets. But instead of letting the core handle the form processing, that’d be up to plugins. Example:

<form name="my-article-post-thingy" method="post">
   <input type="hidden" name="ID" value='<txp:article_id />' />
   <txp:custom_field
      name="colour"
      type="article"
      format="input" />
   <txp:custom_field
      name="size"
      type="article"
      format="input" />
   <input type="submit" name="send" value="Post" />
</form>

By default, the format attribute would be set to value (or something like that) which will display the field’s value. Switching it to input will tap into the routine I have in place for rendering admin-side widgets on the various panels. It just needs a little bit of tinkering to open it up. Rendering a tag widget raises a callback so a plugin can intercept it and set up its own internal array of “expected values”, or completely rewrite the widget if desired.

The tag would also be extended to take wraptag and class attributes. Might even add break and permit a list of names so you could render a bunch of fields in one go. You may also be able to use format="label" to display the widget’s human-readable label.

I have the idea at the back of my head that you should be able to use a <txp:custom_field_info> tag so you can pluck out individual snippets of info from your field and roll your own whatever, using the <txp:custom_field> tag with a form/container.

But the simplest output means you always get the correct type of widget for your field, based on its data type and options that you’ve configured in the admin side. Of course, if you want to override that and bake your own form, that’s up to you.

It would then be up to the public plugin (not shown in the example above) to handle requests, sanitize the data and do the actual DB wrangling, updates, inserts, and so forth. The plugin would also be responsible for injecting the content ID of the thing you’re editing in place of the basic <input name="ID"> I used in the example above. I wouldn’t recommend coding it in plain view like that! mem_form or zem_contact_reborn would utilise a secret form field.

Complete front-side form processing is currently outside the scope of Textpattern so all I’m proposing is a framework for allowing widgets to be rendered and plugins to fill in the gaps. If longer term, front-side editing is enough of a draw and it can be done safely then it can be considered later.

How’s that? Any flaws?

gomedia · 2015-07-07 13:43:06

It’s not quite what you’re after but I’ve got a beta version of adi_contact (mentioned here) that takes data from zem_contact and puts it in a database table (that has been created previously). I’m using on a live site to record information submitted via contact/enquiry/survey forms, which also send emails as normal.

How would something like <txp:custom_field format="input" /> compare/compete/relate to zem_contact’s input field tags?

Bloke · 2015-07-07 14:02:05

gomedia wrote #292752:

to record information submitted via contact/enquiry/survey forms, which also send emails as normal.

Niiiice. Didn’t spot that. If it comes down to offering front-side publishing, I’ll be sure to look at what you’ve done.

How would something like <txp:custom_field format="input" /> compare/compete/relate to zem_contact’s input field tags?

The only major difference is that, when building a form with ZCR or mem_form, you decide which widgets to use. If you want a text area, you use the <txp:zem_contact_textarea /> tag. If you want a checkbox: <txp:zem_contact_checkbox />, etc.

Using the custom fields approach, that decision is taken out of your hands (by default) and the rendered widget is determined by what has been defined for that field on the admin side. If you’ve said that custom 16 is a checkbox set, that’s what’s rendered. You can override it, but that saves you the hassle of picking the appropriate widget. And if you change the CF definition (assuming you’re comfortable with potentially losing data if you move to an incompatible field type), both the front-end and admin-side widgets change accordingly, immediately.

gomedia · 2015-07-07 14:20:49

Bloke wrote #292759:

The only major difference is …

But also, adi_contact_db writes to specially created tables, whereas it looks like <txp:custom_field format="input" /> writes to the ‘textpattern’ (i.e. article) table? One would need to take care!

… the rendered widget is determined by what has been defined for that field on the admin side …

That’s a nice touch.

Bloke · 2015-07-07 14:47:56

gomedia wrote #292763:

adi_contact_db writes to specially created tables, whereas it looks like <txp:custom_field format="input" /> writes to the ‘textpattern’ (i.e. article) table? One would need to take care!

Yeah, the plugin that surrounded the form would need to write back to the corresponding field to which the widget belonged or it would all fall apart.

The field’s name is unique among content types (so you can have only one price field on articles, but can have a price field for images too if you wish). They also have auto-increment IDs which are mostly internal for uniquely identifying fields. Although they are exposed, their use is discouraged in favour of the (sanitized) name.

maverick · 2015-07-08 16:51:13

Bloke wrote #292719:

We share the same dream (hmm, isn’t that a song lyric?!)

It’s a good dream! :D

My (albeit sketchy) plan is to try and utilise the power of the custom_field tag itself to render widgets. But instead of letting the core handle the form processing, that’d be up to plugins.

That makes sense and sound pretty good.

A question/thought: Is using the custom field tag (as named) intuitive?

Textpattern tags have evolved over the years. When I first started with Textpattern, there seemed to be more of a “one tag, one purpose” philosophy. A few years back we seemed to modify that towards a more swiss army knife approach. one tag, with lots of possible attributes that could make a single tag more flexible.

So on the convenience side, a single tag that can do both input and output seems nice. It might not be as intuitive as a flat out <txp:input /> tag. Especially since custom field tags would be the only tags with the input/output feature. They would be an exception to the SOP of txp tags.

Also along that line: custom field isn’t completely intuitive as a name. I read custom field tag, and if I were a newbie I would think – this is for custom fields. But in reality it exposes most (all) txp fields? It really is a <txp:data_field /> tag.

I’m not sure what the answer is . . . deprecate the custom field tag name for something more reflective of it’s power. Move back to a more single tag / single use philosophy. Go with “meh, not big deal. Just learn the tag”. The latter is the simplest way forward :P

The plugin would also be responsible for injecting the content ID of the thing you’re editing in place of the basic <input name="ID"> I used in the example above. I wouldn’t recommend coding it in plain view like that!

I agree there are a couple of fields that probably should never be exposed publicly. Either required to be a hidden field, and/or not available from the front. Just for reasons of safety/exploit/dang, you could really break the database by doing that.

so all I’m proposing is a framework for allowing widgets to be rendered and plugins to fill in the gaps.

It sounds like a really good place to start!

front-side form processing is currently outside the scope of Textpattern . . . If longer term, front-side editing is enough of a draw and it can be done safely then it can be considered later.

I like this. Here’s why:

A content publishing system asks “How do we get the content out?” A content management system, a good one at least, ask “how do we get content in, organize it, and then get it out?” Publishing to a website being only one way to get the data out.

If we are going to be Textpattern, a Content Publishing System known for it’s xml-like tags, that’s fine and we already do it well.

If we are going to be Textpattern, the Content Management System, then we have to broaden our concept of what belongs in a lean and mean core. Input becomes a major player capability-wise – whether front side event/form processing or backside input design.

Given the wide spread use of zem_contact_reborn, glz_custom_fields combined with bot_write_tab_customize, and to a lesser extent, smd_tabber, mem_form, and adi_contact_form beta – I think we have an answer from the community regarding the use and importance. However we implement core friendly input, it’s a major part of who we are becoming. Leaving the bulk of the heavy lifting to a plug in is a necessary place to start, and I’m supportive of that. But if it is important to being a CMS, having a lean core aptitude for event/form processing from the front probably should be part of the vision.

I’m excited by the future.

Thanks Stef!

Last edited by maverick (2015-07-08 16:54:00)

maverick · 2015-07-08 16:55:44

gomedia wrote #292752:

It’s not quite what you’re after but I’ve got a beta version of adi_contact

It would be great to have get a copy. Could I so impose?

Thanks!

Edit

I’m unclear – does adi_contact do this automatically, or just the beta version? If v.05 does it, then I’m all set.

Last edited by maverick (2015-07-08 16:57:23)

maverick · 2015-07-08 17:03:29

Bloke wrote #292766:

The field’s name is unique among content types (so you can have only one price field on articles, but can have a price field for images too if you wish).

To clarify (I think the answer is yes) – a single form would be able to submit to multiple content types?

eg both

 <txp:custom_field
      name="colour"
      type="article"
      format="input" />

and

 <txp:custom_field
      name="colour"
      type="image"
      format="input" />

They also have auto-increment IDs which are mostly internal for uniquely identifying fields. Although they are exposed, their use is discouraged in favour of the (sanitized) name.

auto-increments IDs – I would be hesitant to expose those for input outside of a database editor.

Bloke · 2015-07-08 20:47:09

maverick wrote #292891:

I’m not sure what the answer is . . . deprecate the custom field tag name for something more reflective of it’s power. Move back to a more single tag / single use philosophy.

Yeah, reusing the custom_field tag is probably the lazy option! I take your point about a new tag dedicated to input, and that’s a worthwhile consideration especially give your compelling confuse-a-tag reasoning. I’ll consider all angles, believe me.

Juggling tags and attributes is one of those things that’s harder labour than one might expect from the outside. We have over 150 tags so I’m mindful of introducing more, as it may lead to the comments debacle where in reality, four or five would do. But I appreciate that one tag with a zillion attributes is over the top and obtuse.

<txp:images> is a good example that strikes a reasonable balance. You can get away with just that and/or <txp:image_info> to build virtually any gallery structure you want by hand, but there are a few supporting tags that expose key parts of the image for convenience. They are largely unnecessary, but offer handy functionality. For example, the format attribute of <txp:image_date /> and the flexibility of using <txp:image_url> as a container. In the comments era, the implementation may have added one tag to output the image extension, one for the image name, one for the width, one for the height, …

bq, if it is important to being a CMS, having a lean core aptitude for event/form processing from the front probably should be part of the vision.

And I largely share that vision, with a caveat. As you rightly say, the admin-side is but one data entry mechanism. My only reservation over front-side editing comes from being mindful that we’ve just axed the <txp:rsd /> tag precisely because the vision for writing externally and publishing into your CMS just didn’t gel with users.

If we’re going to go for front-side editing one day, we need to learn from such mistakes of the past and do it right, not just for the sake of it “because we can and it’s cool” but because it fulfills a need.

a single form would be able to submit to multiple content types?

Yes.

Textpattern CMS

Textpattern CMS support forum

#1 2015-07-07 02:53:32