This is a really bad oversight. I’d love to be proven wrong.
Here’s the scenario:
I have a set of schools offering music lessons in a variety of instruments. The conditional fields are the instrument lists because they are unique to each school.
And here’s the problem:
In the save to mySQL settings, each instrument list form item needs to be enabled, to send the data. So then it sends the whole dam lot (instead of only the field from the list made visible to the end user), which means you will always get the first entry on the last list sent to mySQL.
This needs to be recoded! It’s a common scenario, and it breaks because the conditional fields are essentially the same form item, which need to populate ONE mySQL field.
“Hide and show items based on the values of other items.”
There are no claims that it will swap out what data that is sent to MySQL.
To be clear, ALL checked items are passed to MySQL for INSERT.
I recommend renaming your table columns to instrument_1, instrument_2 and instrument_3 and then use your own coding to process which column to pull data from based on the school value.
No it doesn’t answer my question. My own coding? How do I do that? That would answer my question. From what I can see there are no disclaimers either, that conditional fields don’t play nice with the mySQL implementation. I would expect that the data the end user enters, is what is sent to the mySQL database. Otherwise in my view, it’s broken.
Right – I see what you’re getting at. Fix it in post-processing. A bit of a let down, it’s the only reason I upgraded to FL4, for the conditional fields. But they are essentially useless if you’re using mySQL.
My recommendation for you, in order to make your product awesome, would be to solve the problem within the plugin. Make it intelligent enough to send data only from the conditional fields deployed by the end user.
I liked the post because I felt @yabdab did a good job explaining how the stack works. I’m a total noob when it comes to anything dealing with MySQL. I dread databases, where @yabdab seems to have a good mastery of them.
That said, it unfortunately doesn’t seem like the way the stack is designed to work lines up with how you wish it to work. Not all products work for every task we wish they did. This looks to be the case here. It seems you’re trying to use a tool, designed a certain way, to do a task it isn’t built to be able to do.
Your original posts seem to be on the attack instead of asking if the stack works like you think it should. When @yabdab responded to let you know how the stack works that would have been a great opportunity to perhaps ask more questions or maybe even ask if it would be possible to implement such a feature in a future update. Instead it seemed like you took his reply as an affront. I don’t believe he meant any ill-will by his post. He was simply explaining how his product works. It just unfortunately doesn’t do the specific task you are looking for at this time.
I would expect that if a product claims it does A, B, C, D, & E, that it might also do say B & C at the same time. And if not, it might state that fact. The use-case I’ve presented is standard fare, not some esoteric whim, and as such I was really surprised to find it failed in this regard. As for “explaining how the stack works”, I’d already done that.
And yes, it’s unfortunate. And you’re right, I didn’t ask if it would be possible to implement the feature in a future update, rather I suggested it should be. So moving on, anyone know of a stack or solution which can achieve this (aside from mySQL post-processing, that is)?
I think you over estimate how common this scenario is. Most database-based sites do not use the same information in multiple variables with the same name, which is creating the problem for you.
I disagree. It’s one field, “Instrument”. Making thirty “Instrument” fields in mySQL because I have thirty schools would be cumbersome and a nice way to slow the database down, for starters. Not to mention creating straight-forward sorting problems.
I was not suggesting that you create 30 “instrument” fields in your database. That would also be uncommon as well.
What is commonly done, is to have one “instrument” field on your form and not multiple “instrument” fields on the form with some of them hidden. One on the form and one in the database table. Usually, they will not populate that dependent field (your instrument field) until the first field has a choice selected (your school field).
If you’ve ever used an auto parts lookup engine, this is how those are done. They have one “model” variable and not hidden variables for each manufacturer.
Sure Don. The dev’s response though is exactly that, essentially “create 30 Instrument fields in mySQL”.
My understanding of your suggestion is that the Instrument field list values are dynamically built on the form according to school selection. Unfortunately, FormLoom doesn’t do this. It has conditional visibility logic which means having multiple instrument fields, all hidden bar one. Whether Mike can program it so the visible one is the one used to populate mySQL, who knows.
I guess I was just surprised that it’s entirely possible to have a form submitted and incorrect data going to mySQL. Also I’m kinda not surprised, because I can see the design limitation.
Andy - Perhaps I misunderstand, but it appears you are trying to do something for which MYSQL was not built. The object of relational databases is to eliminate duplication. If you expect to have a field in your database with a listing of instruments for each school, you are breaking one of the first rules of database efficiency (nerd speak calls this Normalization). You could build three tables. The first is the school info (index, school name, email, and any other information). The second is an instrument list (index, class (woodwind, percussion, etc), instrument name(clarinet, piano). The third is the tricky one. It would consist of the index for the school and the index for the specific instrument. In that way you could search school, class of instrument, or specific instrument. The third table is actually the one you are trying to build using the form. I don’t see how it can be done that way. Each line of the third table is actually an update transaction to the third table. Usually, this kind of work is done through a PHP application which sits between your form and the database.
You are correct in saying this is a common use case, but it is usually solved using a CRUD (Create, Read, Update, Delete) application. Stackits has EasyDB. Kuler Solutions used to have a nice suite of database tools (sadly, they are no longer available.)
I hope this explanation is helpful. if I have misunderstood what you are trying to do, please forgive me. Best of luck to you. What you want to do is very possible, just not the way you want to do it.
