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

Jesse Glick wrote:

> 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.

Private FolderLookup performs better than Lookup.getDefault().
Irrelevant in this case (but it indirectly improves performace
of clients that put their performace critics registrations in
the default lookup).

> Right - my point was just that the current situation mixes the layer
> folder and the system option, which is strange.
> 
> 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.

But in case of XML catalogs user cannot change it, module
provided catalogs are global, user's catalogs are project
specifics. It'd be nicer to allow user to customize settings
storage (prj vs. layer) but it was not requirement (in fact
requirement was that user must not be able to customize it).
I choose the simplest and backward compatible implementation
I was aware of.
 
> 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.)

Current implementation bets on fact that only one project is
active. Folder marking has the same problem. Both solutions
are from my point point view equally 'dirty'.
 
>>>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.

There is rather big problem: merging ordered items. User cannot
order global and project items to each other.
 
> 5. See modifications to module-provided catalogs and revert them.

Some module-provided catalogs should be unmodifiable. Module
should decide if it provides fixed catalog of a default catalog
(content).
 
> All these things are supported using the current Services API. Hopefully
> they will be even easier using the Registry API and new Projects.

I hope that I'll be able to leverage them easily achieveing user's
settings backward compatibility.

  Cc.