Hi Glenn, > [UI] > Thoughts? Ideas? Anybody want to help?
I've thought about making a user interface for DQSD for years. I can't get past two things though: 1) Script-managed values, for example: myvar1 = Array(val1, val2); myvar2 = Array(val3, val4); sNewVar = myvar2; I have code similar to this throughout my prefs file. I use "jsx" and custom aliases to toggle between different assigned variables and collections of variables throughout the day. 2) What's what? The common variables (like address, telephone number - stuff like that) are relatively easy to figure out. Since the UI would necessarily be a compiled application, how does the UI interpret the type or expected value of variables for searches that are either new or aren't common enough to have a static setup within the UI? Several (okay, probably half or more) of the searches I've made use variables to set certain functionality. I've pondered settings for the xml files to help provide a dynamic UI with the information it needs to build the interface elements directly, but we'd have to review and edit all 375+ searches for potential variables in order to add this functionality. We'd also have to document the behavior quite well in order to facilitate search authors with the ability to add variables into the interface. And then, some variables are broader than a single input. The pp search, for example, generally takes a variable of an array with two values. Simple enough. The yy search takes a variable of arrays with as many values as you want, and defaults their values to an existing value if the parameter is not passed. For example, if the array includes an empty string at position three then it would have a different effect than not including the parameter at all. Telling the interface an array has multiple parameters is one thing, and the interface could fill all "x" of them and prompt with text boxes, but it would have to be capable of also providing the ability to "not" recording a value if it met certain requirements. Potential scope for that is huge. And that's just the ones I've come up with in my own searches. I have no clue what other search or plugin authors have done. I can't be the only one to build searches that take very funky parameters and variables. Then there's the less important and easier to control stuff that still needs to be considered: * Multiline values (the floax search variable "floaxButtons" is much easier to maintain if it's multiline) * Comments. 'Nuff said. * Existing "grouping" and order of values and variables (prevent the line being edited from jumping up or down by 30 lines from where the rest of the lines related to the same search are) My preferences file is over 120 lines and is logically grouped by search, type of search, and includes dozens of comments. Quite simply, I'm afraid a UI might erase or move something of value. Regards, Shawn K. Hall http://12PointDesign.com/ ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel
