Re: [xml-dev] Re: XML Entity Catalogue

Petr Kuzel wrote:
>>1. Inconsistency with usage of e.g. Mount/ folder, and almost everything
>>else in NetBeans that consists of a set of services that can be added by
>>modules and/or users.
> 
> It's faster to use private namespace.

Not sure what you mean.

>>2. User-added catalogs are serialized to
> 
> Services/Hidden/org-netbeans-modules-xml-catalog-settings-CatalogSettings.settings
> 
>>in unreadable form when they could be added as individual service files
>>to e.g. Services/XMLCatalogs/.
> 
> The implementation is about 2+ years old. Now I'd not use that approach.
> I'd delegate persistence responsibility to catalog providers.

Right - my point was just that the current situation mixes the layer 
folder and the system option, which is strange.

>>3. Nonstandard UI (Runtime tab rather than Options, Unmount rather than
>>Delete, no Change Order action, etc.) is encouraged by the nonstandard
>>design.
> 
> Such naming was requested. It cannot be under global options because
> user mounted catalogs are project sensitive.

Lots of stuff in Options is project-sensitive. That is why there is the 
magic "<<<" column that shows you which things are project-sensitive and 
lets you change that status on the fly.

>>4. No ability to make a catalog project-specific or revert a catalog
>>change from default settings.
> 
> User catalogs are project specifics.

Sorry, missed this fact. Of course that is not an argument for using a 
system option - it is just not an argument for not using one. (SFS 
folders can be marked as being project-specific for new files: Mount/ is 
an example.)

>>5. Storage of user-added catalogs will need to be changed to work with
>>the Registry API or whatever in 4.0, so the work has just been deferred.
> 
> I'd delegate the persistence responsibility to catalog providers :-).

Sure. Hopefully the new infrastructure API (e.g. Registry) will make it 
convenient to

1. Provide a place where catalogs can be registered.

2. Make them automatically persist changes.

3. Create some kind of UI to see and modify the mounts, at least good 
enough for prototyping if not for production.

4. Permit some things to be project-specific and others to be global, 
and the two merged together.

5. See modifications to module-provided catalogs and revert them.

All these things are supported using the current Services API. Hopefully 
they will be even easier using the Registry API and new Projects.

-Jesse

-- 
Jesse Glick <mailto:[email protected]> x22801
NetBeans, Open APIs  <http://www.netbeans.org/>