Associate file-extension to 2 diff content-types based on file name patterns [message #517568] |
Mon, 01 March 2010 11:17  |
Eclipse User |
|
|
|
Hello folks,
I have a situation with respect to content-type assocation with file extensions.
I have 2 files whose file-name postfix strings are standardized (let's call them ab.xyz and cd.xyz - note the same extension)
*ab.xyz is associated with MyContentType1
*cd.xyz is assocaited with MyContentType2
Now, in my application's preferences - I am able to view *ab.xyz and *cd.xyz under 2 separate categories (which is fine and the way it should be), however when I try to retrieve content-type id for a file named "sample_ab.xyz" "MyContentType2" is returned instead of MyContentType1.Code to get content-type description is delegated to IFile api.
Your thoughts please.
Thanks!
|
|
|
Re: Associate file-extension to 2 diff content-types based on file name patterns [message #517572 is a reply to message #517568] |
Mon, 01 March 2010 11:22   |
Eclipse User |
|
|
|
Chetan,
It doesn't work that way. You'll need to deal with all files with
extension xyz and determine if it's an ab or a cd based purely on the
contents.
Chetan Kumar wrote:
> Hello folks,
>
> I have a situation with respect to content-type assocation with file
> extensions.
> I have 2 files whose file-name postfix strings are standardized (let's
> call them ab.xyz and cd.xyz - note the same extension)
> *ab.xyz is associated with MyContentType1
> *cd.xyz is assocaited with MyContentType2
>
> Now, in my application's preferences - I am able to view *ab.xyz and
> *cd.xyz under 2 separate categories (which is fine and the way it
> should be), however when I try to retrieve content-type id for a file
> named "sample_ab.xyz" "MyContentType2" is returned instead of
> MyContentType1.Code to get content-type description is delegated to
> IFile api.
>
> Your thoughts please.
> Thanks!
>
|
|
|
|
Re: Associate file-extension to 2 diff content-types based on file name patterns [message #517585 is a reply to message #517580] |
Mon, 01 March 2010 11:59   |
Eclipse User |
|
|
|
Chetan,
As far as I recall, those refer to the full name of the file, e.g.,
plugin.xml or build.properties. There's no pattern matching supported,
as far as I know. Note that pattern matching would require testing all
patterns, rather than a hashed index. It would also require
prioritizing which pattern to match first, so it would be expensive and
tricky to support.
Chetan Kumar wrote:
> Thanks for the response Ed.
>
> But then what does the "file-names" attribute refer to in the
> contentTypes extension point ? Can we give a reg-ex here to signify
> file-names pattern ?
>
> <file-association
> content-type="<!-- some contentType Id -->"
> file-extensions="xyz"
> file-names="*_cd.xyz">
> </file-association>
>
>
> + Chetan Kumar
|
|
|
Re: Associate file-extension to 2 diff content-types based on file name patterns [message #517587 is a reply to message #517585] |
Mon, 01 March 2010 12:34   |
Eclipse User |
|
|
|
Hello Ed,
Then mere file-association with a content-type based on file-names will not solve my problem.
Ultimately, with this set-up i want to load these 2 files (with same extn but different file-name postfix) into 2 different EMF models. The actual ContentType contributions associated with my 2 files is a black-box for me. So, will contributing to EMF content_handler extension-point solve the problem ?
as in, with my ContentHandler implementation - i can override the method to return based on file-name postfix strings.
+ Chetan Kumar
|
|
|
Re: Associate file-extension to 2 diff content-types based on file name patterns [message #517603 is a reply to message #517587] |
Mon, 01 March 2010 14:07  |
Eclipse User |
|
|
|
Chetan,
Comments below.
Chetan Kumar wrote:
> Hello Ed,
>
> Then mere file-association with a content-type based on file-names
> will not solve my problem.
Nope.
>
> Ultimately, with this set-up i want to load these 2 files (with same
> extn but different file-name postfix) into 2 different EMF models.
It seems likely then that the namespace of the root element or the name
of the root element should be sufficient to define the content type
without resorting to this notion of the postfix itself making the
distinction...
> The actual ContentType contributions associated with my 2 files is a
> black-box for me.
I'm not sure I understand that comment. Why?
> So, will contributing to EMF content_handler extension-point solve the
> problem ?
Yes, it will solve the problem from and EMF point of view, but the
platform itself uses content types to determine things like editor
associations and for that, the more flexible EMF solution won't help.
> as in, with my ContentHandler implementation - i can override the
> getFactory(URI) method to return based on file-name postfix strings.
>
> + Chetan Kumar
|
|
|
Powered by
FUDForum. Page generated in 0.03182 seconds