Need your advice: huge form with dynamic elements and multiple groups

[sales2010]

Hello,

I need your advice about this project.

The final result should be simple: a pdf file containing selected data and info retrieved from database. The problem is how to do it in a very easy way for all users involved in this process.


Think to a list of subscriptions. Each subscription will have almost 70% of form fields common with other subscriptions. But the rest of 30% it could mean another 5 or 10 new fields for each subscription. Having over 1200 subscriptions and new ones added every month...soon i will have a huge form and a big problem with performance for this form.


So i was thinking to re use fields for each subscription. I should have only a list of 25-30 fields, lets call them F1, F2...F25

Depending of what user will select(service (a list of main services) -> subscription class (subscriptions will be grouped in classes) -> desired subscription), it should autofill the fees in fields starting with F1. To make it easy for them, users will use "Repeat group" option to add more subscriptions to the same pdf file.

First problem encountered: how can i dynamically change the label of F1, F2 etc. in form, so Editors and Users to know what value they can add/modify (yes, the editors should complete values in another form in back-end for those fields, and users should be able to edit filled values) for F1, F2 etc.?


I hope i was clear of what i need to get at the end, it's a little confused for me too

Of course, any ideas are more than welcome

Thank you

 

[cheesegrits]

We currently don't have any way to dynamically change the labels on elements. The only way I cna think of doing this would be to have a "master" list, with all your F1 thru FXXX elements, then for each version of the form, copy the list, and edit the elements in the copy. So you end up with a separate set of list / form / group(s) / elements for each "version" of the form.

Hmmm, rereading your post, where you talk about literally thousands of different versions of the form ... I'm not sure that's a good approach, though. With (say) 50 elements, that means potentially hundreds of thousands of element rows on the backend, and thousands of lists and forms. Which is something we've never even come close to.

But i really can't think of any way of any way of dynamically setting element labels that makes sense, and would be maintainable in the long run.

-- hugh

 

[sales2010]

Thank you, cheesegrits

Do you have any plans to add this feature (dynamically change the labels on elements) in fabrik? Just want to know if i should wait for a while, or start thinking to other way to do this.

 

[cheesegrits]

You are the only person who has ever asked for this feature, and it wouldn't be trivial to do, as it would mean working out some easily configurable way of creating labels on the fly. So no, it's unlikely to "just happen" real soon, unless of course you wanted to pay us to do it.

How are you imagining that the different versions of the form would be differentiated? In other words, when Fabrik is building the page for a new form, how would we know which version of the form it is? From the J! menu Itemid?

-- hugh

 

[sales2010]

i'm not thinking of different form but different show/hide fields in the same form. For example:

For subscription 1 it will display fields F1,F2,F5, the rest of fields will be hidden
For subscription 2 it will display fields F1,F2,F3,F4, the rest of fields will be hidden
For subscription 3 it will display fields F5,F6,F10, the rest of fields will be hidden

as long each row will have an internal id and some other selected options (service id, class id etc) i think (is just a thought) it might work. But i have to change the label for fields every time a subscription is selected from a dropdown list (and before this selection, it will be another 2 dropdown selections), so when i select:

service 1/class 1/subscription 1, the F1 field will have the label: Nr of minutes
service 1/class 1/subscription 2, the F1 field will have the label: Nr of sims included

and so on..

 

[sales2010]

Hugh, can you send me a PM with a quote for this feature (dynamic labels)?

Thank you

 

[troester]

What about some extra elements holding the labels (eval default depending on the selected subscription type)?
And a custom template displaying those (readonly) elements instead of the original labels.

 

[cheesegrits]

Hmmm. So ...

But i have to change the label for fields every time a subscription is selected from a dropdown list

... this means this would have to be done in JavaScript. And, if it is to be done in a way which is maintainable, it would need to involve AJAX calls to the server to grab the element / label pairs that need changing, which it would only make sense to store in a metadata table, which stored element_name, subscription_plan, visibility and label for each useage case.

So whenever you make a dropdown selection from the subscription, it would make an AJAX call to the server, which would look up the plan ID in the metadata table, and return a JSON array of element names and labels that need to be changed, and which elements need to be shown/hidden. The AJAX response handler in the JavaScript would then have to loop through that array, changing labels in the DOM on the fly, and hiding / showing elements accordingly (rather than using the element JavaScript FX feature on the backend, which is great for simple cases, but gets very cumbersome if you have lots of permutations to handle).

We'd also need an onLoad function, which set up the labels to their initial state, for whatever value the subscription has on form load. But that would simply need to trigger the same function that the dropdown menu triggers, so not a biggie.

I'm guessing this would probably be a days work, when all is said and done, code written, installed, tested and the metadata built for the various subscription states.

Once done, you'd be able to add, remove and edit the label states for different subscriptions by just modifying the data in the metadata table, no coding or any other custom work required.

Let me know if you want to pursue this.

-- hugh

 

[cheesegrits]

PS, just to make sure we agree on terminology, by "metadata table" I just mean a normal MySQL table. Metadata just means "data about data", i.e. data which describes how to render or process your actual "real" data. So for instance the Fabrik tables like fabrik_elements and fabrik_forms conatin "metadata" describing how your forms and elements are displayed and processed.

-- hugh

 

[sales2010]

Hello cheesegrits,

I agree with your approach, javascript and retain the values in a mysql table should be the way to do this, also because at the end the values should be retrieved and displayed in a pdf file in a specific shape.

Just few notes:

- it have to work in IE8 (company official browser..don't ask me why ). The app will be used in our intranet, so as a second note:
- i don't have a testing server to be accessed from web Don't know how to solve it, maybe you have one?
- we need a chain of selections. First, the Service will be selected, then the subscription plan.
- it have to be manageable by some non-technical users, they will have to administer the labels and subscriptions and fees.
- it have to work with repeat group feature, a user will usually add 3 or 4 subscription plans on a client contract

So, in my mind i see the following flow to be used:

1. Administrators will create the F1-F25 fields and will add the validations (this will be tricky because not all the fields should be validated for all the subscriptions,but that's another problem, i think i found a way to make it work more or less dynamic depending on which subscription_plan id has been selected)
2. Editors will add the subscriptions , assign the labels to the fields and fees for each field or any other option you want me to use, just to be easy for users to administer and also, to be dinamic.
3. Users will select the service (Mobile Voice, Fixed voice etc) then the subscription_plan and see the fees added by editors (i will use the autofill plugin) for each field. The values have to be editable. Then will press the submit button and generate a pdf file (the contract for the client).

so..what you think?

 

[sales2010]

friendly bump..

 

[Peter_S]

If my may humbly chip in here. Sales2010 isn't actually the only one who ever asked this question. I have not an identical but related problem with pulling labels dynamically into forms. Maybe Hugh, you are going to complicated with this. With a little prep in the database you could pull the questions from one table and the answers from another then have a third table telling you which customer gets which labels and questions and more or less that's it.

troester had this idea, which makes sense at face value: Put the labels in calc elements, the answers in cascading dropdowns (first element = language, second element observing language to be pointed to the right table to pull the answer-options dropdown. Then you save only id values in your actual responses table, making the responses completely language-independent (or whatever your first cascading element may be).

You need this everytime you do a multilanguage form where you don't want to reinvent the wheel for every language, which if you need to support 5 or 6 languages (not uncommon in the Enterprise world) this becomes ridiculous with large forms, as you rightly stated earlier.

If I may point you over to lime surveys, they do this with a drop down in the php/MySQL environment. I have done this in access VBA with literally 3 lines of code. For better explanation and a little acces file that does this:

See:
http://fabrikar.com/forums/showthread.php?t=29091

 

[Peter_S]

Brainstorming further, could there be a form 1 (F1) which has dropdowns and autofill boxes for all important parameters including customer number, contract number, language or whatever, plugin a redirect at the end of F1, while attaching all field data to the url jump onto form2 (F2) where the labels are calc fields populating themselves on the basis of the info in the url. Where you then do what you have to do in terms of data entry. I didn't understand whether in the process you need to change data that changes labels again dynamically or whether that is a one time front-of-house occurence.

If I may, from a meta perspective, the idea of newly developing anything as complex for a mandatory IE 8 client now? That product is EOL and its successor IE9 is supported for the lifetime of W7 which is going away. After that compatibility with anything is going to be dependent upon religious execution of support packages or Microsoft is going to wipe their mouths, saying: "I told you so". I don't know how good your organization is with executing IT updating strategy across the installed base, but if your co is still on IE8, that raises some doubts in my mind at least.

So if that application is possible at all, erring on the side of using as little browser plugin technology as possible and staying as plain vanilla as possible might be warranted, if you don't want to create a support nightmare for user and developer, none of which is going to be responsible for any of the problems you are going to potentially face. So if this is a live commercial application I guess there is going to have to be a very large service risk premium in the development price, since rightly so or not you will come back to the developer with any problem that pops up based on whatever and if there is money involved or money lost potentially at the point of sale, you get my drift, if it is built on a shaky platform such as IE8, which even I have LOTS of compatibility issues, just trying easy stuff such as CSS

Only reason I'm becoming involved is, I was going to offer to co-fund that development since I take a vested interest in this for one of my projects, but on consideration I think this is going to have to be unnecessarily expensive/risky and there might be easier ways to accomplish the same thing with addressing the underlying complexitiy in your description of business process rather than trying to fix it on the application level.

 

[sales2010]

Hello,

Thank you for the messages, Peter_S

About IE8. It's not my idea to make this application to work specially for this browser, but we'll use the app internally, in our intranet. And, some guys from IT decided that IE8 it's the browser that can handle all kind of applications made by both vendors and "home made". Long story...

I have to redesign the flow, meanwhile i got many new feature requests for this application. Reading users requests, soon this application should be able to make chips, dance the salsa and drive a car

I will return to this message in few days. Thank you all.

 

[Peter_S]

Don't forget the piece where the soft brews cappucinos for waiting clients AND serves them with a little cookie. Always a sure winner with budget owners.