Hi Shawn,
> 1) ignore the error and just skip adding the alias to the
> stack if the search does not exist (preferred).
Actually, I think this is what the current version does - it does throw a
qualifiedalert(), but that only shows if the alertmode preference is set to
1, which it isn't per default.
It walks through an interesting path when adding an alias;
<pseudo>
if(!isSearch(aliasTarget))
{
if(isAlias(aliasTarget))
{
// add another alias to the same search
}
else if(isUrl(aliasTarget))
{
// conjure up an URL firing function dynamically
}
else if(startsWithSearch(aliasTarget))
{
// parse out the search prefix, and build a dynamic
function
// that passes the correct params
}
else
{
qualifiedalert('blah');
return;
}
}
</pseudo>
Is your alertmode set to 1?
Kim
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Shawn K. Hall
> Sent: den 9 juni 2004 06:20
> To: [EMAIL PROTECTED]
> Subject: RE: [DQSD-Devel] coresearches dir
>
> Hi Kim,
>
> > > Personally, I think we ought to provide a mechanism for
> searches to
> > > 'announce' their need to provide an autodetect mechanism.
> > > [...]
> >
> > Looks like a good idea. The only counter-argument I can
> think of (and
> > I'm only posing it for the sake of it) is that searches are free to
> > override others.
>
> They already do. The order the searches are loaded (alphabetically, I
> imagine) would determine what order they were parsed, whereas
> now they go in the order specified in the 'detect special
> commands' portion of the def() method.
>
>
> > > I also think the aliasing tool should NOT raise errors if
> the search
> > > is not loadable - the engine is capable of determining if
> the search
> > > really exists, so just test it before adding it to the
> stack. This
> > > would alleviate the 'backwards compatibility' problem.
> >
> > I'm not sure I follow... Sounds like a good idea overall, in that
> > referenced searches that don't exist won't be added to the alias
> > collection, but I don't see how it helps with backward compat?
>
> The first thing I do after installing DQSD on a system is delete (or
> rename) searches that I will never *ever* use (like
> altavista, switchboard, ebay, cnn, ask jeeves and so forth) -
> since editing the aliases.txt file is a little more work than
> just deleting a file I inevitably receive an error the first
> time I reload DQSD after the changes are made since the
> default aliases reference searches that no longer exist.
> They're not "core" searches, nor are they even remotely
> important (in my mind) - but they are referenced in a base
> file that isn't really expected to have user edits
> (aliases.txt) - so the options remain:
> 1) ignore the error and just skip adding the alias to the
> stack if the search does not exist (preferred).
> 2) provide more detailed feedback to the user so they can
> find the reference in aliases.txt and remove it manually.
>
> #1 is far easier to implement, and requires less user interaction.
>
>
> > ...do you want to get your hands dirty, or should I?
>
> I'd love to, but time is still not as free for me as I'd like
> it to be. When I've got a little more time available I'd be
> happy to post the necessary changes.
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
DQSD-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dqsd-devel
