cforms II User Forum

Registration is currently disabled.
Guest

FAQs

Lost password?
Advanced Search:

— Forum Scope —



— Match —



— Forum Options —




Wildcard usage:
*  matches any number of characters    %  matches exactly one character

Minimum search word length is 4 characters - maximum search word length is 84 characters

Topic RSS Related Topics
Custom field names into database instead of the field name
How to store the custom fields name specified instead of the field name used for display?
August 30, 2012
7:23 pm
jason k
Guest

Example: Name:[id:name]||

What this does is in the html give the display label name as "Name:" and the name/id of the input field as "name".

My problem is that the database still stores the field_name as "Name:"  instead of  "name".

And when the label is more ridiculously long  like "how much money do you have?" then that is not very nice to try to pull later form the database to reference that field that that long string with spaces and characters.

How to accomplish this?

Thanks

October 12, 2012
3:03 pm
Oliver
Munich, Germany
Admin
Forum Posts: 6400
Member Since:
March 6, 2005
Offline

That's why the Help page talks about best practices around using short labels and keep longer descriptions to text-only fields.

October 19, 2012
11:07 am
Stefan
Guest

Hello Oliver,

but shouldn't the "label" be just a label and not the identifier for a field (accessibility and so)?
I would like to make a form where the label really should describe what the field is for and give it an id that is used for custom meta fields. But the returning array looks like this:

Array
(
    [$$$1] => Fieldset1
    [Fieldset1] => My Fieldset
    [$$$2] => Vorname
    [Vorname] => Gabi
    [$$$kaz_forename] => Vorname
    [$$$3] => Nachname
    [Nachname] => Mustermann
    [$$$kaz_surname] => Nachname
    [$$$4] => Inhalt
    [Inhalt] => Hallo Welt.
    [$$$post_content] => Inhalt
)

 

I know cforms has grown for years and there will be no way to store fields in an array containing label, description, title, errormsg and so on. But that would ease the postprocessing a lot.

October 19, 2012
11:16 am
Stefan
Guest

I've found a solution on stackoverflow which filters the array into a better processable form:
http://stackoverflow.com/questions/3552114/array-f…..ups-in-php

Maybe this also helps jason k.

October 21, 2012
7:17 pm
Oliver
Munich, Germany
Admin
Forum Posts: 6400
Member Since:
March 6, 2005
Offline

Indeed, labels should really be only used as brief field descriptions. Longer text should go into text-only fields .

Re: "array filter" & DB access; why not simply use cforms own API to search, filter and retrieve form data?

February 10, 2013
8:04 pm
Jay
Guest

I came up with a way to achieve the behavior that I think jason k wants. It is approximately the behavior that I want. It is not pretty, but it's simple and seems to work reliably, so here goes:

=====

In cforms/cforms.php, change the line:

$field_name = substr_replace($field_name,'',$idPartA,($idPartB-$idPartA)+1);

to:

$field_name = ( substr($field_name,$idPartA+4,($idPartB-$idPartA)-4) ); 

Then, use the names you want the database to use as the field names, and use the labels you want humans to see as the ids. In jason k's example: name[id:Name:].

=====

The fact that the names need to be "swapped" in this way for every field makes this an ugly hack. I was in a hurry and did not want to risk breaking things deeper in the code, which I was afraid could happen if I tried to get this to work the other way, where I imagined that sanitization might introduce subtle problems. However, it probably can be done without a stupendous amount of effort.

Also, this arguably partially breaks the ability to use the ids as normally intended, which doesn't matter to me.

I believe jason k and I are not alone in wanting a behavior like this, because we want the data from the form to be usable in downstream applications without needing to munge the field names. The more human-readable the Cforms field names are, in general, the more error-prone the munging is going to be. Relatedly, we want the field names to be easy to keep stable even if the human-readable field descriptions are tweaked or changed over time.

Oliver, in your best-practice approach, the human-readable field descriptions should go into a separate text-only field that is logically unrelated to the data fields. Although I would discuss the pros and cons of this with you if you were inclined to have such a discussion with me, I accept that this is how you have chosen to handle the issue. jason k, using that approach, I think people like you and I would want to entirely suppress display of the (ugly-to-human-eyes) field names we need to use, while still keeping the text-only fields displaying their descriptive text. I have not tried to suppress the display of field names in that way, but I imagine it is not too complicated; it may even be trivial. Probably it would be done using CSS.

I greatly appreciate all the time and effort you have put into this plug-in, Oliver. I hope this posting from me has been mostly constructive.

Forum Timezone: Europe/Berlin

Most Users Ever Online: 959

Currently Online:
20 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

tracedef: 43

mores: 21

Gyrus: 20

frozenwaste: 18

asuffredini: 15

photoworks: 14

Member Stats:

Guest Posters: 3708

Members: 1463

Moderators: 3

Admins: 2

Forum Stats:

Groups: 1

Forums: 4

Topics: 5307

Posts: 18665

Newest Members: juredujmovic, dreamkeeper, rajattyagi, wrokaa, lukass

Moderators: Paul (421), cnymike (8), sonika (95)

Administrators: Oliver (6400), Nicky (3)