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.
In current state java module provides some 'not official' way how to extend java editor and work with guarded blocks in java source files. This is used by form module for example. We have to publish this in official supported API. There is a proposal written and published on http://java.netbeans.org/Proposals/GuardedBlocks/GuardedBlocks.html. Use this proposal as a starting point and design API for guarded blocks. This API should be placed to java/editor module.
It seems that the full implementation of the proposed Guarded Blocks API is almost impossible in the current state of guarded blocks. Problem: The smallest guarded unit seems to be the line. It is obvious, because the guarded block is marked in the source file as comment using "//GEN-" marks. The new API assumed, that the element can be divided into smaller subelements such as declaration, definition, signature. To each of this subelement a different value of guarding (DENY_RAW, DENY_USER) should be assigned. It means, that i.e. guarded FieldElement will look for example like this: <guarded level=DENY_RAW>Type</guarded> <guarded level=DENY_USER>name</guarded> = <guarded level=DENY_RAW>value</guarded> It means, that "//GEN-" marks are not sufficient and they should be replaced by other method of storing the guarded information, if we don't want to place each element in new line. One can propose to use /*GEN-*/, but the code would be highly unreadable using this approach. Just imagine, the code for guarded String foo = ""; shown in other editor: /*GEN-BEGIN-RAW:field_declaration_foo*/ String /*GEN-END-RAW:field_declaration_foo*/ /*GEN-BEGIN-USER:field_signature_foo*/ foo /*GEN-END-USER:field_signature_foo*/ = /*GEN-BEGIN-RAW:field_definition_foo*/ ""; /*GEN-END-RAW:field_definition_foo*/ I can implement the API to provide the same functionality of guarding as it is now. I mean Guarded SimpleSection and Guarded InteriorSection for methods. And let the possibility for the future implementation of the API in the full range. If it will be ever possible. Or do you have some better ideas?
It seems that the following idea could solve the problem described above: The main goal of the new API is to change the concept of guarding from the offset to element philosophy. The names of guarded sections are created by guarded section creator in the current guarded block impl. This helps the user to find a proper guarded section by name later. Now, in the new API, the naming is irrelevant. User of the new API can find the appropriate guarded element using this API and java source hierarchy. What about to use the name for guarded information? Example: /*GEN-PB:3A.A.00*/ String foo = ""; /*GEN-PE*/ 1. changing the line comment philosophy to block comment: // -> /* ... */ 2.GEN-PB mark of the start of protected block PB-ProtectionBegin 3. 3A - hexa format of ID number of the protected element. The ID will be generated internally, using the algorhitm of newID = maxID++; 4. A - hexa format of the element's regions info: in details: Element.WHOLE = 0; Element.DOC = 1; Element.HEADER = 2; Element.BODY = 4; Element.FOOTER = 8; in this case: A = Element.HEADER + Element.FOOTER. Classic interior section for the method for example. 5. 01 - indication of the level of ProtectionType. Namely: Element.HEADER = DENY_RAW; ELEMENT.FOOTER = DENY_USER; (just for example) 6. /*GEN-PE*/ - at the end of element should be the mark of the end of protected area. PE - ProtectionEnd This end mark should be usefull in the case when the parser doesn't identify the element correctly. Is it worth to implement such concept, or are there some potentional problems that could occur?
There is a typo in the example. It should be: /*GEN-PB:3A.A.01*/ String foo = ""; /*GEN-PE*/
implemented in [prj40_prototype] Implementation provides the same functionality as the guarded blocks till now. The concept of /* ... */ will be implement later. I am attaching a short demo, that can be used for testing. Demo lists guarded and unguarded elements of the given source file (TestFile.java) and demonstrates a guarding of simple section, interior section and unguarding. Demo should be run via internal execution.
Created attachment 10300 [details] demo
Created attachment 10301 [details] diff
You should place the API to the java/editor module. The java/api module is obsolete and will be probably removed.
IMHO java/editor module is not capable for this. In this case java module will have to depend on java/editor module. I would propose to place this to java/src/org/netbeans/api/java/editor/guarded Is this valid?
Well, I don't think having it in main java module is ideal solution, but I don't have any better at the moment. Since we are going to remove the java/api we have to move the GB-API out of it. Martin, please, do it. Thanks.
Done. In the demo, please change the imports from org.netbeans.api.java.editor to org.netbeans.api.java.editor.guarded
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped. Marking issue as VERIFIED --->
---> CLOSED