Hi Kim. > > > Good point... It seems only ">" is valid as contents > > > of an attribute. > > > > Even that may be changed in future patches to IE. > > The fact that ">" is interpreted as valid, yes. Which > characters are valid as attribute text, no. > That's dictated by the XML standard, so it's not likely > to ever change.
I don't know - MS has changed global IE handling of other W3C standards and RFC recommendations (the http authentication scheme is a good example). Just because the W3 or the IETF say something is the way it "should" or "must" be done, doesn't mean that functionality will always be available. I was bit by the http auth change and it made me rewrite a lot of code that I should not have had to. There are people on either side of this argument - sure, it's "safer" to remove http auth, but the URL and HTTP specs oth have it as part of the design. To blindly trust that MS would not change XML parsing to break processing of > in attributes is a scary proposition, IMO. > To present a management UI to the user, you still have to > write a layer to edit and query the text file... > The difference is, with MSXML, the majority of that code is > written and working -- with the text file one us has to do > it. The other difference is that a management UI doesn't have to get loaded just to 'turn on' DQSD. It gets loaded on command, when the user want to do editing. A brief delay is expected when loading non-core portions of an application. Adding the necessary XML processing to the base initialization could delay it more. > Compared to a nested array, I think this is cleaner. :/ Okay. Let's take this from another angle. Someone joins the users group and needs help changing settings. If we have a UI it will offset the confusion a bit, but I don't think there are easier ways than telling someone "add this line to localprefs.js: variable=value;" > Of course, your search may have to enumerate an XML doc, > and that may be problematic if you're not accustomed to > MSXML, which is why I think we should provide a wrapping > layer (either a COM object or a script class) that builds > structural elements like an array or collection of data > objects. This could help alleviate some of my concerns, but then it brings up another. Some of the searches I wrote and use often rely on the order of the lines of script. //[yy] : yyid = Array( "username", "password" ); var syg = Array( "user1", "pass1", "http://groups.yahoo.com/mygroups" ); var sra = Array( "user1", "pass1" ); var skh = Array( "user2", "pass2" ); var sk2 = Array( "user3", "pass3" ); var yyid= skh; What this amounts to is building 4 different profiles for the yy (Yahoo Login) search. It defaults to one of them, but can be passed any of the 4 to use an alternate profile. I guess I could rebuild it using something like: <yy> <profile name="syg" id="user1" pw="pass1" url="http://whatever/"> <profile name="sra" id="user1" pw="pass1"> <profile name="skh" id="user2" pw="pass2" default="default"> <profile name="sk2" id="user3" pw="pass3"> </yy> :/ I am still unconvinced. Perhaps a conversion to XML would make more sense if we provided each search the option of building it's own configuration interface. For the above search the config form would provide a simple row-by-row selection form and autoappend an empty bottom row when the next empty row was used. Beside it would appear option buttons to let you select the default config to apply. That would increase the complexity of searches quite a bit, but it'd be even more power-user friendly. Hmmmm... Regards, Shawn K. Hall http://12PointDesign.com/ http://ReliableAnswers.com/ '// ======================================================== "Patience and fortitude conquer all things." -- Ralph Waldo Emerson ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel
