search

No-Half-Pixels / Fluent-Framework

WordPress Options Framework with a difference
http://no-half-pixels.github.io/Fluent-Framework/
5 stars 2 forks source link

Dynamic field preset through other fields #32

Open ghost opened 10 years ago

ghost commented 10 years ago

Something that I would like to do is have one field or a set of fields act as a preset starting point for some other fields in the options page. I will give you an example of a scenario where I might use this or others might use this.

I would like to have a main tab called Presets, the fields in here will preset the theme to be either boxed or full width. If the user selects the boxed option, then a new field will appear with a boxed_width slider field.

This boxed_width field value will be used to preset the default values in the header_wrap max width field, body_wrap max width field and the footer_wrap max width field.

the end user when they get to these fields in the settings can then choose to overwrite the setting of for instance the footer or body however they like. If this does not make sense I will be happy to display a screenshot of what I have tried within redux in which I am wanting to make the switch over to NHP.

leemason commented 10 years ago

hello cmwwebfx,

it does make sense, sort of.

i think with the current version of the framework the best way to implement this would be to have a preset field similar to redux, where by you have a list of presets, that can be displayed as a list of images like the radio image field.

when the user clicks on a preset they would get a warning saying "we are about to set some default values for you ....".

they either confirm or cancel via the dialog and if they confirm the page gets submitted and the values stored against that preset option will overwrite the options they are for.

so:

  1. user clicks a preset
  2. confirms preset
  3. page gets submitted
  4. the preset options get set against the options saved to the db.

it would work very much like the restore defaults function, to give you a better idea.

in the future i think we could make this dynamic a lot easier without the page reload.

I'm currently investigating either angular js or backbone to display the options. when we have one of those working we should be able to change values on the fly regardless of the field type used as the data would be store in json and not through a page submission.

the new backbone/angualr version may or may not be different in how we define the options. so we are building it as a separate class (Fluent_Options_Page_V2), so there would be no conflicts with older versions.

of course it will not be a separate product, it will just be another class that can be used (so uses could still use the old "deprecated" classes).

ghost commented 10 years ago

OK, this sounds like a good compromise on pre-setting some fields. I presume these other three fields once they are preset can then be updated manually by the end user without causing any issue?