[
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