【发布时间】:2018-07-06 13:06:35
【问题描述】:
我正在尝试通过使用类似 java 的包、类和导入来定义语法来学习 Xtext。我的语法片段如下所示,其中 CompilationUnit 是根对象。
CompilationUnit:
packageDeclaration=PackageDeclaration?
imports+=ImportDeclaration*
topClass=Class
;
packageDeclaration:
'package' path=QualifiedName ';'
;
ImportDeclaration:
'import' importedNamespace=QualifiedNameWithWildCard ';'
;
Class:
{Class} visibility=Visibility isStatic?='static' 'class' name=ID ('extends' superClass=[Class|QualifiedName])? body=ClassBody
;
为了导入交叉引用,我使用 DefaultGlobalScopeProvider,并使用我自己的版本覆盖了 QualifiedNameProvider,该版本将包名称附加为 topClass 的 QualifiedName 的前缀。为了自动化自己的包导入,我编辑了项目特定的 ScopeProvider。所有这一切似乎工作得很好,并且使用生成的 Eclipse IDE,我可以使用“import [packageName].[*|ClassName]”从其他文件导入类。 (仍在与引用者在同一个包中自动导入类的工作,但目前我可以通过显式导入来管理)
我正在尝试的下一步是验证导入和包声明。我想实现与 Java 相同的限制,即文件的包声明应该等于文件的相对路径,另一方面我想验证导入的类或包的存在。问题是通过 EObject 的 eResource 我只能访问资源的完整 URI(例如 platform:/resource/Sample/src/mypack/Sample.myjava),而相对于源文件夹的路径名会更短( mypack/Sample.myjava)。我还没有弄清楚是否应该使用一些逻辑或完全不同的方法来剪辑 URI。
一个可能的想法可能是以某种方式获取项目的每个类路径目录的 URI 并从那里开始工作,但我还没有弄清楚如何做到这一点。
知道我应该如何验证我的包和导入声明吗?我一直觉得我很接近,但到目前为止。
编辑:删除了对 DefaultGlobalScopeProvider 行为的误解。这与文件层次结构无关,而仅与限定名称有关。我还可以自动导入自己的包。
更新:考虑到这一点,我应该通过枚举可用资源并检查它们的限定名称来适当地验证导入。那么只有包声明验证需要文件层次结构检查。
Update2:在 Eclipse 中,资源 URI 的格式似乎总是“平台:/资源/[项目]/[src 文件夹]/...”。假设这意味着我可以对其进行严格检查,但是在语法项目验证器中执行此操作会创建对 Eclipse 的语法级依赖,这对于任何严肃的 DSL 项目来说可能都不是一个好主意。然而,这篇文章中的一条评论让我想到,也许我应该考虑在语法级别根本不进行包位置验证,而只在 UI 项目中进行(我还没有改变)。这个想法是,资源的位置可能应该以比传统文件系统层次结构更抽象的形式保留。
【问题讨论】:
-
您是否查看过 jdt / IjavaProjects 以及访问源文件夹的可能性?你看过 xtend 中的验证吗? org.eclipse.xtend.ide.validator.XtendUIValidator.checkFileNamingConventions(XtendFile)
-
在那个项目中,验证似乎是在 UI 项目而不是语法项目中进行的,这让我想到是否应该在语法项目中进行包位置检查。在我的帖子中添加了关于此的更新。
-
独立模式下没有项目和源文件夹
标签: xtext