Re: svn: /web/php/trunk/ include/header.inc js/common.js js/jquery.autocomplete.js js/jquery.autocomplete.pack.js styles/structure.css
styles/theme.css
| From: | Paul Dragoonis | Date: | Wed, 29 Dec 2010 12:18:23 +0000 |
| Subject: | Re: svn: /web/php/trunk/ include/header.inc js/common.js js/jquery.autocomplete.js js/jquery.autocomplete.pack.js styles/structure.css styles/theme.css |
||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.webmaster |
| Request: | Send a blank email to php-webmaster+get-9926@lists.php.net to get a copy of this message | ||
Hi Stewart,
Nice to.see you back on the autocomplete stuff. Regarding.categories if you
do.a.search on Apple.com you will see categorized results. Or used to
anyway. We could do the same here with.the cats mentioned and limit.it to
the top 4 scored results per.cat. if a cat is empty we can.bump up another 4
results.from the cat with the most.results in it.
What do you think ?
On 29 Dec 2010 08:47, "Hannes Magnusson" <hannes.magnusson@gmail.com> wrote:
> On Wed, Dec 29, 2010 at 09:32, Stewart Lord <stewey@ambitious.ca> wrote:
>> On 2010-12-28, at 11:04 PM, Hannes Magnusson wrote:
>>> I do wonder though.. Should we try to categorize/chunk the files so we
>>> can improve the search priority and do as we originally wanted, split
>>> the search results into "categories".
>>> - functions
>>> - methods
>>> - chapters
>>> - references
>>> - appendixes
>>> - ...
>>> That would help, especially for description matches (i.e. searching
>>> for "audio" would give you
>>> http://php.net/manual/en/wrappers.php.php
>>> for example)
>>
>> This does sound pretty neat. Were you thinking of taking a crack at it? I
wonder if it would be best left for a later pass. The scoring logic works
well for matching functions, but it would need more work to match on
descriptions.
>>
>> As an incremental improvement, we could try to add methods to the index
so that searching for 'offset' would match ArrayAccess::offsetExists,
offsetGet, and so on. Assuming the same structure of the index file, if you
set the name of method entries to "ClassName::methodName" then the client
code should just work.
>>
>> Also, the index file that we've been playing with has classes, but they
are all lower case. It would be nice if the generated index file preserved
the correct case.
>>
>
>
> The generated index comes directly from the Docbook sources, so as
> long as the src is correct, the capitalization will be correct.
>
> I did look into supporting variable search, constants, etc etc.
>
> array(
> "refentry" => array(
> array("strpos" => "function.strpos"),
> ),
> "phpdoc:varentry" => array(
> array("$http_response_headers" =>
"reserved.variables.httpresponseheader"),
> ),
> "phpdoc:classref" => array(
> array("DOMDocument" => "class.domdocument")
> ),
> "appendix" => array(
> array("Userland Naming Guide" => "userlandnamgin.global")
> ),
> )
> would be the structure of the searchIndex..
> Or provide multiple index files, one per type. Then we could decide
> not to push examples, or callouts, or whatever types to the user by
> simply commenting it out..
>
> I didn't spend much time on it in javascript land after I figured out
> it actually sorts the entire index everytime :P
> Was more looking at what kind of data we can get for free from PhD
> without needing specific runs.. Looks like we can extract prettymuch
> whateverwe want in under a second while generating the docs.
>
> -Hannes
>
> --
> PHP Webmaster List Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>