Jaxer的优缺点 [英] Pros and cons with Jaxer

查看:166
本文介绍了Jaxer的优缺点的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我意识到这个问题已经问过了,但是它已经过去一个月都没有体面的回应...我正在查看

脚本使用<script>标记放置在页面上,并且可以指定runat属性(ala ASP.NET)来标记脚本以在客户端,服务器(两者)上或作为"server-proxy"执行这使功能在客户端上可用,但是它们通过AJAX在服务器上执行.这也意味着您可以在服务器以及客户端上使用自己喜欢的客户端库(jQuery,Prototype).

它还可以用于处理用另一种语言(例如php,ruby)生成的文档,我认为这是不切实际的,只是有助于将现有应用程序转换为使用Jaxer.

  • 优缺点是什么?
  • API的成熟度/稳定性如何?
  • 与 其他服务器端html 预处理器?
  • 有没有人和其他人一起使用Jaxer 技术(php,珍珠,红宝石等) 你的经历是什么?

关于我在使用Jaxer时发现的缺点,我发布了另一个问题:定义使用Jaxer时的对象

解决方案

我已经很长时间没有使用Jaxer了,但是我发现了一些东西:

专业人士

  • 用相同的代码编写前端和后端.特别适合编写验证逻辑.
  • 无缝" AJAX通信返回到服务器-就像调用JS函数一样.
  • 使用jQuery之类的JavaScript框架来操作DOM的能力.
  • 使用Canvas API生成或处理图像的功能.
  • 您可以使用大量的JavaScript 1.8新功能(例如Array Extras和getters/setters)来编写服务器JavaScript.

缺点

  • 我发现他们的API不稳定(当我尝试时它们正在过渡到1.0,这样就可以理解),并且文档令人困惑,丢失或与更改的功能不匹配.我还发现调试我的Jaxer服务器端代码非常困难,并且当我遇到麻烦时,错误消息不是很有帮助.
  • 在演示文稿和逻辑之间没有真正的MVC甚至MVP(ASP.NET风格)分隔.
  • 我个人无法使E4X(JavaScript中的xml)正常工作,这本来应该很吸引人.
  • 围绕它构建许多应用程序的框架并不多.您是从一些非常基本的构建块开始的.
  • 它实际上并没有提供任何帮助,因此请忘记您可能在其他地方使用的所有模板化或可重用组件.并不是说您不能复制它,但是比开箱即用要困难得多.

总的来说,我认为Jaxer作为另一个web framewok的后处理器最有前途.使用Jaxer将所有精美的AJAX内容分层放置在现有站点的顶部将是很棒的.在服务器和客户端之间共享具有验证/页面操作逻辑的动态站点将变得容易得多.我认为我不想只使用Jaxer编写应用程序.另外,它还很年轻(而且还不成熟)-我很想知道它的结局.

I realize that this question has been asked before, but it has been a month with no decent responses... I'm looking at Aptana's Jaxer and I find the concept to be very exciting.

Here is a quick overview for those who are not familiar with it:

Jaxer is, in their words, "the world's first true AJAX server". It is based on the Mozilla engine so scripts are written with javascript and you have complete access to the DOM on the server-side.

Scripts are placed on your pages with <script> tags and you can specify a runat attribute (ala ASP.NET) to mark scripts for execution on the client, server, both, or as a "server-proxy" which makes the functions available on the client, but they execute on the server via AJAX. This also means that you can use your favorite client-side libraries (jQuery, Prototype) on the server as well as the client.

It also can be used to process documents that are generated in another language (e.g. php, ruby) which I imagine is not practical except to help in transitioning existing applications to use Jaxer.

  • What are the pros and cons?
  • How mature/stable is it the API?
  • How good is performance compared to other server-side html preprocessors?
  • Has anyone used Jaxer with another technology (php, pearl, ruby, etc.) and what were your experiences?

EDIT: I've posted another question regarding a drawback I discovered while playing with Jaxer: Defining objects when using Jaxer

解决方案

I didn't use Jaxer for very long, but here's some things I found:

Pros

  • Write the frontend and backend in the same code. Especially nice for writing validation logic.
  • "Seamless" AJAX communication back to the server - it's just like calling a JS function.
  • The ability to use JavaScript frameworks like jQuery to manipulate the DOM.
  • The ability to generate or manipulate images using the Canvas API.
  • You get to write your server JavaScript using whizzy new JavaScript 1.8 features like Array extras and getters/setters.

Cons

  • I found their API to be unstable (they were transitioning to 1.0 when I was trying it so that kinda made sense) and the documentation was confusing, missing, or didn't match with changed functionality. I also found that it was very hard to debug my Jaxer server-side code, and when I got in trouble the error messages weren't very helpful.
  • You don't get real MVC or even MVP (ASP.NET-style) separation between your presentation and your logic.
  • I personally couldn't get E4X (xml in JavaScript) working, which was supposed to be a big draw.
  • There's not a lot of framework built around it for building a whole application. You're starting from some pretty basic building blocks.
  • It's not really providing any help in your view, so forget all the templating or reusable components you might use elsewhere. Not that you can't replicate that, but it's more difficult than having it out of the box.

Overall, I think Jaxer has the most promise as a postprocessor in front of another web framewok. It would be great to use Jaxer to layer all the spiffy AJAX stuff on top of an existing site. It would make it a lot easier to make a dynamic site with validation / page manipulation logic shared between server and client. I don't think I would want to write an application using only Jaxer. Also, it's young (and immature) - I'll be interested to see where it ends up.

这篇关于Jaxer的优缺点的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆