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

Reply via email to