Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Bug 22905 ([EditorMgmt] associations: Allow pattern matching) and API deprecation

Alexandros Karypidis <akarypid@xxxxxxxx> wrote on 2013-11-27 23:09:12:

> 1) Redefine the "extension" concept to be everything after the FIRST dot

That's a no-go, since that would be a breaking change for existing files 
like "4.4 Plan.txt" and for everybody using e.g. 
IResource#getFileExtension().

> 2) When looking up mappings for some filename, sequentially relax the 
> extension until a mapping is found  (e.g. file.x.y.z will look for 
> mappings for *.x.y.z, *.y.z and *.z -- in that order -- and stop at the 
> first matching mapping as the most specific mapping should "win").

Sounds like the way to go. I.e. never try to extract a "suffix" from a 
given file name, since the correct suffix can be ambiguous. Only use a 
suffix _pattern_ to map from file name to content type.

> This semantic change would in fact mean the API is backwards compatible: 

> currently there are only simple rules in the wild (*.somextension), so 
> changing the existing API implementation along these lines would mean 
> things will keep working (but people will be able to now add more 
> specific rules going forward).

It is not completely backwards compatible for clients that use e.g. 
IContentType#getFileSpecs(int) or IFileEditorMapping#getExtension() and 
assume the extension doesn't contain a dot, but I think that will cause 
less problems than introducing a new "suffix" concept to which every 
client has to adapt.

Markus



Back to the top