| <?xml version="1.0" encoding="UTF-8"?> |
| <!-- |
| |
| Licensed to the Apache Software Foundation (ASF) under one |
| or more contributor license agreements. See the NOTICE file |
| distributed with this work for additional information |
| regarding copyright ownership. The ASF licenses this file |
| to you under the Apache License, Version 2.0 (the |
| "License"); you may not use this file except in compliance |
| with the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, |
| software distributed under the License is distributed on an |
| "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| KIND, either express or implied. See the License for the |
| specific language governing permissions and limitations |
| under the License. |
| |
| --> |
| <!DOCTYPE api-answers PUBLIC "-//NetBeans//DTD Arch Answers//EN" "../nbbuild/antsrc/org/netbeans/nbbuild/Arch.dtd" [ |
| <!ENTITY api-questions SYSTEM "../nbbuild/antsrc/org/netbeans/nbbuild/Arch-api-questions.xml"> |
| ]> |
| |
| <api-answers |
| question-version="1.29" |
| author="vstejskal@netbeans.org" |
| > |
| |
| &api-questions; |
| |
| |
| <!-- |
| <question id="arch-overall" when="init"> |
| Describe the overall architecture. |
| <hint> |
| What will be API for |
| <a href="http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi"> |
| clients and what support API</a>? |
| What parts will be pluggable? |
| How will plug-ins be registered? Please use <code><api type="export"/></code> |
| to describe your general APIs and specify their |
| <a href="http://openide.netbeans.org/tutorial/api-design.html#category-private"> |
| stability categories</a>. |
| If possible please provide simple diagrams. |
| </hint> |
| </question> |
| --> |
| <answer id="arch-overall"> |
| <p> |
| The Editor Braces Matching module provides the |
| <api name="BracesMatchingSPI" group="java" type="export" category="devel" url="@org-netbeans-modules-editor-bracesmatching@/overview-summary.html"/> |
| for registering services capable of finding matching |
| areas of text in a document. These areas can be pretty much anything and the rules |
| for finding them are solely up to the implementors. A typical usecase and the main |
| motivation for this SPI is to be able to implement language specific matchers |
| for finding pairs of braces, highlighting them and allowing users to move a caret |
| (navigate) from one to the other. The matching areas can also be for example |
| XML, HTML or JSP tags. |
| </p> |
| |
| <p> |
| The Braces Matching SPI is a replacement for the old SPI in |
| <code>org.netbeans.editor.ExtSyntaxSupport</code>. |
| </p> |
| |
| <h3>The infrastructure overview</h3> |
| |
| <p> |
| The following paragraphs give an overview of the infrastructure used for braces |
| matching and explain the essential terminology and ideas behind it. |
| </p> |
| |
| <h4>Original and matching areas</h4> |
| |
| <p> |
| The whole task of finding matching areas can be split in two parts. First we need |
| to determine if the caret is positioned over a character or an area that could |
| possibly have another matching areas. And if so, then we need to find those areas. |
| For the purpose of this SPI we call the area at the caret the <b>original area</b> |
| and the other areas are simply the <b>matching areas</b>. |
| </p> |
| |
| <pre><![CDATA[ |
| for(int i = 0; i < 10; i++) ]]><span style="background-color : #C0FFC0;">{</span><![CDATA[ |
| System.out.println(i); |
| ]]><span style="background-color : #FFC0C0;">}</span><![CDATA[| |
| |
| | - the caret |
| ]]><span style="background-color : #FFC0C0;"> </span><![CDATA[ - original area |
| ]]><span style="background-color : #C0FFC0;"> </span><![CDATA[ - matching area |
| ]]></pre> |
| |
| <p> |
| There is always only one original area, if there is any at all. On the other hand |
| the matchers are free to report as many matching areas as they like. In most |
| cases, however, the matchers will only report none or one matching are as well. |
| </p> |
| |
| <h4>Caret Bias</h4> |
| |
| <p> |
| Normally when typing or moving a caret in the editor one of the characters is |
| always considered to lay 'under' a caret. The decision if it is the character |
| on the left hand side or right hand side of a caret depends on the shape of |
| the caret. Although the visual appearance of a caret can vary, there are generaly |
| only two shapes to consider. The I-beam caret and the block caret. |
| </p> |
| |
| <p> |
| The I-beam caret normally looks like a vertical line placed on a position |
| between characters in text. However, when typing it is generally accepted that |
| the left hand side character is the one under the I-beam caret. The I-beam caret |
| is used in Netbeans editor when editing text in the normal mode. |
| </p> |
| |
| <p> |
| The block caret on the other hand may look like a little square or vertical line |
| placed beneath or under a character. This type of caret makes it visually very clear |
| what character is 'under' the caret. It is the right hand side character. In |
| Netbeans editor the block caret is used for the overwrite mode. |
| </p> |
| |
| <p> |
| When searching for the original area the search has always to start at the |
| character 'under' a caret - the <b>important character</b>. In order not |
| to tie the braces matching infrastructure to a praticular implementation of |
| a caret we use the parameter <b>caret bias</b> to describe on which side of |
| a caret the important character lies. Obviously the caret bias can only have |
| two values - <b>backward</b> or <b>forward</b> - designating positions on the |
| left or right hand side of the caret. |
| </p> |
| |
| <p> |
| Because the search for the original area always starts with the important character |
| the result of this search is directly influenced by the caret bias. |
| The search could result in two different original areas depending on the value |
| of the caret bias, even if the actual position of the caret was not changed. |
| </p> |
| |
| <p> |
| The caret bias is not only used for searching for the original area, but it is also |
| used when navigating (jumping) between matching areas. The navigation is always done |
| in a way to make the matching area where we are navigating to to appear on the |
| same side of the caret as is the side of the caret bias. This makes sure that |
| the matching area will be recognized as the next original area. (Strictly speaking |
| this also depends on the particular matcher implementation that was used for |
| finding the areas.) |
| </p> |
| |
| <h4>Search direction</h4> |
| |
| <p> |
| In general when looking for the original area we not only want to look right |
| next to a caret, but we also want to search <i>a little bit further</i>. Looking |
| a little bit further makes it easier for users to see the matching areas and |
| navigate between them. They don't have to position the caret right at a brace |
| in order to see the matching one or navigate to it. |
| The scope of this search should, however, never leave the line with the caret |
| and in some situations it might be restricted even more. |
| </p> |
| |
| <p> |
| Although there are only two directions to look in - <b>backward</b> or <b>forward</b> - |
| in a real situation looking in both directions gives more practical results. |
| That is why the infrastructure supports the following two search directions. |
| </p> |
| |
| <ul> |
| <li><b>Backward preferred</b> - for searching in the backward direction first |
| and if no original area can be found then searching in the forward direction. |
| </li> |
| <li><b>Forward preferred</b> - for searching in the forward direction first |
| and if no original area can be found then searching in the backward direction. |
| </li> |
| </ul> |
| |
| <h4>Maximum lookahead</h4> |
| |
| <p> |
| The maximum distance, measured in characters from the position of a caret, that |
| the search should be attempted in is called maximum lookahead. The infrastructure |
| uses independent values for both search directions and calls them |
| <b>maximum backward lookahead</b> and <b>maximum forward lookahead</b>. |
| The lookahead |
| is normally limited by the beginning and end of a line with the caret, but |
| can be further limited by those two parameters. The absolute lookahead maximum |
| in each direction enforced by the infrastructure is 256 characters |
| </p> |
| |
| <p> |
| There is an important relationship between maximum lookaheads and the caret bias. The |
| maximum lookaheads can <b>never</b> obscure the important character. In other words |
| the maximum lookahead in the direction of the caret bias will not prevent the infrastructure |
| from searching through the important character (ie. the character right next to the caret). |
| </p> |
| |
| <h4><a name="controlling-parameters">Controlling the parameters</a></h4> |
| |
| <p> |
| There is no API for controlling caret bias, search direction and maximum lookaheads |
| on the global level. It is expected that the module implementing the braces matching |
| infrastructure will expose its own GUI for user to control those parameters. This |
| GUI is yet to be designed. By default the infrastructure will set the parameters |
| to mimic the behavior of the existing (old) implementation of braces matching |
| done using <code>org.netbeans.editor.ExtSyntaxSupport</code>. |
| </p> |
| |
| <p> |
| On the other hand the parameters can be controlled on per-component basis by |
| setting appropriate client properties. This is to allow interested modules |
| such as the jVi plugin to overwrite global settings and implement their own |
| searching policies. The following properties are supported. |
| </p> |
| |
| <ul> |
| <li><code>nbeditor-bracesMatching-caretBias</code> - The caret bias to determine |
| the important character, available |
| values are <code>backward</code> and <code>forward</code>. |
| </li> |
| <li><code>nbeditor-bracesMatching-searchDirection</code> - The direction to |
| search in for the original area. Available values are <code>backward-preferred</code> |
| and <code>forward-preferred</code>. |
| </li> |
| <li><code>nbeditor-bracesMatching-maxBackwardLookahead</code> - The maximum |
| distance to search in when searching backward. The allowed values are <code>0</code> |
| - <code>256</code>. |
| </li> |
| <li><code>nbeditor-bracesMatching-maxForwardLookahead</code> - The maximum |
| distance to search in when searching forward. The allowed values are <code>0</code> |
| - <code>256</code>. |
| </li> |
| </ul> |
| |
| |
| <h3>Key parts of the SPI</h3> |
| |
| <p>Modules implementing the SPI are shielded from most of the complexity of |
| the braces matching infrastructure as it was described earlier. Thier job is |
| as simple as being able to search in one direction through the requested number |
| of characters. The SPI provides all the neccessary information to perform |
| such search as well as mechanisms for registering implemented matchers. |
| </p> |
| |
| <p> |
| The main part of the SPI is the |
| <code><a href="@org-netbeans-modules-editor-bracesmatching@/org/netbeans/spi/editor/bracesmatching/BracesMatcher.html">BracesMatcher</a></code> |
| interface, which |
| needs to be implemented by anybody who wishes to provide a text matching |
| services for a particular type of documents. Implementations of the |
| <code>BracesMatcher</code> interface can be plugged in to the system by |
| registering |
| <code><a href="@org-netbeans-modules-editor-bracesmatching@/org/netbeans/spi/editor/bracesmatching/BracesMatcherFactory.html">BracesMatcherFactory</a></code> |
| in the MIME lookup. |
| </p> |
| |
| <p>The braces matching |
| infrastructure will use registered factories to create matchers for highlighting |
| matching areas in documents. Each type of a document (ie. mime type or more |
| precisely each mime path) can have at most one <code>BracesMatcher</code> registered. |
| If there is more different implementations registered for the same mime path |
| the infrastructure will only use the first one. |
| </p> |
| |
| <p> |
| When asking a <code>BracesMatcherFactory</code> to create an instance of |
| <code>BracesMatcher</code> the infrastructure passes the factory an instance of |
| <code><a href="@org-netbeans-modules-editor-bracesmatching@/org/netbeans/spi/editor/bracesmatching/MatcherContext.html">MatcherContext</a></code>, |
| which provides information about a document |
| and a position in that document, where the search should start. |
| </p> |
| |
| |
| <h3>BracesMatcher registration</h3> |
| |
| <p> |
| The registration of <code>BracesMatcher</code>s has to be done through an |
| instance of the <code>BracesMatcherFactory</code> class. The factory should |
| be registered in <code>MimeLookup</code> under the mime-type of documents, which |
| the <code>BracesMatcher</code> should be used for. For example, if a module |
| wants to provide <code>BracesMatcher</code> for <code>text/x-something</code> documents |
| it should implement its own <code>BracesMatcherFactory</code> (e.g. |
| <code>org.some.module.BMFactory</code> class) and register it in <code>MimeLookup</code> |
| using its XML layer as it is shown on the example below. |
| </p> |
| |
| <pre> |
| <folder name="Editors"> |
| <folder name="text"> |
| <folder name="x-something"> |
| <folder name="BracesMatchers"> |
| <file name="org-some-module-BMFactory.instance" /> |
| </folder> |
| </folder> |
| </folder> |
| </folder> |
| </pre> |
| |
| <p> |
| The <code>BMFactory</code> class will simply return a new instance of |
| the module's implementation of the <code>BracesMatcher</code> interface from its |
| <code>createMatcher</code> |
| method. |
| </p> |
| |
| |
| <h3>Languages embedding</h3> |
| |
| <p> |
| The registration mechanism described earlier and the general concept of MIME lookup |
| allows to provide special <code>BracesMatcher</code>s for embedded languages. |
| The braces matching infrastructure will always try to find the inner-most language at |
| a position in a document, where the search should start. It will then create |
| the <code>BracesMatcher</code> according to the mime path of that inner-most |
| language. |
| </p> |
| |
| <p> |
| As per the general inheritance rules defined by MIME lookup this may result |
| in using a <code>BracesMatcher</code> that is registered for a top level |
| language (ie. mime type) different from the main language of the scanned |
| document. Here is an example of a java snippet in a JSP page, the caret's |
| position is indicated by the '|' pipe character. Assuming that there are only |
| two <code>BracesMatcher</code> implementations registered - one for <code>text/x-jsp</code> |
| and the other one for <code>text/x-java</code>, the infrastructure's attempt to find a matcher |
| for the <code>text/x-jsp/text/x-java</code> mime path is going to result in |
| finding the matcher registered for <code>text/x-java</code>. |
| </p> |
| |
| <pre><![CDATA[ |
| <% for(int i = 0; i < 10; i++) ]]><span style="background-color : pink;">{</span><![CDATA[ %> |
| <th><%=i%>. column</th> |
| <% ]]><span style="background-color : pink;">}</span><![CDATA[| %>; |
| ]]></pre> |
| |
| <p> |
| Since the support for languages embedding comes with the new Lexer API, the |
| above example is naturally only going to work for document types that provide |
| a <code>Lexer</code> implementation. This is the case for the most document types |
| supported in Netbeans 6. In case that a document does not have a <code>Lexer</code> |
| the infrastructure will fall back to using the document's main mime type ignoring |
| any other languages that may potentially be embedded in the document. |
| </p> |
| |
| <h3>Threading</h3> |
| |
| <p> |
| While finding the original brace is relatively simle task, because it's always |
| done in a limited and quite small area around a caret, finding the matching |
| brace can take much more time and in generall it can involve searching through |
| a whole document. The search is normally done in response to a moving caret, |
| which means that there can be a lot of search requests generated |
| when a user moves the caret quickly over some text. It is not very important |
| to show all the results as the caret moves, but it is important to show the |
| last result when the caret stops moving. |
| </p> |
| |
| <p> |
| In order not to impact responsiveness of the editor and its caret the braces matching |
| infrastructure performs all searches in a background thread outside of the Swing's |
| event thread. If needed a running task is cancelled and rescheduled with new |
| parameters reflecting the latest position of the caret. The <code>BracesMatcher</code>s |
| implemented by modules are <b>required</b> to react accordingly when a search task |
| is cancelled. This is described in detail in the javadoc for <code>BracesMatcher</code>. |
| </p> |
| |
| |
| <h3>Constraints and limitations</h3> |
| |
| <p> |
| The current design does not cover searching for areas in right-to-left documents. This |
| usecase has not been even analyzed and may prove itself unsolvable withough major changes |
| in the infrastructure and the SPI. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-quality" when="init"> |
| How will the <a href="http://www.netbeans.org/community/guidelines/q-evangelism.html">quality</a> |
| of your code be tested and |
| how are future regressions going to be prevented? |
| <hint> |
| What kind of testing do |
| you want to use? How much functionality, in which areas, |
| should be covered by the tests? How you find out that your |
| project was successful? |
| </hint> |
| </question> |
| --> |
| <answer id="arch-quality"> |
| <p> |
| There are unit tests covering the basic funtionality of the infrastructure |
| needed for the SPI plugins to work. New tests will be continuously added as |
| the module develops. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-time" when="init"> |
| What are the time estimates of the work? |
| <hint> |
| Please express your estimates of how long the design, implementation, |
| stabilization are likely to last. How many people will be needed to |
| implement this and what is the expected milestone by which the work should be |
| ready? |
| </hint> |
| </question> |
| --> |
| <answer id="arch-time"> |
| <p> |
| The SPI will be part of the standard Netbeans build in Netbeans 6.0 timeframe. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-usecases" when="init"> |
| <hint> |
| Content of this answer will be displayed as part of page at |
| http://www.netbeans.org/download/dev/javadoc/usecases.html |
| You can use tags <usecase name="name> regular html description </usecase> |
| and if you want to use an URL you can prefix if with @TOP@ to begin |
| at the root of your javadoc |
| </hint> |
| |
| Describe the main <a href="http://openide.netbeans.org/tutorial/api-design.html#usecase"> |
| use cases</a> of the new API. Who will use it under |
| what circumstances? What kind of code would typically need to be written |
| to use the module? |
| </question> |
| --> |
| <answer id="arch-usecases"> |
| <p> |
| Although the SPI can generally by used for highlighting areas in a document |
| that have something in common, the usecases below are demonstrated on a simple |
| braces matching example. This example is used for its simplicity and clarity, |
| but it could be substituted by more complex examples. |
| </p> |
| |
| <p> |
| The usecases listed here were heavily inspired by comments in issues |
| <a href="http://www.netbeans.org/issues/show_bug.cgi?id=95126">95126</a> and |
| <a href="http://www.netbeans.org/issues/show_bug.cgi?id=66037">66037</a>. |
| </p> |
| |
| <usecase id="usecase-1" name="Usecase 1. - Highlighting results"> |
| <p> |
| Probably the main reason why this SPI exists is to allow Netbeans editor to |
| highlight matching braces in a document. The highlighting itself is done by the |
| infrastructure and is not of a concern for <code>BracesMatcher</code> implementors. |
| It should be possible to highlight independently |
| (ie. in a different color) both the original brace and the matching brace. It should also |
| be possible to highlight the original brace in a special color when its matching |
| brace can't be found. The colors obviously have to be customizable by users. |
| </p> |
| </usecase> |
| |
| <usecase id="usecase-2" name="Usecase 2. - Navigating between results"> |
| <p> |
| If the original brace is detected and its matching brace is found Netbeans editor |
| needs to allow an easy navigation between those two positions (ie. jumping |
| from the original brace to the matching one and back). |
| </p> |
| |
| <p> |
| In general if there is more than one matching area users should be allowed to cycle |
| through all of them. Since there is only one editor action (shortcut) for navigating |
| between matching areas the cycling is only done in one direction (backward). In |
| order for cycling to work properly the <code>BracesMatcher</code> implementation has to report |
| matching areas in a consistent way. That is the matching areas should always be |
| sorted by their position in a document, starting with the one at the lowest offset. |
| </p> |
| </usecase> |
| |
| <usecase id="usecase-3" name="Usecase 3. - Different search scenarios"> |
| <p> |
| The users are likely to have different preferences for the way how braces matching |
| works therefore its behavior should be customizable. We have listed below several |
| possible scenarios that can be used simply by setting different values for the |
| search parameters described before. They all differ in the way how the original |
| area is detected. |
| </p> |
| |
| <p> |
| The shortcuts for the parameters have the following meaning - <code>MBL</code> |
| ... max backward lookahead, <code>MFL</code> ... max forward lookahead, |
| <code>SD</code> ... search direction, <code>CB</code> ... caret bias. The values |
| are <code>B</code> ... backward or backward preferred and |
| <code>F</code> ... forward or forward preferred. The question mark <code>?</code> |
| means that the value of this parameter has no effect for the search. |
| </p> |
| |
| <ul style="list-style-type : upper-alpha"> |
| <li> |
| <a name="search-scenario-A"><code>MBL = 0, MFL = 0, SD = ?, CB = F</code></a> : Check only the right hand side |
| character of the caret. This is the default for Netbeans overwrite mode (ie. the |
| block shaped caret). |
| </li> |
| <li> |
| <a name="search-scenario-B"><code>MBL = 1, MFL = 1, SD = ?, CB = B</code></a> : Check characters right next to |
| the caret on both its sides. This is the default for Netbeans normal mode (ie. |
| the I-beam shaped caret). |
| </li> |
| <li> |
| <code>MBL = 0, MFL = 256, SD = F, CB = B</code> : Check the character on the |
| left hand side of the caret, otherwise search forward. This is the default |
| for jVi insert mode. |
| </li> |
| <li> |
| <code>MBL = 0, MFL = 256, SD = F, CB = F</code> : Search forward from the caret. |
| This is the default for jVi command mode. |
| </li> |
| <li> |
| <code>MBL = 256, MFL = 256, SD = F, CB = B</code> : Check the left hand side |
| character, otherwise search forward first and then backward. Suitable for |
| I-beam carets that detect the original area anywhere on the line with the |
| caret giving preferrence to the area positioned forward from the caret. The |
| preferrence for the backward positioned area can simply be achieved by changing |
| the search direction (ie. <code>SD = B</code>). |
| </li> |
| <li> |
| <code>MBL = 256, MFL = 256, SD = F, CB = F</code> : The same as |
| option E, but for the block carets. |
| </li> |
| </ul> |
| </usecase> |
| |
| <usecase id="usecase-4" name="Usecase 4. - Auto-switching the search scenario"> |
| <p> |
| The editor in Netbeans can operate in two modes - normal and overwrite. They both |
| use different shape of a caret and thus need a different caret bias. The braces |
| matching infrastructure should detect what mode the editor is in and change the |
| parameters used for searching for the original area accordingly. The caret bias |
| is the most important parameter, but other parameters may need to be changed too. |
| </p> |
| |
| <p> |
| This feature should of course be only active for text components where the parameters |
| have not been overwritten by some other module. |
| </p> |
| |
| <p> |
| By default the two search scenarios used for the normal and overwrite modes in |
| Netbeans editor are the <a href="#search-scenario-B">scenario B</a> for the normal |
| mode and <a href="#search-scenario-A">scenario A</a> for the overwrite mode. In |
| general scenarios from both editor modes should be customizable by users. |
| </p> |
| </usecase> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-what" when="init"> |
| What is this project good for? |
| <hint> |
| Please provide here a few lines describing the project, |
| what problem it should solve, provide links to documentation, |
| specifications, etc. |
| </hint> |
| </question> |
| --> |
| <answer id="arch-what"> |
| <p> |
| The Braces Matching SPI allows modules providing editor support for documents |
| to create their own <code>BracesMatcher</code>s that are tailored for the type of documents they |
| support. The module itself provides an infrastructure for |
| highlighting matching areas identified by a matcher and navigating between them. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-where" when="impl"> |
| Where one can find sources for your module? |
| <hint> |
| Please provide link to the CVS web client at |
| http://www.netbeans.org/download/source_browse.html |
| or just use tag defaultanswer generate='here' |
| </hint> |
| </question> |
| --> |
| <answer id="arch-where"> |
| <defaultanswer generate='here' /> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="compat-deprecation" when="init"> |
| How the introduction of your project influences functionality |
| provided by previous version of the product? |
| <hint> |
| If you are planning to deprecate/remove/change any existing APIs, |
| list them here accompanied with the reason explaining why you |
| are doing so. |
| </hint> |
| </question> |
| --> |
| <answer id="compat-deprecation"> |
| <p> |
| The Braces Matching SPI is a replacement for <code>ExtSyntaxSupport.findMatchingBlocks</code> |
| SPI. The module provides a legacy matcher that will use <code>ExtSyntaxSupport</code> |
| in case that a new matcher is not available for a given document type. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="compat-i18n" when="impl"> |
| Is your module correctly internationalized? |
| <hint> |
| Correct internationalization means that it obeys instructions |
| at <a href="http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/i18n-branding.html"> |
| NetBeans I18N pages</a>. |
| </hint> |
| </question> |
| --> |
| <answer id="compat-i18n"> |
| <p> |
| Yes. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="compat-standards" when="init"> |
| Does the module implement or define any standards? Is the |
| implementation exact or does it deviate somehow? |
| </question> |
| --> |
| <answer id="compat-standards"> |
| <p> |
| No standards implemented. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="compat-version" when="impl"> |
| Can your module coexist with earlier and future |
| versions of itself? Can you correctly read all old settings? Will future |
| versions be able to read your current settings? Can you read |
| or politely ignore settings stored by a future version? |
| |
| <hint> |
| Very helpful for reading settings is to store version number |
| there, so future versions can decide whether how to read/convert |
| the settings and older versions can ignore the new ones. |
| </hint> |
| </question> |
| --> |
| <answer id="compat-version"> |
| <p> |
| Yes. At the moment there are no previous versions of this module. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-jre" when="final"> |
| Which version of JRE do you need (1.2, 1.3, 1.4, etc.)? |
| <hint> |
| It is expected that if your module runs on 1.x that it will run |
| on 1.x+1 if no, state that please. Also describe here cases where |
| you run different code on different versions of JRE and why. |
| </hint> |
| </question> |
| --> |
| <answer id="dep-jre"> |
| <p> |
| Any JRE suitable for Netbeans platform itself. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-jrejdk" when="final"> |
| Do you require the JDK or is the JRE enough? |
| </question> |
| --> |
| <answer id="dep-jrejdk"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-nb" when="init"> |
| What other NetBeans projects and modules does this one depend on? |
| <hint> |
| Depending on other NetBeans projects influnces the ability of |
| users of your work to customize their own branded version of |
| NetBeans by enabling and disabling some modules. Too |
| much dependencies restrict this kind of customization. If that |
| is your case, then you may want to split your functionality into |
| pieces of autoload, eager and regular modules which can be |
| enabled independently. Usually the answer to this question |
| is generated from your <code>project.xml</code> file, but |
| if it is not guessed correctly, you can suppress it by |
| specifying <defaultanswer generate="none"/> and |
| write here your own. Please describe such projects as imported APIs using |
| the <code><api name="identification" type="import or export" category="stable" url="where is the description" /></code>. |
| By doing this information gets listed in the summary page of your |
| javadoc. |
| </hint> |
| </question> |
| --> |
| <answer id="dep-nb"> |
| <defaultanswer generate='none' /> |
| <ul> |
| <li><api type='import' group='java' category='private' name='org.jdesktop.layout' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 1.4 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='deprecated' name='org.netbeans.modules.editor.lib' url='@org-netbeans-modules-editor-lib@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 1.14 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='devel' name='org.netbeans.modules.editor.lib2' url='@org-netbeans-modules-editor-lib2@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 1.3 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='official' name='org.netbeans.modules.editor.mimelookup' url='@org-netbeans-modules-editor-mimelookup@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 1.6 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='private' name='org.netbeans.modules.editor.settings' url='@org-netbeans-modules-editor-settings@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 1.9 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='private' name='org.netbeans.modules.editor.util' url='@org-netbeans-modules-editor-util@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 1.17 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='official' name='org.netbeans.modules.lexer' url='@org-netbeans-modules-lexer@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 1.18 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='official' name='org.openide.dialogs' url='@org-openide-dialogs@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 7.4 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='official' name='org.openide.modules' url='@org-openide-modules@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 7.2 |
| is required. |
| </api> |
| </li> |
| <li><api type='import' group='java' category='official' name='org.openide.util' url='@org-openide-util@/overview-summary.html' > |
| The module is needed for compilation. |
| |
| The module is used during runtime. |
| |
| Specification version |
| 7.9 |
| is required. |
| </api> |
| </li> |
| </ul> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-non-nb" when="init"> |
| What other projects outside NetBeans does this one depend on? |
| |
| <hint> |
| Depending on 3rd party libraries is always problematic, |
| especially if they are not open source, as that complicates |
| the licensing scheme of NetBeans. Please enumerate your |
| external dependencies here, so it is correctly understood since |
| the begining what are the legal implications of your project. |
| Also please note that |
| some non-NetBeans projects are packaged as NetBeans modules |
| (see <a href="http://libs.netbeans.org/">libraries</a>) and |
| it is preferred to use this approach when more modules may |
| depend and share such third-party libraries. |
| </hint> |
| </question> |
| --> |
| <answer id="dep-non-nb"> |
| <p> |
| None. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-platform" when="init"> |
| On which platforms does your module run? Does it run in the same |
| way on each? |
| <hint> |
| If you plan any dependency on OS or any usage of native code, |
| please describe why you are doing so and describe how you envision |
| to enforce the portability of your code. |
| Please note that there is a support for <a href="http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-os-specific">OS conditionally |
| enabled modules</a> which together with autoload/eager modules |
| can allow you to enable to provide the best OS aware support |
| on certain OSes while providing compatibility bridge on the not |
| supported ones. |
| Also please list the supported |
| OSes/HW platforms and mentioned the lovest version of JDK required |
| for your project to run on. Also state whether JRE is enough or |
| you really need JDK. |
| </hint> |
| </question> |
| --> |
| <answer id="dep-platform"> |
| <p> |
| No platform dependencies. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-dependencies" when="final"> |
| What do other modules need to do to declare a dependency on this one, |
| in addition to or instead of the normal module dependency declaration |
| (e.g. tokens to require)? |
| <hint> |
| Provide a sample of the actual lines you would add to a module manifest |
| to declare a dependency, for example OpenIDE-Module-Requires: some.token. |
| If other modules should not depend on this module, or should just use a |
| simple regular module dependency, you can just answer "nothing". If you |
| intentionally expose a semistable API to clients using implementation |
| dependencies, you should mention that here (but there is no need to give |
| an example of usage). |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-dependencies"> |
| <p> |
| Just normal module dependency. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-jar" when="impl"> |
| Do you deploy just module JAR file(s) or other files as well? |
| <hint> |
| Usually a module consist of one JAR file (perhaps with Class-Path |
| extensions) and also a configuration file that enables it. If you |
| have any other files, use |
| <api group="java.io.File" name="yourname" type="export" category="friend">...</api> |
| to define the location, name and stability of your files (of course |
| changing "yourname" and "friend" to suit your needs). |
| |
| If it uses more than one JAR, describe where they are located, how |
| they refer to each other. |
| If it consist of module JAR(s) and other files, please describe |
| what is their purpose, why other files are necessary. Please |
| make sure that installation/uninstallation leaves the system |
| in state as it was before installation. |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-jar"> |
| <p> |
| No additional files. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-nbm" when="impl"> |
| Can you deploy an NBM via the Update Center? |
| <hint> |
| If not why? |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-nbm"> |
| <p> |
| Yes. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-packages" when="init"> |
| Are packages of your module made inaccessible by not declaring them |
| public? |
| |
| <hint> |
| By default NetBeans build harness treats all packages are private. |
| If you export some of them - either as public or friend packages, |
| you should have a reason. If the reason is described elsewhere |
| in this document, you can ignore this question. |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-packages"> |
| <p> |
| Yes. Only the <code>org.netbeans.spi.editor.bracesmatching</code> package is public. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-shared" when="final"> |
| Do you need to be installed in the shared location only, or in the user directory only, |
| or can your module be installed anywhere? |
| <hint> |
| Installation location shall not matter, if it does explain why. |
| Consider also whether <code>InstalledFileLocator</code> can help. |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-shared"> |
| <p> |
| Anywhere. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-ant-tasks" when="impl"> |
| Do you define or register any ant tasks that other can use? |
| |
| <hint> |
| If you provide an ant task that users can use, you need to be very |
| careful about its syntax and behaviour, as it most likely forms an |
| API for end users and as there is a lot of end users, their reaction |
| when such API gets broken can be pretty strong. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-ant-tasks"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-classloader" when="impl"> |
| Does your code create its own class loader(s)? |
| <hint> |
| A bit unusual. Please explain why and what for. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-classloader"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-component" when="impl"> |
| Is execution of your code influenced by any (string) property |
| of any of your components? |
| |
| <hint> |
| Often <code>JComponent.getClientProperty</code>, <code>Action.getValue</code> |
| or <code>PropertyDescriptor.getValue</code>, etc. are used to influence |
| a behavior of some code. This of course forms an interface that should |
| be documented. Also if one depends on some interface that an object |
| implements (<code>component instanceof Runnable</code>) that forms an |
| API as well. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-component"> |
| <p> |
| Yes. The infrastructure recognizes the following properties that can be set |
| on a <code>JTextComponent</code>. The properties influence the way how a matcher |
| is used for finding the original area (ie. the area where the matching starts, |
| for example the first brace). |
| </p> |
| <ul> |
| <li> |
| <api name="nbeditor-bracesMatching-caretBias" group="property" category="devel" type="export" > |
| Controls where the important character lies in relation to a caret. The important |
| character is a character right next to a caret and depending on the value of |
| this property it can be the character on either the left hand side or the right hand side |
| of the caret. Please see the infrastructure |
| <a href="#controlling-parameters">overview</a> |
| for more details. |
| </api></li> |
| <li> |
| <api name="nbeditor-bracesMatching-searchDirection" group="property" category="devel" type="export" > |
| Controls a direction |
| in which the search for the original area is performed. Please see the infrastructure |
| <a href="#controlling-parameters">overview</a> |
| for more details. |
| </api></li> |
| <li> |
| <api name="nbeditor-bracesMatching-maxBackwardLookahead" group="property" category="devel" type="export"> |
| Controls the maximum distance |
| measured in characters from the position of a caret, where matchers are allowed |
| to search for the original area. Please see the infrastructure |
| <a href="#controlling-parameters">overview</a> |
| for more details. |
| </api></li> |
| <li> |
| <api name="nbeditor-bracesMatching-maxForwardLookahead" group="property" category="devel" type="export"> |
| Controls the maximum distance |
| measured in characters from the position of a caret, where matchers are allowed |
| to search for the original area. Please see the |
| <a href="#controlling-parameters">overveiw</a> |
| for more details. |
| </api></li> |
| </ul> |
| |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-introspection" when="impl"> |
| Does your module use any kind of runtime type information (<code>instanceof</code>, |
| work with <code>java.lang.Class</code>, etc.)? |
| <hint> |
| Check for cases when you have an object of type A and you also |
| expect it to (possibly) be of type B and do some special action. That |
| should be documented. The same applies on operations in meta-level |
| (Class.isInstance(...), Class.isAssignableFrom(...), etc.). |
| </hint> |
| </question> |
| --> |
| <answer id="exec-introspection"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-privateaccess" when="final"> |
| Are you aware of any other parts of the system calling some of |
| your methods by reflection? |
| <hint> |
| If so, describe the "contract" as an API. Likely private or friend one, but |
| still API and consider rewrite of it. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-privateaccess"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-process" when="impl"> |
| Do you execute an external process from your module? How do you ensure |
| that the result is the same on different platforms? Do you parse output? |
| Do you depend on result code? |
| <hint> |
| If you feed an input, parse the output please declare that as an API. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-process"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-property" when="impl"> |
| Is execution of your code influenced by any environment or |
| Java system (<code>System.getProperty</code>) property? |
| On a similar note, is there something interesting that you |
| pass to <code>java.util.logging.Logger</code>? Or do you observe |
| what others log? |
| <hint> |
| If there is a property that can change the behavior of your |
| code, somebody will likely use it. You should describe what it does |
| and the <a href="http://openide.netbeans.org/tutorial/api-design.html#life">stability category</a> |
| of this API. You may use |
| <pre> |
| <api type="export" group="property" name="id" category="private" url="http://..."> |
| description of the property, where it is used, what it influence, etc. |
| </api> |
| </pre> |
| </hint> |
| </question> |
| --> |
| <answer id="exec-property"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-reflection" when="impl"> |
| Does your code use Java Reflection to execute other code? |
| <hint> |
| This usually indicates a missing or insufficient API in the other |
| part of the system. If the other side is not aware of your dependency |
| this contract can be easily broken. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-reflection"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-threading" when="init"> |
| What threading models, if any, does your module adhere to? How the |
| project behaves with respect to threading? |
| <hint> |
| Is your API threadsafe? Can it be accessed from any threads or |
| just from some dedicated ones? Any special relation to AWT and |
| its Event Dispatch thread? Also |
| if your module calls foreign APIs which have a specific threading model, |
| indicate how you comply with the requirements for multithreaded access |
| (synchronization, mutexes, etc.) applicable to those APIs. |
| If your module defines any APIs, or has complex internal structures |
| that might be used from multiple threads, declare how you protect |
| data against concurrent access, race conditions, deadlocks, etc., |
| and whether such rules are enforced by runtime warnings, errors, assertions, etc. |
| Examples: a class might be non-thread-safe (like Java Collections); might |
| be fully thread-safe (internal locking); might require access through a mutex |
| (and may or may not automatically acquire that mutex on behalf of a client method); |
| might be able to run only in the event queue; etc. |
| Also describe when any events are fired: synchronously, asynchronously, etc. |
| Ideas: <a href="http://core.netbeans.org/proposals/threading/index.html#recommendations">Threading Recommendations</a> (in progress) |
| </hint> |
| </question> |
| --> |
| <answer id="exec-threading"> |
| <p> |
| The infrastructure uses a dedicated <code>RequestProcessor</code> for running |
| tasks that search for the original and matching areas. The search is initiated |
| by moving a caret in a text component, which usually happens in Swing's event |
| thread. In order not to block this thread the infrastructure posts the task to |
| the <code>RequestProcessor</code>. Any previously running task is cancelled, |
| because its results are not needed anymore. When a task finishes it highlights |
| its results (if there are any) in the text component using the Highlighting SPI. |
| Please read more in the <code>org.netbeans.spi.editor.bracesmatching</code> |
| package's javadoc. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="format-clipboard" when="impl"> |
| Which data flavors (if any) does your code read from or insert to |
| the clipboard (by access to clipboard on means calling methods on <code>java.awt.datatransfer.Transferable</code>? |
| |
| <hint> |
| Often Node's deal with clipboard by usage of <code>Node.clipboardCopy, Node.clipboardCut and Node.pasteTypes</code>. |
| Check your code for overriding these methods. |
| </hint> |
| </question> |
| --> |
| <answer id="format-clipboard"> |
| <p> |
| None. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="format-dnd" when="impl"> |
| Which protocols (if any) does your code understand during Drag & Drop? |
| <hint> |
| Often Node's deal with clipboard by usage of <code>Node.drag, Node.getDropType</code>. |
| Check your code for overriding these methods. Btw. if they are not overridden, they |
| by default delegate to <code>Node.clipboardCopy, Node.clipboardCut and Node.pasteTypes</code>. |
| </hint> |
| </question> |
| --> |
| <answer id="format-dnd"> |
| <p> |
| None. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="format-types" when="impl"> |
| Which protocols and file formats (if any) does your module read or write on disk, |
| or transmit or receive over the network? Do you generate an ant build script? |
| Can it be edited and modified? |
| |
| <hint> |
| <p> |
| Files can be read and written by other programs, modules and users. If they influence |
| your behaviour, make sure you either document the format or claim that it is a private |
| api (using the <api> tag). |
| </p> |
| |
| <p> |
| If you generate an ant build file, this is very likely going to be seen by end users and |
| they will be attempted to edit it. You should be ready for that and provide here a link |
| to documentation that you have for such purposes and also describe how you are going to |
| understand such files during next release, when you (very likely) slightly change the |
| format. |
| </p> |
| </hint> |
| </question> |
| --> |
| <answer id="format-types"> |
| <p> |
| None. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="lookup-lookup" when="init"> |
| Does your module use <code>org.openide.util.Lookup</code> |
| or any similar technology to find any components to communicate with? Which ones? |
| |
| <hint> |
| NetBeans is build around a generic registry of services called |
| lookup. It is preferable to use it for registration and discovery |
| if possible. See |
| <a href="http://www.netbeans.org/download/dev/javadoc/org-openide-util/org/openide/util/lookup/doc-files/index.html"> |
| The Solution to Comunication Between Components |
| </a>. If you do not plan to use lookup and insist usage |
| of other solution, then please describe why it is not working for |
| you. |
| <br/> |
| When filling the final version of your arch document, please |
| describe the interfaces you are searching for, where |
| are defined, whether you are searching for just one or more of them, |
| if the order is important, etc. Also classify the stability of such |
| API contract. Use <api group=&lookup& /> tag, so |
| your information gets listed in the summary page of your javadoc. |
| </hint> |
| </question> |
| --> |
| <answer id="lookup-lookup"> |
| <p> |
| Yes. The module uses <code>MimeLookup</code> to find instances of <code>BracesMatcherFactory</code> |
| registered for particular mime types. The instances are then used for creating |
| <code>BracesMatcher</code>s, which are used for finding the matching areas of |
| a document. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="lookup-register" when="final"> |
| Do you register anything into lookup for other code to find? |
| <hint> |
| Do you register using layer file or using <code>META-INF/services</code>? |
| Who is supposed to find your component? |
| </hint> |
| </question> |
| --> |
| <answer id="lookup-register"> |
| <p> |
| Yes. An implementation of <code>HighlightsLayerFactory</code> is registered in |
| the root of <code>MimeLookup</code> to plug in a special highlighting layer |
| that will show seach results. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="lookup-remove" when="final"> |
| Do you remove entries of other modules from lookup? |
| <hint> |
| Why? Of course, that is possible, but it can be dangerous. Is the module |
| your are masking resource from aware of what you are doing? |
| </hint> |
| </question> |
| --> |
| <answer id="lookup-remove"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-exit" when="final"> |
| Does your module run any code on exit? |
| </question> |
| --> |
| <answer id="perf-exit"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-huge_dialogs" when="final"> |
| Does your module contain any dialogs or wizards with a large number of |
| GUI controls such as combo boxes, lists, trees, or text areas? |
| </question> |
| --> |
| <answer id="perf-huge_dialogs"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-limit" when="init"> |
| Are there any hard-coded or practical limits in the number or size of |
| elements your code can handle? |
| <hint> |
| Most of algorithms have increasing memory and speed complexity |
| with respect to size of data they operate on. What is the critical |
| part of your project that can be seen as a bottleneck with |
| respect to speed or required memory? What are the practical |
| sizes of data you tested your project with? What is your estimate |
| of potential size of data that would cause visible performance |
| problems? Is there some kind of check to detect such situation |
| and prevent "hard" crashes - for example the CloneableEditorSupport |
| checks for size of a file to be opened in editor |
| and if it is larger than 1Mb it shows a dialog giving the |
| user the right to decide - e.g. to cancel or commit suicide. |
| </hint> |
| </question> |
| --> |
| <answer id="perf-limit"> |
| <p> |
| No limits on the numbers of registered <code>BracesMatcherFactory</code>s. The |
| performance of Netbeans editor can be affected by poorly designed implementations |
| of <code>BracesMatcher</code>. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-mem" when="final"> |
| How much memory does your component consume? Estimate |
| with a relation to the number of windows, etc. |
| </question> |
| --> |
| <answer id="perf-mem"> |
| <p> |
| Roughly 100 bytes per an edited document. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-menus" when="final"> |
| Does your module use dynamically updated context menus, or |
| context-sensitive actions with complicated and slow enablement logic? |
| <hint> |
| If you do a lot of tricks when adding actions to regular or context menus, you can significantly |
| slow down display of the menu, even when the user is not using your action. Pay attention to |
| actions you add to the main menu bar, and to context menus of foreign nodes or components. If |
| the action is conditionally enabled, or changes its display dynamically, you need to check the |
| impact on performance. In some cases it may be more appropriate to make a simple action that is |
| always enabled but does more detailed checks in a dialog if it is actually run. |
| </hint> |
| </question> |
| --> |
| <answer id="perf-menus"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-progress" when="final"> |
| Does your module execute any long-running tasks? |
| |
| <hint>Long running tasks should never block |
| AWT thread as it badly hurts the UI |
| <a href="http://performance.netbeans.org/responsiveness/issues.html"> |
| responsiveness</a>. |
| Tasks like connecting over |
| network, computing huge amount of data, compilation |
| be done asynchronously (for example |
| using <code>RequestProcessor</code>), definitively it should |
| not block AWT thread. |
| </hint> |
| </question> |
| --> |
| <answer id="perf-progress"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-scale" when="init"> |
| Which external criteria influence the performance of your |
| program (size of file in editor, number of files in menu, |
| in source directory, etc.) and how well your code scales? |
| <hint> |
| Please include some estimates, there are other more detailed |
| questions to answer in later phases of implementation. |
| </hint> |
| </question> |
| --> |
| <answer id="perf-scale"> |
| <p> |
| No scaling problems in the infrastructure itself. The performance of registered |
| <code>BracesMatcher</code>s is likely to be affected by the size of a document |
| they search in. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-spi" when="init"> |
| How the performance of the plugged in code will be enforced? |
| <hint> |
| If you allow foreign code to be plugged into your own module, how |
| do you enforce that it will behave correctly and quickly and will not |
| negatively influence the performance of your own module? |
| </hint> |
| </question> |
| --> |
| <answer id="perf-spi"> |
| <p> |
| Long running old searches for matching areas are cancelled by new requests. No |
| other enforcement is in place. A poorly written plugin <code>BraceMatcher</code> |
| can negatively influence the overall performance of Netbeans editor. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-startup" when="final"> |
| Does your module run any code on startup? |
| </question> |
| --> |
| <answer id="perf-startup"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-wakeup" when="final"> |
| Does any piece of your code wake up periodically and do something |
| even when the system is otherwise idle (no user interaction)? |
| </question> |
| --> |
| <answer id="perf-wakeup"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-file" when="final"> |
| Does your module use <code>java.io.File</code> directly? |
| |
| <hint> |
| NetBeans provide a logical wrapper over plain files called |
| <code>org.openide.filesystems.FileObject</code> that |
| provides uniform access to such resources and is the preferred |
| way that should be used. But of course there can be situations when |
| this is not suitable. |
| </hint> |
| </question> |
| --> |
| <answer id="resources-file"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-layer" when="final"> |
| Does your module provide own layer? Does it create any files or |
| folders in it? What it is trying to communicate by that and with which |
| components? |
| |
| <hint> |
| NetBeans allows automatic and declarative installation of resources |
| by module layers. Module register files into appropriate places |
| and other components use that information to perform their task |
| (build menu, toolbar, window layout, list of templates, set of |
| options, etc.). |
| </hint> |
| </question> |
| --> |
| <answer id="resources-layer"> |
| <p> |
| Yes. The module layer contains <code>MimeLookup</code> registrations neccessary |
| for plugging in its highlighting layer. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-mask" when="final"> |
| Does your module mask/hide/override any resources provided by other modules in |
| their layers? |
| |
| <hint> |
| If you mask a file provided by another module, you probably depend |
| on that and do not want the other module to (for example) change |
| the file's name. That module shall thus make that file available as an API |
| of some stability category. |
| </hint> |
| </question> |
| --> |
| <answer id="resources-mask"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-preferences" when="final"> |
| Does your module uses preferences via Preferences API? Does your module use NbPreferences or |
| or regular JDK Preferences ? Does it read, write or both ? |
| Does it share preferences with other modules ? If so, then why ? |
| <hint> |
| You may use |
| <api type="export" group="preferences" |
| name="preference node name" category="private"> |
| description of individual keys, where it is used, what it |
| influences, whether the module reads/write it, etc. |
| </api> |
| Due to XML ID restrictions, rather than /org/netbeans/modules/foo give the "name" as org.netbeans.modules.foo. |
| Note that if you use NbPreferences this name will then be the same as the code name base of the module. |
| </hint> |
| </question> |
| --> |
| <answer id="resources-preferences"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-read" when="final"> |
| Does your module read any resources from layers? For what purpose? |
| |
| <hint> |
| As this is some kind of intermodule dependency, it is a kind of API. |
| Please describe it and classify according to |
| <a href="http://openide.netbeans.org/tutorial/api-design.html#categories"> |
| common stability categories</a>. |
| </hint> |
| </question> |
| --> |
| <answer id="resources-read"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="security-grant" when="final"> |
| Does your code grant additional rights to some other code? |
| <hint>Avoid using a class loader that adds extra |
| permissions to loaded code unless really necessary. |
| Also note that your API implementation |
| can also expose unneeded permissions to enemy code by |
| calling AccessController.doPrivileged().</hint> |
| </question> |
| --> |
| <answer id="security-grant"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="security-policy" when="final"> |
| Does your functionality require modifications to the standard policy file? |
| <hint>Your code might pass control to third-party code not |
| coming from trusted domains. This could be code downloaded over the |
| network or code coming from libraries that are not bundled |
| with NetBeans. Which permissions need to be granted to which domains?</hint> |
| </question> |
| --> |
| <answer id="security-policy"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| </api-answers> |