Sproutcore/Qooxdoo 这样的东西有什么帮助？
我正在学习 Python 并构建我的第一个网络应用程序。我一直在阅读 django 教程，并且刚刚开始考虑如何做客户端。我希望它是 web 2.0 左右，并且需要一些 AJAX/javascript 功能来显示数据库中的列表，以及日期选择器、自动完成等很酷的东西。
似乎是 html/css/javascript （尤其是 jquery）是最受欢迎的选择。作为一个新手，我对 qooxdoo 和 sproutcore 这样的框架很感兴趣，但不明白它们到底是如何工作的。例如：
- 我可以轻松地在另一个应用程序中重用代码吗？
- 也能轻松拥有一页静态页面吗？
- 它们只有一页吗，有点像 gmail？有关系吗？
- 它真的比不使用它更容易吗？我的意思是框架的学习曲线等于学习 html/css/javascript 吗？
- 这些类型的应用程序加载速度是否较慢，因为它们有很多开销？
或者，
使用/不使用有何优点/缺点 使用其中之一？
欢迎对初学者提出任何建议！
I am learning Python and building my first web app. I have been going thru the django tutorials and just beginning to think about how to do the client side. I want it to be web 2.0-ish, and will need some AJAX/javascript functionality for displaying lists from the database, and cool things like date choosers, auto-completion, etc.
It seems html/css/javascript (esp. jquery) is the most popular option. Being a newbie I am intrigued by frameworks like qooxdoo and sproutcore, but don't understand exactly how they work. For example:
- Can I easily reuse code from one app into another?
- Can you have one page static pages easily also?
- Are they only one page, kind of like gmail? Does it matter?
- Is it really any easier than not using it? I mean is the learning curve for the framework equal to learning html/css/javascript?
- Are these type of apps slower to load because they have a lot of overhead?
Or,
What are the pros/cons of using/not
using one of these?
Any advice for a beginner is welcome!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
以下是qooxdoo角度的回答：
是的，你可以。您可以在“库”中组织代码，这些代码可以包含在多个应用程序中。但每个应用程序都将是一个单独的整体（将其视为静态链接库代码的二进制文件），无需手动复制 .js 文件。
我不确定你在这里的意思。
是的，您可以使用 qooxdoo 构建单页应用程序。
这很大程度上取决于你的背景。如果您对 OO 有很好的掌握，甚至可能有使用 Qt 或 Swing 等 OO 界面库的经验，那么选择 qooxdoo 应该非常简单。在这种情况下，我认为学习工作量比 html/css/javascript 少，因为您基本上是在针对一个 OO 类库工作，该类库向您屏蔽了底层技术。 （这是一件好事。例如，获得正确的跨浏览器 CSS 是很困难的）。
我会这么说。您需要为基础设施支付罚金。但如果您想要一个真正的 Web GUI，那么这是值得的。
正如其他地方所说，这实际上取决于您想要实现的目标。从你的问题中我了解到你不仅仅想要“显示数据库中的列表”，而且你想要一个交互式用户界面，带有高级小部件（日期选择器），跨浏览器事件处理（自动完成），也许还有其他控件、布局管理等。对于这样的情况我说利大于弊。
但这是一项投资，对于一次性项目来说太大了。如果您只想要一些列表视图，请坚持使用 Django 模板，也许还可以加入一些 Javascript。
Here is an answer from the qooxdoo perspective:
Yes, you can. You can organize your code in "libraries" which can be included in multiple apps. But each app will be an individual whole (think of it as a binary with the library code being linked in statically), there is no manual copying around of .js files.
I'm not sure what you mean here.
Yes, you build single-page applications with qooxdoo.
That largely depends on your background. If you have a good grasp on OO, maybe even experience with an OO interface library like Qt or Swing, picking up qooxdoo should be very straight-forward. In such a case I would argue the learning effort is less than compared to html/css/javascript, as you are basically working against an OO class library that shields the underlying technology from you. (Which is a good thing. Getting e.g. cross-browser CSS right is tough).
I would say so. You pay a penalty for the infrastructure. But if a real web GUI is what you want, it's worth it.
As said elsewhere, it really depends on what you want to achieve. From your question I gather that you don't just want to "display lists from a database", but you want an interactive user interface, with high-level widgets (date chooser), cross-browser event handling (auto-completion), maybe other controls, layout management, and such. For such a case I say the pros outweigh the cons.
But it's an investment, too much for a one-shot project I'd say. And if you just want a few list views, stick with the Django templates, maybe spiced up with a bit of Javascript thrown in.
你必须记住，HTML 中的 T 代表文本。 HTML 旨在显示文档。 JavaScript 为这些文档添加了交互性。在某种程度上，这是“变态”的，JavaScript 用于创建类似桌面应用程序的操作 DOM 对象的体验。
如今，如果您查看网络应用程序，您会发现主要分为三个类别：
此类应用程序基本上是内容/文档交付服务。您可以浏览、搜索、编辑和发布一些文档。基本上就是这样。 stackoverflow 是此类别的一个很好的例子。
此类应用程序向实际在服务器上运行的应用程序提供 Web 前端。它们充当在服务器上运行的业务逻辑的接口。网上银行应用程序或不同类型服务的网络界面就是一个很好的例子。在某种程度上，经典的谷歌页面是。
这些应用程序完全在客户端上运行。它们从服务器获取数据并提供用户界面，允许在客户端直接操作该数据并可能提交进度/结果。
当然，有些应用程序不能仅归入其中一个类别。
现在，对于网站来说，出于多种原因，生成语义、干净且有效的 HTML 非常重要。搜索引擎优化和可访问性是最重要的。
对于 Web 界面和 RIA，情况并非如此。在这里，在客户端，最重要的是可用性。对于 Web 界面，希望避免整个页面刷新并最大限度地方便用户输入。对于 RIA 来说，这是必须的。这两个类别都不使用 HTML 来表示文档，而是构建用户界面。
对于 Web 界面，经典表单可能会起作用，具体取决于用户输入的复杂性，因此考虑到这一点，您可以将它们视为网站或 RIA。
虽然网站使用 HTML 来表示实际数据，使用 CSS 来定义其视觉外观，使用 JavaScript 来添加交互性，但 Web 界面和 RIA 使用 DOM 对象来创建 UI，使用 CSS 来为 UI 设计外观，使用 JavaScript 来实现客户端业务逻辑。
因此，虽然您使用的平台相同，但您实际上在做完全不同的事情。把它想象成文本模式。屏幕上的字符可能代表文本，或GUI 元素。 （我想在这个类比中，网络界面将是命令提示符：D）。
qooxdoo 和 sproutcore 等框架旨在促进 RIA 的创建。由于 DOM 在这种方法中被滥用，因此它们提供了必要的抽象来在 UI 逻辑和底层 DOM 操作之间建立桥梁。它们消除了对 HTML 和 CSS 的需求，因为这些不是旨在创建交互式 UI 的工具。
根据您打算做什么，您必须选择合适的工具。
You have to bear in mind, the T in HTML stands for text. HTML is designed to show documents. JavaScript added interactivity to these documents. This was, "perverted" (in a way) up to a point, where JavaScript was used to create desktop-app-like experience manipulating DOM objects.
Nowadays, if you look at web apps, there are three main categories:
Such apps basically are content/document delivery services. you can browse, search, edit and post some documents. that's basically it. stackoverflow is a good example for this category.
Such apps present a web frontend to an application that actually runs on a server. They act as interface to a business logic, that runs on the server. Online banking apps are a good example, or web interfaces for different kinds of services. The classic google page is, in a way.
These apps completely run on the client. They obtain data from the server and provide a user interface, that allows manipulating that data right on the client side and possibly submitting a progress/result.
Of course there're apps that cannot be classified in just one of those categories.
Now for web sites, it is very important to produce semantic, clean and valid HTML, for a number of reasons. SEO and accessibility being the most important ones.
For web interfaces and RIAs, this in not the case. Here, on the client side, the most important thing is usability. For web interfaces it is desirable avoiding whole page refreshs and facilitating user input to a maximum. For RIAs, this is a must. Both categories do not use HTML to represent documents, but to build a user interface.
For web interfaces, classical forms may do the trick, depending on the complexity of user input, so you can either treat them as web sites or as RIAs for this consideration.
While websites use HTML to represent actual data, CSS to define its visual appearence and JavaScript to add interactivity, web interfaces and RIAs use DOM objects to create a UI, CSS to skin that UI and JavaScript to implement client side business logics.
So while the platform you are using is the same, you're really doing something completely different. Think of it like text mode. The characters on the screen may be representing text, or GUI elements. (I suppose web interfaces would be command prompts in this analogy :D).
Frameworks like qooxdoo and sproutcore are designed to facilitate the creation of RIAs. Since the DOM is in a way misused in this approach, they provide the necessary abstraction to bridge between UI-logics and the underlying DOM-manipulation. They nullify the need for HTML and CSS, because these are not tools designed to create interactive UIs.
Depending on what you intend to do, you will have to choose an appropriate tool.