Hey Brent, > 1) the script type is more of a pain than currently > because you'll have to remember to escape all the > javascript correctly in the xml
Can we use CDATA junks to avoid having to escape script? > 2) Re: xml format > > I think I'd prefer > > <option description="Local events file" type="string" > name="localeventsfileurl">localevents.xml</option> > > instead of > > <option display_name="Local events file" type="string" > var_name="localeventsfileurl" > value="localevents.xml"></option> Actually that was close to what I had in the initial version (http://dqsd.cvs.sourceforge.net/*checkout*/dqsd/dqsd/preferences.xml?revision=1.1), but after I added some <possible_value /> elements like so [1], it seemed a bit unweildy [2]. Plus I think it might introduce some problems dealing with unintentional carriage returns. Not sure though, it does seem weird to use the element text for <possible_value /> but not for <option />. And, 'description' > 'display_name', agreed, but how about 'caption' so that we can use 'description' for more verbose text describing what the option is/does. I can see the description being displayed in a tooltip or detail pane, but the caption being used for, uhm, well the caption. I'd also change 'var_name' to 'var'. [1] <option display_name="Reuse browser window mode" type="int" var_name="reuseBrowserWindowMode" value="0"> <possible_values> <value display="New window always [default]">0</value> <value display="Single window for all">1</value> <value display="Single window for each search type">2</value> </possible_values> </option> [2] <option display_name="Reuse browser window mode" type="int" var_name="reuseBrowserWindowMode">0 <possible_values> <value display="New window always [default]">0</value> <value display="Single window for all">1</value> <value display="Single window for each search type">2</value> </possible_values> </option> -------- Original Message -------- > From: Brent Beardsley <[EMAIL PROTECTED]> > Sent: Tuesday, July 25, 2006 10:32 AM > To: [EMAIL PROTECTED], DQSD development discussions > <[email protected]> > Subject: Re: [DQSD-Devel] configuration ideas xml format > > I like it - here's a couple of thoughts... > > 1) the script type is more of a pain than currently > because you'll have to remember to escape all the > javascript correctly in the xml > > 2) Re: xml format > > I think I'd prefer > > <option description="Local events file" type="string" > name="localeventsfileurl">localevents.xml</option> > > instead of > > <option display_name="Local events file" type="string" > var_name="localeventsfileurl" > value="localevents.xml"></option> > > Brent > --- Glenn Carr <[EMAIL PROTECTED]> wrote: > > > Kim and I had a chat yesterday about the DQSD > > configuration and ended up coming up with some > > ideas. They may or may not fly, but I thought I'd > > throw them out there for feedback... > > > > - Deprecate the script files that currently define > > the configuration options (preferences.js and > > localprefs.js) in favor of more structured storage > > (e.g., preferences.xml [or .config] and > > localprefs.xml [ or .config] ) which have an XML > > format. We would continue to honor settings in a > > users the localprefs.js if present. > > > > - The config file format defines 4 types of option > > variables/values -- string, bool, int, and script. > > The ability to embed literal jscript as a value > > would solve the problem of search configuration > > options that don't translate easily to > > bool/int/string var types. > > > > - The result of 'consuming' these new config files > > would result in the same global variables being set, > > so no changes to any other handling of options would > > be required. > > > > - preferences.xml would define general DQSD, > > search-independent options. > > > > - Each search would define its config options in an > > optional blob of additional XML added to its current > > XML. > > > > - localprefs.xml would contain a conglomeration of > > both overridden values from preferences.xml and > > search configuration values. > > > > - A UI would expose the merged content of > > preferences.xml, all searches configuration options, > > and localprefs.xml, with localprefs.xml overriding > > values in preferences.xml and the search .xml > > options. > > > > - A prototype of a config file format: > > http://tinyurl.com/hk5du > > > > - A listview similar to the listview shown by > > Firefox with about:config could be used to display > > and change the options. We could also provide > > categorization and filtering at some point depending > > on how fancy we want to get. (Has anyone > > implemented an ATL/WTL listview that handles > > embedded comboboxes/editboxes/etc.? Where's Will > > Dean these days?) > > > > That's it I think. I may have missed something, but > > thoughts and feedback are more than welcome. > > > > Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel
