<!-- <questionid="arch-overall"when="init"> Describetheoverallarchitecture. <hint> WhatwillbeAPIfor <ahref="http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi"> clientsandwhatsupportAPI</a>? Whatpartswillbepluggable? Howwillplug-insberegistered?Pleaseuse<code><apitype="export"/></code> todescribeyourgeneralAPIsandspecifytheir <ahref="http://openide.netbeans.org/tutorial/api-design.html#category-private"> stabilitycategories</a>. Ifpossiblepleaseprovidesimplediagrams. </hint> </question>
-->
<answer id="arch-overall">
<p>
The lexer/nbbridge module provides the implementation of the <code>org.netbeans.spi.lexer.LanguageProvider</code>
interface that allows to register <code>org.netbeans.api.lexer.Language</code>s and maps of
embedded languages in the MimeLookup. It's basically a bridge between the netbeans-independent
lexer module and Netbeans (MimeLookup).
<br/>
The module does not provide any API at all and the SPI is reduced to extending
MimeLookup and defining a special folder for registering embedded languages.
</p>
</answer>
<!-- <questionid="arch-quality"when="init"> Howwillthe<ahref="http://www.netbeans.org/community/guidelines/q-evangelism.html">quality</a> ofyourcodebetestedand howarefutureregressionsgoingtobeprevented? <hint> Whatkindoftestingdo youwanttouse?Howmuchfunctionality,inwhichareas, shouldbecoveredbythetests?Howyoufindoutthatyour projectwassuccessful? </hint> </question>
-->
<answer id="arch-quality">
<p>
There are unit tests written for the module. They cover the functionality
of the <code>org.netbeans.api.lexer.LanguageProvider</code>'s implementation provided by the module.
</p>
</answer>
<!-- <questionid="arch-time"when="init"> Whatarethetimeestimatesofthework? <hint> Pleaseexpressyourestimatesofhowlongthedesign,implementation, stabilizationarelikelytolast.Howmanypeoplewillbeneededto implementthisandwhatistheexpectedmilestonebywhichtheworkshouldbe ready? </hint> </question>
-->
<answer id="arch-time">
<p>
The module is very simple and it's functinality is pretty much done. Obviously
there might be needed some fixes or changes over the time, but besides of that
the project is finished.
</p>
</answer>
<!-- <questionid="arch-usecases"when="init"> <hint> Contentofthisanswerwillbedisplayedaspartofpageat http://www.netbeans.org/download/dev/javadoc/usecases.html Youcanusetags<usecasename="name>regularhtmldescription</usecase> andifyouwanttouseanURLyoucanprefixifwith@TOP@tobegin attherootofyourjavadoc </hint> Describethemain<ahref="http://openide.netbeans.org/tutorial/api-design.html#usecase"> usecases</a>ofthenewAPI.Whowilluseitunder whatcircumstances?Whatkindofcodewouldtypicallyneedtobewritten tousethemodule? </question>
-->
<answer id="arch-usecases">
<p><usecase name="Language for mime-type"id="lang-for-mime-type">
Basic information the lexer module needs to function properly is an implementation
of a language and its tokens. This information in form of <code>Language</code>
is used for lexing a text input. The lexer API accepts <code>Language</code>
either explicitely or it tries to determine it from a mime type of an input document.
<br/>
The lexer/nbbridge module provides the implementation of the <code>org.netbeans.spi.lexer.LanguageProvider</code>
interface, which looks for <code>Language</code>s in MimeLookup.
This allows other modules registering <code>Language</code>s of
languages they implement into MimeLookup. Such a <code>Language</code>
should be registered under a mime-type appropriate for files that are normally
used for storing text (i.e. source code) in this language.
<br/>
Assuming that there is a language called 'Simple Plain Language' and files
containing source text of this language have a mime-type of 'text/x-simple-plain'
the <code>org.netbeans.api.lexer.Language</code> for this language
could be implemented by the following class.
<pre> public final class SimplePlainTokenId {
... // Token ids definition
private static final Language<SimplePlainTokenId> language = new LanguageHierarchy<SimplePlainTokenId>() {
public Lexer<SimplePlainTokenId> createLexer(LexerRestartInfo<SimplePlainTokenId> info) {
return new SimplePlainLexer(info);
}
public LanguageEmbedding embedding(
Token<SimplePlainTokenId> token, boolean tokenComplete,
LanguagePath languagePath, InputAttributes inputAttributes) {
return null; // No embedding
}
public String mimeType() {
return "text/x-simple-plain";
}
}.language();
public static Language<SimplePlainTokenId> language() {
return language;
}
}
</pre>
<br/>
The <code>SimplePlainTokenId.language()</code> should be registered in MimeLookup under
the 'text/x-simple-plain' mime type in order to make it available for the
lexer module. This registration can be done using the following fragment
of a module layer.
<pre>
<filesystem>
<folder name="Editors">
<folder name="text">
<folder name="x-simple-plain">
<file name="org-netbeans-modules-lexer-nbbridge-test-simple-SimplePlainTokenId.instance">
<attr name="instanceCreate" methodvalue="org.netbeans.modules.lexer.nbbridge.test.simple.SimplePlainTokenId.language()"/>
<attr name="instanceOf" stringvalue="org.netbeans.api.lexer.Language"/>
</file>
</folder>
</folder>
</folder>
</filesystem>
</pre>
This of course assumes that the <code>SimplePlainTokenId</code> class resides
in the <code>org.netbeans.modules.lexer.nbbridge.test.simple</code> package.
</usecase></p>
<p><usecase name="Embedded Languages"id="embedded-lang">
The reality of today's world is that some source files contain text in several
different languages. As an example you can think of javadoc comments in
a java source file, of java scriplets in a JSP file or of JavaScript in
an HTML file. The lexer module covers language embedding by allowing tokens
from one language to contain text in another language. Such a token can be
further lexed using the embedded language and provide a new set of sub-tokens.
Obviously, the language embedding is recursive and there is no limit on how
many languages can be embedded or how deep the embedding hierarchy can go.
<br/>
The lexer API supports two ways of defining tokens that contain text in
another language and specifying what language that is. First, an implementation
of <code>org.netbeans.api.lexer.Language</code> can override
the <code>embedding</code> method and return <code>Language</code>
of an embedded language for each token that contains text in an embeded language.
This way puts the implementation of the hosting language in control of
what tokens contain an embedded contents and what language this contnents
represents.
<br/>
Another alternative is for an implementor of a language that could potentianly
be embedded to some other language to extend a token from that language (hosting language)
and specify that the token can be further broken to tokens from another language. The lexer/nbbridge module allows this to be done declaratively in MimeLookup.
<br/>
Assuming that there are two languages called 'Simple Plain Language' and 'Simple Char Language' and that the Simple Char Language is embedded
into the Simple Plain Language extending the Simple Plain Language's token
WORD the registration can be achieved by the following fragment of a
module layer.
<pre>
<filesystem>
<folder name="Editors">
<folder name="text">
<folder name="x-simple-char">
<file name="org-netbeans-modules-lexer-nbbridge-test-simple-SimpleCharLanguage.instance">
<attr name="instanceCreate" methodvalue="org.netbeans.modules.lexer.nbbridge.test.simple.SimpleCharLanguage.description"/>
<attr name="instanceOf" stringvalue="org.netbeans.api.lexer.Language"/>
</file>
</folder>
<folder name="x-simple-plain">
<file name="org-netbeans-modules-lexer-nbbridge-test-simple-SimplePlainLanguage.instance">
<attr name="instanceCreate" methodvalue="org.netbeans.modules.lexer.nbbridge.test.simple.SimplePlainLanguage.description"/>
<attr name="instanceOf" stringvalue="org.netbeans.api.lexer.Language"/>
</file>
<folder name="languagesEmbeddingMap">
<file name="WORD"><![CDATA[text/x-simple-char]]></file>
</folder>
</folder>
</folder>
</folder>
</filesystem>
</pre>
Please note that the <code>Language</code> implementations of
both languages are registered under their respective mime types (i.e.
text/x-simple-plain and text/x-simple-char). The implementing classes are
placed in the <code>org.netbeans.modules.lexer.nbbridge.test.simple</code>
package.
<br/>
The interesting bit is the <code>languagesEmbeddingMap</code> folder and its
files. This folder contains a map of languages that extend tokens from the
Simple Plain Language (i.e. text/x-simple-plain). Each file's name is
a name of a token from the Simple Plain Language, which contains text
in an embedded language. The embedded language is determined by the contents
of the file, which is a mime type of that language.
<br/>
Therefore this module layer fragment specifies that the WORD token from
the Simple Plain Language contains text in an embedded language with the 'text/x-simple-char' mime-type, where the Simple Char Language's implementation
is registered.
</usecase></p>
</answer>
<!-- <questionid="arch-what"when="init"> Whatisthisprojectgoodfor? <hint> Pleaseprovidehereafewlinesdescribingtheproject, whatproblemitshouldsolve,providelinkstodocumentation, specifications,etc. </hint> </question>
-->
<answer id="arch-what">
<p>
This module allows others to register lexer services (i.e. their implementations
of <code>org.netbeans.api.lexer.Language</code>) for a particular mime type or mime path. It
also allows to extend a token provided by some <code>org.netbeans.api.lexer.Language</code> and
register a new <code>org.netbeans.api.lexer.Language</code> for the embedded language represented
by this token.
The registration mechanism is based on MimeLookup and the system filesystem (i.e. module layers).
</p>
</answer>
<!-- <questionid="compat-deprecation"when="init"> Howtheintroductionofyourprojectinfluencesfunctionality providedbypreviousversionoftheproduct? <hint> Ifyouareplanningtodeprecate/remove/changeanyexistingAPIs, listthemhereaccompaniedwiththereasonexplainingwhyyou aredoingso. </hint> </question>
-->
<answer id="compat-deprecation">
<p>
This module is an extension of the functionality provided by the lexer module.
It provides for a better integration of the lexer module and Netbeans. There
are no incompatible changes to or other influences on existing APIs.
</p>
</answer>
<!-- <questionid="compat-i18n"when="impl"> Isyourmodulecorrectlyinternationalized? <hint> Correctinternationalizationmeansthatitobeysinstructions at<ahref="http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/i18n-branding.html"> NetBeansI18Npages</a>. </hint> </question>
-->
<answer id="compat-i18n">
<p>
Yes. The module does not have any UI at all besides of the name and description
of the module itself.
</p>
</answer>
<!-- <questionid="dep-platform"when="init"> Onwhichplatformsdoesyourmodulerun?Doesitruninthesame wayoneach? <hint> IfyouplananydependencyonOSoranyusageofnativecode, pleasedescribewhyyouaredoingsoanddescribehowyouenvision toenforcetheportabilityofyourcode. Pleasenotethatthereisasupportfor<ahref="http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-os-specific">OSconditionally enabledmodules</a>whichtogetherwithautoload/eagermodules canallowyoutoenabletoprovidethebestOSawaresupport oncertainOSeswhileprovidingcompatibilitybridgeonthenot supportedones. Alsopleaselistthesupported OSes/HWplatformsandmentionedthelovestversionofJDKrequired foryourprojecttorunon.AlsostatewhetherJREisenoughor youreallyneedJDK. </hint> </question>
-->
<answer id="dep-platform">
<p>
All platforms supporting the required JRE and it runs the same way on all of them.
</p>
</answer>
<!-- <questionid="deploy-dependencies"when="final"> Whatdoothermodulesneedtodotodeclareadependencyonthisone, inadditiontoorinsteadofthenormalmoduledependencydeclaration (e.g.tokenstorequire)? <hint> Provideasampleoftheactuallinesyouwouldaddtoamodulemanifest todeclareadependency,forexampleOpenIDE-Module-Requires:some.token. Ifothermodulesshouldnotdependonthismodule,orshouldjustusea simpleregularmoduledependency,youcanjustanswer"nothing".Ifyou intentionallyexposeasemistableAPItoclientsusingimplementation dependencies,youshouldmentionthathere(butthereisnoneedtogive anexampleofusage). </hint> </question>
-->
<answer id="deploy-dependencies">
<p>
The lexer module 'OpenIDE-Module-Recommends' that there should be an implementation
of the <code>org.netbeans.spi.lexer.LanguageProvider</code>. The lexer/nbbridge
module provides such an implementation and therefore declares this token as
provided. It would enough for other modules to declare a module dependency on
the lexer/nbbridge module should they need to register lexer services in MimeLookup.
</p>
</answer>
<!-- <questionid="lookup-register"when="final"> Doyouregisteranythingintolookupforothercodetofind? <hint> Doyouregisterusinglayerfileorusing<code>META-INF/services</code>? Whoissupposedtofindyourcomponent? </hint> </question>
-->
<answer id="lookup-register">
<p>
The modules registers an implementation of the <code>org.netbeans.spi.lexer.LanguageProvider</code>
interface in the default lookup.
</p>
</answer>
<!-- <questionid="perf-mem"when="final"> Howmuchmemorydoesyourcomponentconsume?Estimate witharelationtothenumberofwindows,etc. </question>
-->
<answer id="perf-mem">
<p>
Pretty much none. The module does not store or cache anything; it just provides
the way of finding implementations of <code>org.netbeans.api.lexer.Language</code>.
</p>
</answer>
<!-- <questionid="resources-layer"when="final"> Doesyourmoduleprovideownlayer?Doesitcreateanyfilesor foldersinit?Whatitistryingtocommunicatebythatandwithwhich components? <hint> NetBeansallowsautomaticanddeclarativeinstallationofresources bymodulelayers.Moduleregisterfilesintoappropriateplaces andothercomponentsusethatinformationtoperformtheirtask (buildmenu,toolbar,windowlayout,listoftemplates,setof options,etc.). </hint> </question>
-->
<answer id="resources-layer">
<p>
No, but it expects other modules to register their lexer services in MimeLookup.
Specifically, modules can register embedded languages under the <code>languagesEmbeddingMap</code>
subfolder of particular mime-paths.
</p>
</answer>
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung und die Messung sind noch experimentell.