lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV searching in lists


From: Foteos Macrides
Subject: Re: LYNX-DEV searching in lists
Date: Tue, 19 Nov 1996 09:00:07 -0500 (EST)

Wayne Buttles <address@hidden> wrote:
>>[...]
>>      Anyway, Lynx does search "lists", so probably what you are really
>> asking is how hard it would be search form field values, such as in a
>> SELECT with 609 OPTIONs.
>> 
>>      Very, very hard. :) :)
>>      
>
>Would it?  When you are in a select list the input is parsed within the
>pop-up code, right?  So it would be a matter of allowing / and then just
>strcmp'ing through opt_ptr->name's to find the pointer to emulate a select
>on.
>
>Of course tons of select options is pretty abusive to the user and
>the browser, especially in light of the discussion we have had on
>accessability.  It would be a better idea to complain that the page was
>user unfriendly (no matter what browser you use!).
>
>Searching other form elements (like button text) as a part of a page
>search seems much harder to me.

        The WHEREIS searches are from the orginal (v1) Lynx, before
forms existed, and are two phased.  First it searches the link names
of standard hypertext anchors, by looping through the structure which
holds them.  If there is no hit, it then searches the plain text strings
in the HText structure.  It does not do any searches of form fields,
which are in yet another structure, except that the HText structure
has underscore strings as "placeholders" for the form fields, so if you
search for a "string of underscores" you could get unintended hits for
form fields, which will be filled into the ultimate page display with
their values from the form structures, so you'll wonder why it acted
like you got a hit when in fact there is no string of underscores there.

        If anyone does add code for searching form fields, you'll now
have either a three phase search, or you'll need a major redesign of
the logic so that it behaves as if it where one linear search, and
you'll need to decide what Lynx should actually do when it gets hits
for the actual values (rather than underscore "placeholders") of
form fields.  Also, searching the OPTION values after a SELECT popup
has been created is functionally different from a global document
search.

        The most important thing to grasp here, again, is that Lynx
is an HTML browser, not a file viewer.  There may be some who can't
grasp that distinction, and, for example, will perpetually make
inappropriate comparisions between apples in a file viewer like
most versus organges in Lynx, but those who actually work on the
code should keep clear in there minds that WHEREIS searches already
are a hodge-podge of link name versus surrounding text searches that
don't handle forms, and that trying to extend that as a navigation
aid within SELECT popups may end up just compounding the hacks and
taking Lynx yet another step down a dead-end road, rather than
redesigning it more rationally for a long-term future.

        Yet my two cents. :) :) :)

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]