search

wooey / Wooey

A Django app that creates automatic web UIs for Python scripts.
http://wooey.readthedocs.org
BSD 3-Clause "New" or "Revised" License
2.11k stars 182 forks source link

Conditional Field #24

Open mfitzp opened 9 years ago

mfitzp commented 9 years ago

@streetmapp Your issue has been moved to this repo (the base for future work).

Looking to have a confirmation field available in certain cases. One way to achieve this that I'm aware of is to have the field always there, and execute some checks that way. Ideally, the field only shows when a particular condition is met.

The main use case is to prevent accidental execution if ENV = PROD.

Is this a potential feature request?

mfitzp commented 9 years ago

Are you describing subparsers for argparse?

Like this SO question: http://stackoverflow.com/questions/9505898/conditional-command-line-arguments-in-python-using-argparse

This sounds like something for the 'clinto' package, which can implement subparser processing. I'll created an issue for that.

An alternative would be the creation of our own view that allows decision trees to be created with filters..but I'm thinking that is a lot of work and too situational for my liking -- but it might also be something already implemented by some javascript library.

mfitzp commented 9 years ago

Good -- I think subparsers are a good way to implement this.

Chris7 commented 9 years ago

As a form is a pre-generated structure, this can be encoded on an input field's widget dictionary to provide conditional logic. For instance, we have 2 subparsers: a/b, each with fields a-choice, b-choice.

Input for the radio button/whatever representing the subparser will have the attributes: data-reveal-a="a-input-name" data-reveal-b="b-input-name,extrafields"

On initialization we hide all fields that need to be revealed, and hook into the input method of anything with data-reveal to control any inputs that need to be toggled.

What needs to be figured out is the best way to model this on the database. I'm considering introducing two new ScriptParameter flags: 1) a boolean to indicate a parser, 2) a collection of ScriptParameter corresponding to that parser. This changes the field buildup to first search for parsers, then build up parameters from that parser. This is reflective of the dynamic nature argparse/click/etc. allows -- where an argument can be under multiple subparsers instead of the rather static approach we've taken so far.

Chris7 commented 9 years ago

Each subparser may have different fields. Perhaps the best way for this is to organize our tabs by subparsers? With the default case of a single parser, nothing will change, but we could have our current setup nested under each subparser.