This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The quicksearch feature should search through documentation and help in the IDE. For expected behavior, see the UI spec. in the URL field. Note: Ideally, this would be done in 6.5 time-frame.
M2 is too aggressive I think, changing to 6.5. Stando, please hold this for a short while, I already started to think about provider for searching through google and I would love to prototype it. Then you can do anything with it :)
Maybe it's obvious, but please note that from users' perspective, both searching through web tutorials, wiki as well as through options is fulfilling the same "help me!" use case. So it should be in a single section in quicksearch results.
After discussion with Standa, I decided to change my opinion - it's time to hold back my ego, I had a lot of other work to do so Standa will have this done sooner. I gave Standa my current knowledge and Standa is free to work on this immediately if he wants. re to olangr: disagree strongly, options should be kept separate! Mixing slow, web based provider with fast, local options provider will cause a lot of headache to us and it's really impossible to implement it so that it behaves correctly, believe me. Explanation off line if you are interested (too long, I'm lazy to write it here)
SORRY, I meant "IDE help" instead of "options". But .. as your comment probably still applies (IDE help is probably quite fast to search through while web is not), let's discuss this offline.
Result of the offline discussion: --------------------------------- Ideal state is that results would be interactively filled into the Help & Tutorials & Documentation section as soon as available and sorted on the fly (i.e. each item would be inserted into the appropriate position). Because this would require API change and lots of implementation effort, we may for 6.5 go with waiting until all help results (IDE help, tutorials from the web, ...) are available and displaying them at once, properly sorted by significance.
part one (searching netbeans.org) is finished: 15c24c94a029
To the implementation: 1. Is there a reason to use an HTML request for the search rather than a web service call? 2. This belongs in nb cluster, not platform, at least if it searches nb.org content. Please either move the whole impl out of core.ui into nb cluster; or keep the impl in platform cluster (probably better in spi.quicksearch) with no registration, and register it in some module in nb cluster using e.g. <file name="search-netbeans-org.instance"> <attr name="instanceCreate" methodvalue="org.netbeans.modules.quicksearch.WebProvider.create"/> <attr name="site" stringvalue="netbeans.org"/> </file>
Google don't provide their SOAP api anymore and i didn't find any suitable replacement. i'll find a better place for this module
Great to have the initial version of web search so quickly! Now we should think about limiting the web search to reasonable parts of www.netbeans.org and wiki.netbeans.org. I think the target parts should be http://wiki.netbeans.org/Faq..., http://wiki.netbeans.org/DevFaq..., http://www.netbeans.org/kb/.... John, some other parts of web where we should check for end-user focused Docs?
That's it. There are a lot of user docs on the wiki but unfortunately there's no way to limit search to just those since there's no directory structure or anything in the URL that would tell you. Also platform.netbeans.org/tutorials/.
One thing - I'd like to do some metrics tracking so that we know which hits to the web site are coming from the quick search feature. Is it possible to append ?cid=somenumber to the end of al URLs that are launched from quick search?
javahelp search c44963758ee8
done 3eb1bf994696 a4f5d1ec4775
Reopening, it seems that results from all of netbeans.org are returned, which means there's a lot of "mess".
> Reopening, it seems that results from all of netbeans.org are returned, which means there's a lot of "mess". Did you try today's continuous build? The changesets got into main (from core-main) last night. We had problems with tests on core-main builder for a few last days, thus the delay. I tried it right now and I think it works nicely.
> One thing - I'd like to do some metrics tracking so that we know which hits to the web site are coming from the quick > search feature. Is it possible to append ?cid=somenumber to the end of al URLs that are launched from quick search? it should be possible. what the 'somenumber' should look like?
I tried with build 200807020003 and it didn't work, but I just saw it working at Standa, sorry for the confusion, closing.
all web search results now have "?cid=<autoupdate id>" in their urls (let me know if you want it changed to something else) efea4f6dbbbd
925878 NB IDE Search Feature Most likely this will need to be appended as "&cid=925878" because the search URL will probably already have parameters. If there isn't a "?" in the URL, then append "?cid=925878".
> 925878 NB IDE Search Feature done: 5dc8eb4d6ff6