将库或贡献包含到 qooxdoo 中

发布于 2024-09-26 06:50:41 字数 928 浏览 2 评论 0原文

我尝试在 qooxdoo 中使用 xqjqplot 库,但在使用生成源生成期间仍然收到错误消息。

错误:

Unknown global symbol referenced: qxjqplot.Plot

我的 config.json 看起来像

"libraries" : {
   "library" : [{
     "manifest"   : "contrib://qxjqplot/trunk/Manifest.json",
     "uri"        : "../QxJqPlot/trunk" // the trunk of the checked out QX lib
   }]
},

在我的班级中,我尝试使用 varplot = new qxjqplot.Plot( .... ); 访问 qxjqplot 但名称空间未解析。

我使用 QX 1.0.2-pre。是否需要进行任何额外的调整

我需要做什么才能使其正常工作?

*****编辑*******

迁移到 1.2.1 后,我遇到了相同的错误。库已正确链接,编译器不再抛出错误(如上所述)。通常这应该有效,但事实并非如此。在初始化绘图期间未找到命名空间。

*****结束编辑*****

谢谢。

I try to use the xqjqplot library within qooxdoo, but i still get a error message during generating with generate-source.

Error:

Unknown global symbol referenced: qxjqplot.Plot

My config.json looks like

"libraries" : {
   "library" : [{
     "manifest"   : "contrib://qxjqplot/trunk/Manifest.json",
     "uri"        : "../QxJqPlot/trunk" // the trunk of the checked out QX lib
   }]
},

In my class i try to access qxjqplot with var plot = new qxjqplot.Plot( .... ); but the namespace is not resolved.

I Use QX 1.0.2-pre. Are there any additinal adjustments required

What do i have to do to get this working?

***** edit *******

After migrating to 1.2.1 i get the same errors. The library is linked correctly and the compiler does not throw the Error (described above) anymore. Usualy this should work, but it doesnt. During Initializing the Plot the namespace is not found.

***** end edit *****

thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

甜是你 2024-10-03 06:50:41

其一,既然 1.0.2 已经发布很久了,为什么还要使用 -pre 版本?

然后,除非您 100% 确定您知道自己在做什么,否则我建议从库条目中删除“uri”参数。仅当您从 Web 服务器运行应用程序时,这才有效(无论如何不建议对源版本)。您确定此 URI 在运行时解析为正确的路径吗?生成器的默认 URI 构造通常很好并且可以满足您的要求。如果您可以从 file:// URL 运行您的应用程序,那么您应该依赖它。

贡献是否正确下载?当生成器尝试在线访问它时,您是否会收到警告? Sourceforge 更改其 ViewVC 前端时出现问题(请参阅此 bug 获取补丁这)。

你能检查一下你的下载缓存吗?在 Linux 上,它通常位于 /tmp/cache/downloads 下(您可以使用 generate.py source -w 获取作业设置的详细日志记录;扫描 'cache': {.. .'downloads':...} 在标题 >>> Expanded job config: 下查找文件系统上的路径)。

如果您不确定 contrib 是否正确下载,请从 Sourceforge 下载 直接(查找“下载 GNU tarball”)。将其放在文件系统上的合适路径中,只需调整库条目的“manifest”参数以指向本地 Manifest.json(相对路径效果最佳)。

你得到什么?

For one, why are you using a -pre version, when 1.0.2 is since long released?!

Then, unless you are 100% sure you know what you're doing, I would recommend dropping the "uri" parameter from the library entry. This can only work if you run the app from a web server (which is not recommended for source versions anyway). Are you sure this URI resolves to the correct path during run time? The default URI construction of the generator is usually fine and does what you want. If you can run your app from a file:// URL, you should rely on that.

Is the contrib downloaded correctly? Do you get warnings when the generator tries to access it online? There were issues with Sourceforge changing their ViewVC frontend (see this bug for a patch for this).

Can you check your download cache?! On Linux it's usually under /tmp/cache/downloads (You can use generate.py source -w to get a verbose logging of your job settings; scan for 'cache': {...'downloads':...} under the heading >>> Expanded job config: to find the path on your file system).

If you are in doubt if the contrib is downloaded correctly, download it from Sourceforge directly (look for "Download GNU tarball"). Put it in a suitable path on your file system and just adapt the "manifest" parameter of the library entry to point to the local Manifest.json (relative paths work best).

What do you get?

夏日浅笑〃 2024-10-03 06:50:41

使用绝对路径设置 URI 确实有效。也许这是一个依赖于浏览器的问题。

Settng the URI with a absolute path did work. Perhaps this was an browser-dependent issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文