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.
It seems, there are various form editor implementations for different project and source types. Please, use one form editor implementation for all. Re-using it in different editors, this will (hopefully) result in a stable api, which could then be used for other implementations, too (e.g. custom project types). Along with this, I'd be glad, if there would also be a possibility to reduce some abilities on a project-base (as not all abilities make sense in every configurations, e.g. it wouldn't help to use swing forms for an app server, which is customized using pojos, while an additional j2ee server wouldn't make sense, either). While the second issue might be a different enhancement request, I'm combining these issues here, as in my case both are needed for the same thing, and I'm only going to describe the second as far as it is related to the form editor. As far as I've seen, the form editor is the "real" editor, at least for java files. It just doesn't show the form window, if there isn't any form, so I don't even have a chance to replace the editor. Further, it seems, the form editor checks for palette item paths, and, as the utilities class uses static methods, behaviour cannot be changed. And, because the form editor seems to make use of a great bunch of good but complicated algorithms, it doesn't seem, I should replace everything. So, in my case, to make the form editor reusable for me, it even would be sufficient to hide the "standard" items and to define an api how palette items (containers, layouts and components) need to be designed to be usable for the editor. The hiding must be project-type related, so sth. like <folder="project-types"><folder="myProjectType"><folder="FormEditor">....</..> would be necessary.
I just want to add/clarify some ideas: 1. The hiding issue is, of course, not only related to the editor, project-specific hiding should be possible. 2. The editor should have a multi-pane facility, it shouldn't be built be every form editor 3. The editor should accept files on a set-base, not based only on the primary file, e.g. there should be a possibility to distinguish the set of ("java","form") from ("java","myform"). Further, there should be the possibility to filter for generated source code, comments, signatures etc., e.g. a file type for OOo-UNO should be able to plug-in into the "acceptance chain" before the standard java editor. If a java file is to be edited, it could the ask the file loader, if the java file is of the specialized type. 4. *After* accepting the file type, the multi-pane should be built using sth. like multi.add(new editor(multi, fileobject)) with each editor adding its label (e.g. "form" or "design") and its actions (to create buttons from them; separators could just be given as null). Also a NOI18N-name is needed (see 5). 5. The different editors need to interact which each other, so sth. like multi.getConcurrentEditor(name) is needed. 6. The editors should communicate on the base of properties (Using generated code regions directly would specialize this to work for code only, but not for xml files. However, the regions need to have a defined name, of course, best if the same for the whole NB project). 7. Of course, in the case of form editors, the palette should be independent from the form editor (and vice versa). So, there should be only few editors: one GUI editor for all forms, CASA, ... Of course, if this all is already implemented and I just couldn't find the docs for that, I'd be VERY HAPPY if You could point me there, but I've already asked at the mailing lists (without any answer, so don't really know, if the docs and/or the implementation are missing)!