Steve, sounds like you get it.
Eric, I don't know what that means.
Chef-Scott, you've just explained the "Show Element Using Display Rule" feature of the Form Builder. It's a great feature and I've used it quite a lot. In fact, my form does the exact thing your example showed.
Now, try to picture what I'm wanting to do. I'm talking about the emails; not the form. We'll use your decalsandtrees form as an example:
When that form is submitted, you will get an email with the results from the form. The customer (form-filler-outer) would also get an email with the results from the form. You can style (or configure) the the email to show up however you want. You can leave it how the wfb default shows it, or you can make it fancy.
On your form, if someone clicked "Ship to Billing" then you nor they would ever see any info about the shipping address because they didn't fill it out. In fact, any text field (element that your customer can enter info into) that is not set to "required", and no info is entered into it, will NOT show up as a 'result' in the email that gets sent out. But.... on your form, the email will show up with this in it:
"
Select an Option - Ship to Billing Address" because it is a named element that was selected (had a 'result').
But what if you wanted your email to show up like this:
"
Select an Option - Ship to Billing Address"
"Just to clarify, you have selected that you want your items sent to your billing address."
The "Just to clarify..." line would be on the
form as a Plain Text Element (which doesn't have a 'name') and it would only show up on the form, according to "Display Rule" if they selected the first option (Ship to Billing Address). That's great.
But how would you also get that line to show up in the email like my example above? If you simply type it in the email it will just be in there every time - even if someone actually chose to "Ship to Different Address", and that would be dumb.
So.... it needs to be "told" when to be in the email and when not to be - just like it is told on the form.
Since you can tell the email which 'results' to show by entering the 'name' of the element, and leave out ones you don't want to show by simply not entering their 'name', and since the "Just to clarify..." line is technically a 'result' that depended on which selection they person chose on the form, you'd think you could just tell the email to show it too in that same circumstance, right?
Well, you can't because WFB has told its software to only allow "named elements" from the form to be installed in the emails. The Plain Text Element ("Just to clarify..." line) IS an element, and it IS a result of the form being filled out, but it doesn't have a "name". The only things that WFB has allowed to have "names" are the elements in which the filler-outer can INPUT or SELECT something.
The solution (to this little issue) for future versions would be to give 'names' to EVERY element, OR to instruct the email config to show anything in the emails that you tell it to based on the element's "id" or something. I personally think there is a way to work this out in the current version, but the "way" to do it is beyond me.
Everything I do is custom. And I'd think that coding (web & software design) is the easiest thing to customize - the thing that "if you can dream it, it can be done" because it's all just language. It's all just telling a computer to show what you want it to show or do what you want it to do. I can't make a steel car out of wooden logs. But if I want my confirmation emails to show a certain thing upon a certain circumstance, then it can surely be done. I don't even see how it's that hard. The WFB software is already set up to do this very thing (on the form and in the emails), but it has a built-in limiter by only allowing the emails to show form results that have 'names'.
Surely someone else gets this. I can't be the first person to ever take this software and want it to do something more than "the default", can I? All software (and future versions thereof) are just a bunch of language-typing someone did. They tell it what to do. And for future versions, they just add to what they've already told it so that it will do more. Is there not a true coder out there that can look at this and go, "Oh, okay. This is easy. Let's tell this thing to show me something more than what the designers set it up to show. And here's how we'll do it."? That's exactly what will happen when they sit down to code the next version of the WFB; they will simply tell it to do it. Let's get started on that now, shall we? I'm ready to get my emails to simply show me a simple non-entry result from my forms so I can get this done.
Knowing is half the battle
