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.

Bug 220915 - Help window - does not contain detailed description of core functions
Summary: Help window - does not contain detailed description of core functions
Status: REOPENED
Alias: None
Product: javascript
Classification: Unclassified
Component: Documentation (show other bugs)
Version: 7.3
Hardware: PC Linux
: P3 normal with 2 votes (vote)
Assignee: Petr Pisl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-26 12:02 UTC by Vladimir Riha
Modified: 2015-10-12 10:56 UTC (History)
6 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Riha 2012-10-26 12:02:01 UTC
Some time ago, help window for e.g. decodeURI contained more detailed textual description. For instance (based on my tests), for Math.abs there was this string in help window (I saved only a small part of the entire help text):

"absolute value of a number"


Now there is nothing but parameters and what it returns ("Type String"). Is this supposed to? Is it possible to get "rich" help window back again?


Product Version: NetBeans IDE Dev (Build 201210260001)
Java: 1.7.0_10-ea; Java HotSpot(TM) Client VM 23.6-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_10-ea-b11
System: Linux version 3.2.0-31-generic-pae running on i386; UTF-8; en_US (nb)
Comment 1 Martin Fousek 2012-10-26 12:14:17 UTC
Yeah Vlado, I'm afraid that it's by intention. It's not possible to use documentation we parsed for now so the "javadoc" stays quite empty. I think that would be great if we could place the documentation at least to Plugin Portal as a update module, but it's probably still not possible, right Petr, John?

Sorry, but I must close it as wontfix for now. :/
Comment 2 Vladimir Riha 2012-10-26 12:29:49 UTC
Thanks for quick response. I didn't know about it.
Comment 3 Petr Jiricka 2012-10-26 19:14:41 UTC
Would it at least be possible to display a link to the documentation on the web in the doc window? E.g. there is the icon that displays documentation in external web browser - it's disabled right now. It could be enabled and link to the real documentation at its source. And the doc window could contain some hint text such as "Click [this icon] to view documentation for this function."
Comment 4 Martin Fousek 2012-10-31 09:17:30 UTC
(In reply to comment #3)
> Would it at least be possible to display a link to the documentation on the web
> in the doc window? E.g. there is the icon that displays documentation in
> external web browser - it's disabled right now. It could be enabled and link to
> the real documentation at its source. And the doc window could contain some
> hint text such as "Click [this icon] to view documentation for this function."

It should be possible, just it will take some time, since no such information exists in the downloaded resources (probably will require manual update) and there has to be binded link to every item of the JS signature files. I raised new enhancement for doing that:
http://netbeans.org/bugzilla/show_bug.cgi?id=221152
Comment 5 Petr Jiricka 2012-12-11 16:01:41 UTC
Hopefully we will be able to put the JS documentation to Update Center, so I am reopening this as an enhancement request.
Comment 6 Petr Jiricka 2013-06-28 13:48:10 UTC
One way to implement this could be to download the documentation from the network on the fly, and then cache it in the IDE's caches directory. As Martin will probably not have time for this in 7.4, assigning to Petr P.
Comment 7 Martin Fousek 2013-08-05 06:04:11 UTC
(In reply to comment #6)
> One way to implement this could be to download the documentation from the
> network on the fly, and then cache it in the IDE's caches directory.

I don't think that this is even possible. The base documentation is pretty big and split into many sources. Few points why this looks impossible to me (ordered by severity):

1, Size and amount of files. It's 25MB to 80MB of mostly ~30kB files. We are speaking at least about 700+ files to be downloaded (or it can growth to thousands of files. Except IDE performance issues due to very big download time it would generate really big traffic, especially of the MDN site.

2, There are tens various type of the documentation pages. Most of them are parsed by scripts (if more similar doc pages exist), several of them were collected manually to save time to write parser for every small page. I'm afraid about the license here to place it these texts into standard distro.

3, Every doc page change could break the documentation of the whole object or objects and we wouldn't able to fix that without patching.

4, When I wrote the parser there was no plan to do such things as a part of the IDE tasks. The code would require probably some optimisation, permission to use jsoup library for the parsing.
Comment 8 Petr Jiricka 2013-08-05 12:08:57 UTC
Thanks for the evaluation Martin. Looks complicated. I must say I am not too concerned about item 1, assuming we would download/cache the files on a just-in-time basis, and not pre-download them all at the beginning. This usage pattern would then be no different to how users can access the documentation from the web browser today.

Items 2 and 3 are more serious OTOH. But if we don't insist on parsing and understanding all the pages, and just make do with some 80% of the pages, would this simplify the problem to an acceptable level? Thanks.
Comment 9 Martin Fousek 2013-08-05 13:01:12 UTC
(In reply to comment #8)
> Items 2 and 3 are more serious OTOH. But if we don't insist on parsing and
> understanding all the pages, and just make do with some 80% of the pages, would
> this simplify the problem to an acceptable level? Thanks.

I think that we are not able to prevent issue Nr.3 we can at most presume that it will not happen.

The base and the most important looks to me be core JS documentation got from MDN so let's speak only about these docs. If we risk Nr.3, we must have mapping to the methods/fields (issue #221152), then it's theoretically doable with pretty big effort. Also keep in mind that pruning of current generator must be done or rather the code base must be split into two (code duplication, harder maintainability).
Comment 10 aupanner 2015-10-10 11:05:52 UTC
Still an issue in 8.1RC