I'm a bit confused. Dimitry indicated that I should register a file type through extensions, but the doc below indicates that I should use an application component.
The first step in developing a custom language plugin is registering a file type the language will be associated with. IDEA determines the type of a file by looking at its extension. Thus, a custom language can only be associated with specific file extensions -- it is not currently possible to create a language which will be applied to files with specific content, like, for example, a specific XML root namespace.
A custom language file type is a class derived from LanguageFileType, which passes a Language implementation class to its base class constructor. The file type is typically registered in the initComponent() method of an application component (class implementing the ApplicationComponent interface). The registration of the file type is performed by a call to FileTypeManager.getInstance().registerFileType().
Example: Registering LanguageFileType for JavaScript
To verify that the file type is indeed registered correctly, you can implement the LanguageFileType.getIcon() method and verify that the correct icon is displayed for files which have the extension associated with your file type.
Sascha Weinreuter wrote:
Hello Peter,
>> Why does IntelliJ complain that fileTypeFactory is not allowed in the extentions?
I'm a bit confused. Dimitry indicated that I should register a file type through extensions, but the doc below indicates that I should use an application component.
So registering file types changed in version 8.0? And the samples and documentation have not be updated yet?
Now I am unconfused.
Can you give me a pointer to any version 8 sample custom file type code, complicated or not? JavaScript, Groovy etc. would all be much appreciated.
Dmitry Jemerov wrote:
Hello Peter,
>> I'm a bit confused. Dimitry indicated that I should register a file >> type through extensions, but the doc below indicates that I should use >> an application component. >> >> Neither one seems to work for me. >> >> http://www.jetbrains.com/idea/plugins/developing_custom_language_plugi >> ns.html
Thank you again Dmitry. This is good-- the code and documentation now agree.
However, when I try the plugin.xml from Groovy, I'm still having "Element fileTypeFactory not allowed here" (and other errors). Do I need to be using a different IDEA SDK? Perhaps the SDK is also out of sync with version 8.
Dmitry Jemerov wrote:
Hello Peter,
>> Can you give me a pointer to any version 8 sample custom file type >> code, complicated or not? JavaScript, Groovy etc. would all be much >> appreciated.
On Fri, 28 Nov 2008 18:04:21 -0500, Peter Wolf wrote:
Thank you again Dmitry. This is good-- the code and documentation now agree.
However, when I try the plugin.xml from Groovy, I'm still having "Element fileTypeFactory not allowed here" (and other errors). Do I need to be using a different IDEA SDK? Perhaps the SDK is also out of sync with version 8.
"Element fileTypeFactory is not allowed here" and similar errors are expected and not a cause for concern. If you look at the plug-in DTD you'll see that it doesn't say anything about the content of the ]]> element (there's a comment about it being a "relaxed constraint"). This allows plug-ins to define arbitrary extension points of their own that a more constraining DTD would explicitly prevent. For example, I might write a plug-in that supports the "com.codebrewer.foo" extension point, and other plug-ins could then express a dependency on my plug-in and register an implementation of "foo" in the "com.codebrewer" namespace that my plug-in would be able to retrieve. The downside is that 'core' extension points (such as those for registering custom languages) are unknown to a strict validation against the DTD. It just means that IDEA and plug-ins must document externally the extension points they support.
(Note that most of the above was inferred from writing 1) a trivial plug- in that provides extension points; 2) a trivial custom language plug-in, the "colorSettingsPage", "fileTypeFactory" and "syntaxHighlighter" extensions of which show up as errors in plugin.xml but work correctly.)
Thank you Mark, that is exactly what I needed to know.
I think I am good now :)
Mark Scott wrote:
On Fri, 28 Nov 2008 18:04:21 -0500, Peter Wolf wrote:
>> Thank you again Dmitry. This is good-- the code and documentation now >> agree. >> >> However, when I try the plugin.xml from Groovy, I'm still having >> "Element fileTypeFactory not allowed here" (and other errors). Do I >> need to be using a different IDEA SDK? Perhaps the SDK is also out of >> sync with version 8.
"Element fileTypeFactory is not allowed here" and similar errors are expected and not a cause for concern. If you look at the plug-in DTD you'll see that it doesn't say anything about the content of the <extensions> element (there's a comment about it being a "relaxed constraint"). This allows plug-ins to define arbitrary extension points of their own that a more constraining DTD would explicitly prevent. For example, I might write a plug-in that supports the "com.codebrewer.foo" extension point, and other plug-ins could then express a dependency on my plug-in and register an implementation of "foo" in the "com.codebrewer" namespace that my plug-in would be able to retrieve. The downside is that 'core' extension points (such as those for registering custom languages) are unknown to a strict validation against the DTD. It just means that IDEA and plug-ins must document externally the extension points they support.
(Note that most of the above was inferred from writing 1) a trivial plug- in that provides extension points; 2) a trivial custom language plug-in, the "colorSettingsPage", "fileTypeFactory" and "syntaxHighlighter" extensions of which show up as errors in plugin.xml but work correctly.)
This link doesnt go anywhere anymore (like a lot of others).
The documentation for the SDK is inadequate at best. No JavaDocs for the PluginSDK out of the box, no obvious place to get it, no simple code samples - just the usual response of "go check out the Javascript or Groovy plugin".
Is Jetbrains really expecting a significant up-tick in plugin development now that things are open source?
This link doesnt go anywhere anymore (like a lot of others).
The documentation for the SDK is inadequate at best. No JavaDocs for the PluginSDK out of the box, no obvious place to get it
Since you can get far more useful information from the source code than from the JavaDocs that we had, there's no longer much sense in publishing the JavaDocs. Just go and grab the source.
-- Dmitry Jemerov Development Lead JetBrains, Inc. http://www.jetbrains.com/ "Develop with Pleasure!"
Hello Peter,
please see/vote for
http://www.jetbrains.net/jira/browse/IDEA-19849
http://www.jetbrains.net/jira/browse/IDEA-19850
Sascha
Thanks Sascha,
I'm a bit confused. Dimitry indicated that I should register a file
type through extensions, but the doc below indicates that I should use
an application component.
Neither one seems to work for me.
http://www.jetbrains.com/idea/plugins/developing_custom_language_plugins.html
Registering a File Type
The first step in developing a custom language plugin is registering a
file type the language will be associated with. IDEA determines the type
of a file by looking at its extension. Thus, a custom language can only
be associated with specific file extensions -- it is not currently
possible to create a language which will be applied to files with
specific content, like, for example, a specific XML root namespace.
A custom language file type is a class derived from LanguageFileType,
which passes a Language implementation class to its base class
constructor. The file type is typically registered in the
initComponent() method of an application component (class implementing
the ApplicationComponent interface). The registration of the file type
is performed by a call to FileTypeManager.getInstance().registerFileType().
Example: Registering LanguageFileType for JavaScript
To verify that the file type is indeed registered correctly, you can
implement the LanguageFileType.getIcon() method and verify that the
correct icon is displayed for files which have the extension associated
with your file type.
Sascha Weinreuter wrote:
>> Why does IntelliJ complain that fileTypeFactory is not allowed in the extentions?
Hello Peter,
This document wasn't updated for IDEA 8.0. An up-to-date version of this
document can be found at:
http://www.jetbrains.net/confluence/display/IDEADEV/DevelopingCustomLanguagePluginsforIntelliJIDEA
--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
Ah ha! Much better.
So registering file types changed in version 8.0? And the samples and
documentation have not be updated yet?
Now I am unconfused.
Can you give me a pointer to any version 8 sample custom file type code,
complicated or not? JavaScript, Groovy etc. would all be much appreciated.
Dmitry Jemerov wrote:
>> I'm a bit confused. Dimitry indicated that I should register a file
>> type through extensions, but the doc below indicates that I should use
>> an application component.
>>
>> Neither one seems to work for me.
>>
>> http://www.jetbrains.com/idea/plugins/developing_custom_language_plugi
>> ns.html
Hello Peter,
The code for the Groovy plugin can be found at http://svn.jetbrains.org/idea/Trunk/bundled/groovy/
--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
Thank you again Dmitry. This is good-- the code and documentation now
agree.
However, when I try the plugin.xml from Groovy, I'm still having
"Element fileTypeFactory not allowed here" (and other errors). Do I
need to be using a different IDEA SDK? Perhaps the SDK is also out of
sync with version 8.
Dmitry Jemerov wrote:
>> Can you give me a pointer to any version 8 sample custom file type
>> code, complicated or not? JavaScript, Groovy etc. would all be much
>> appreciated.
On Fri, 28 Nov 2008 18:04:21 -0500, Peter Wolf wrote:
"Element fileTypeFactory is not allowed here" and similar errors are
expected and not a cause for concern. If you look at the plug-in DTD
you'll see that it doesn't say anything about the content of the
]]> element (there's a comment about it being a "relaxed
constraint"). This allows plug-ins to define arbitrary extension points
of their own that a more constraining DTD would explicitly prevent. For
example, I might write a plug-in that supports the "com.codebrewer.foo"
extension point, and other plug-ins could then express a dependency on my
plug-in and register an implementation of "foo" in the "com.codebrewer"
namespace that my plug-in would be able to retrieve. The downside is
that 'core' extension points (such as those for registering custom
languages) are unknown to a strict validation against the DTD. It just
means that IDEA and plug-ins must document externally the extension
points they support.
(Note that most of the above was inferred from writing 1) a trivial plug-
in that provides extension points; 2) a trivial custom language plug-in,
the "colorSettingsPage", "fileTypeFactory" and "syntaxHighlighter"
extensions of which show up as errors in plugin.xml but work correctly.)
--
Mark Scott
mark@codebrewer.com
Thank you Mark, that is exactly what I needed to know.
I think I am good now :)
Mark Scott wrote:
>> Thank you again Dmitry. This is good-- the code and documentation now
>> agree.
>>
>> However, when I try the plugin.xml from Groovy, I'm still having
>> "Element fileTypeFactory not allowed here" (and other errors). Do I
>> need to be using a different IDEA SDK? Perhaps the SDK is also out of
>> sync with version 8.
This link doesnt go anywhere anymore (like a lot of others).
The documentation for the SDK is inadequate at best. No JavaDocs for the PluginSDK out of the box, no obvious place to get it, no simple code samples - just the usual response of "go check out the Javascript or Groovy plugin".
Is Jetbrains really expecting a significant up-tick in plugin development now that things are open source?
Hello Nick,
Since you can get far more useful information from the source code than from
the JavaDocs that we had, there's no longer much sense in publishing the
JavaDocs. Just go and grab the source.
--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"