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 20397 - Use services for editor types
Summary: Use services for editor types
Status: NEW
Alias: None
Product: obsolete
Classification: Unclassified
Component: externaleditor (show other bugs)
Version: -FFJ-
Hardware: PC Linux
: P3 blocker (vote)
Assignee: issues@obsolete
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-09 12:42 UTC by Jesse Glick
Modified: 2006-12-18 23:56 UTC (History)
1 user (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 Jesse Glick 2002-02-09 12:42:18 UTC
Currently the external editor supports XEmacs, VIM, and two
user-defined editor types USR1 and USR2. This style is inconsistent
with other NetBeans configuration UI and does not take advantage of
the Services API.

Proper style is to (1) define an abstract class e.g.
ExternalEditorType extends Object implements Cloneable, Serializable,
with some method(s) to initiate a connection and so on; (2) each EET
subclass (XEmacs + VIM perhaps) contains bean properties such as
command, host/port/password, XEmacs library location, whatever is
appropriate; (3) default instances of available EET subclasses are
placed in Services/ExternalEditorType/ in the layer using .settings
files with appropriate localized names and icons; (4)
UI/Services/.../Editing/ contains a .shadow file pointing to
Services/ExternalEditorType so it appears in the Options dialog;
Templates/Services/ExternalEditorType/ contains templates (.settings
with template=true file attr) for each kind of external editor so that
the user could create more of them, e.g. alternate XEmacs
configurations; (5) the main system option selects the external editor
type according to a property editor of type Object constrained to load
only ExternalEditorType, as described in the Services API "Property
Editor for Services", and saving the selection as a lookup ID.

You might have a generic EET subclass "unknown external process"
applicable to VIM and so on, with an arbitrary number of preconfigured
instances in Services/ but perhaps only one template in
Templates/Services/, which would launch a configurable process but not
provide any further UI to the user; use methodvalue="" in your
.settings to employ static factories to preconfigure several standard
instances of one class. This is as opposed to the XEmacs type which
permits the library location to be configured and so must be a
subclass.

An additional advantage of the services style is that if
ExternalEditorType is public and maintained compatibly, additional
modules could provide support for other editor types if they require
special setup beyond making a connection.
Comment 1 Jaroslav Tulach 2002-02-19 12:06:57 UTC
No need to extend ServiceType. You can just create abstract
ExternalEditorType extends Object and find it using lookup. Rest is
the same as Jesse suggests. And yes, this is the preferred way to
implement plug-in extensibility.
Comment 2 Jan Chalupa 2002-10-27 17:44:09 UTC
[S1S-EVAL]