DonationCoder.com Software > FARR Plugins and Aliases

FARR Plugin Idea Holy Grail - DQSD (400 searches)

<< < (4/5) > >>

mouser:
im sorry czb, but hobby or not, you are a coder.  and you should be proud of what you've created.  of course there is always more to learn, that's true for every programmer.

as far as being confused by the the xml search files... there is nothing really to it once you understand the idea -- the xml file is just a couple of sections.  some sections are just html code which describes the plugin -- that text would just be given to FARR function to display it when appropriate.  And then the main section is just pure javascript -- there is nothing to be done with that except to "run" it.  so the dq meta plugin really doesnt have to do anything clever here, just "execute" or eval() the javascript block when appropriate.

like i said it may be that ecaradec would want to write this dq meta plugin by writing it in c++ and executing the javascript the way he does it with his javascript sdk already.  BUT i think you've really done more complicated plugins than this already, or at least very close.

i think the important thing to realize is that the dq metaplugin doesnt have to care very much at all what is in these xml files, there is very little in there that it has to be concerned with.  it just has to read the xml files in to learn which search words are available, and then send certain blocks in the xml (there are xml helper functions built into JS) to the FARR memo mode (or html mode), and execute certain blocks using JS eval() command.

joes_garage:
Mouser, where do you think the main difficulty here? it seems to me that there's really not much JS coding to be done!  It's mainly traversing the script directory, parsing an xml file, displaying a bit of info, and launching the actual chunk of code contained in the xml file.  Am I missing something here?

mouser:
I don't think there's all that much more to it, but i've simplified the description of all the steps, and i do think the nature of what's happening with dynamically running snippets of javascript is unusual enough that it could be a little tricky.

There are two additional things i glossed over:

* There are a few javascript functions that the blocks of search code call to interface with the main program -- these have to be discovered and implemented.  these are mainly functions to actually load the desired url, but there are some other helper functions.
* Some of the search xmls define an html form, and invoke it -- i'm not sure exactly how that works -- i think it's probably something very close to how some of the existing FARR javascript plugins present a form.
In summary -- there are enough little tricky and unusual pieces that i suspect it will require some effort to get it working.  Definitely a challenge, but not an insurmountable one.

ewemoa:
Question 3.2 of the DQSD FAQ seems to have some detailed information regarding forms and how they fit in with creating your own searches.  A portion of 3.2 follows:


* Take a look at the original HTML form for the search, and create your own HTML form to do the same thing, but where you make all the input fields hidden instead of visible (i.e., change the type to "hidden"). Be sure to be explicit about the "action" of the form (it has to be an absolute URL).
* Write a JavaScript function that takes one text parameter and assigns values the hidden fields of your form, and then submits it. By convention, if the text parameter is blank, you should open a window into a useful page that helps you launch the search -- typically the home page of the search. If there are multiple fields in the form, then your JavaScript should use a regular expression of some kind to pull apart the single text field to fill in the multiple form fields. The easiest way to do this is with the 'parseArgs' function, which will handle the parsing for optional 'switches' and their values.
* Paste your new HTML form and your new JavaScript function into its own XML file (SEARCHNAME).xml - copy the bits of xml from an existing search xml file - and include the attribute indicating your JavaScript function name, a short name for the search, a long description, a link to a description of the search engine, your name, and so on. Be sure to follow XML rules - all your attributes need to be quoted, remember the trailing slash in the INPUT tag, etc...
At the end of 3.2, concerning the xml file there is the following:


* Your search will be callable using the function="..." name. E.g., if function="foo" then you can do the search saying "foo bar". So pick a good short name for your JavaScript function.
* Every search's NAME attribute will be displayed if the search is put on the menu, so keep it short and descriptive, like a menu item.
* If you include a LINK attribute, then the link will appear in the ? help box for the search.
* The DESCRIPTION attribute is also included in the ? help box.
* The CATEGORY attribute defines the name of the category in which the search appears in the ? help box.
* The CONTRIBUTOR attribute is for your name, and the EMAIL attribute is for your email address.
A casual browsing of some of the searches have turned up the following regarding pieces of the xml file:


* name
* category
* contributor
* link
* email
* description
* form
* script
* copyright
* created_by
"copyright" and "created_by" don't appear to serve technical purposes and the rest of the bits seem like they are described at least a bit.

Regarding the dqsd-specific javascript functions, I started making a list of candidates.  I'm not confident about these yet, but FWIW, here's what I've got so far (this was done by manual inspection of various searches):


* nullArgs
* parseArgs
* submitForm
* setSearchWindowText
* openSearchWindow

mouser:
ewe, i've also looked again at dqsd since i believe that the work that ecaradec and you have been doing on FSubScript has made dqsd implementation infinitely more likely.

my reading is that in fact the ability to use dqsd searches is likely to be implemented in the near future and will not be that hard to do.

the last part of your post is the most helpful -- those dqsd-specific functions.. that's great that you've started making a list of those -- i didn't find any documentation yet which describes them so this is really useful.  :up: :up:

Navigation

[0] Message Index

[#] Next page

[*] Previous page