使用其他框架？ [英] use of other frameworks?

问题描述

观看
C9视频与Joe Binder和Beth Massi一起，我很高兴看到"不要重新发明轮子，使用那里的东西！"使用jQuery Mobile（一个很好的选择！）的立场，但后来我看到了其他一些领域似乎团队可以利用
现有框架。

第一个（和恕我直言更多'令人震惊'的情况）是数据绑定，其中存在地图数据的重新绑定，并且Joe提到团队已经完成了一堆数据绑定工作。  不可否认的是，对于LightSwitch不太了解，因为有多么奇怪的淘汰版本，它带来了
，它是多少让它从MVVM-in-Silverlight过渡到好看又简单，以及它是如何来自ASP的.NET团队成员Steve Sanderson。

如果有一些根本原因淘汰不适合这个，那么团队可以解释一下吗？  这将有助于解释我们其他人的事情。 :) 此外，还有许多其他数据绑定类型的引擎（例如，流星团队已经将
打包为liveui以便在流星之外使用），因此重新发明这似乎是一个特别奇怪的领域轮。  利用淘汰赛可以让我更轻松地转换到HTML客户端（诚然，我已经使用了淘汰赛，但它真棒！）

另一个可能更容易解释"为什么我们不使用那个"，但我想我还是会问。  鉴于屏幕模板的性质，看起来Twitter的引导项目及其网格系统非常适合。

在相关的说明中，无论使用（或不使用）框架对于像模板（或团队决定称之为）和布局的东西，这是"可插拔"的东西吗？  我可以想象它可能是一个PITA（鉴于乔提到的'重新管道'
是屏幕模板所必需的，所以听起来像'viewmodel'/树可能不是与生成的html / javascript分离，如此必要，但特别是作为社区努力的潜在来源，我认为这将是
a巨大的胜利。  

特别是到了这个RTM的时候，你可以期待很多网络开发团队已经拥有了他们已经使用的给定模板引擎，所以不必学习新的并保持它是一个巨大的优势。当然，团队将能够手动制作他们自己的
html客户端（我想象）与lightswitch中间层交谈，但是可扩展性优于不必扔掉它并从头开始。 :)

谢谢！

解决方案

< blockquote>

嗨詹姆斯，

感谢您的评论和反馈。 
为了回答您的一般性问题，是的，我们确实希望您需要/需要插件框架来增强或取代LightSwitch提供的功能。 
目前，我们已经真正优化了以简单方式使用JQuery和jQueryMobile插件，但我们肯定有机会为数据绑定，全球化等启用类似插件的体验。

具体参考淘汰赛，您将听不到我们关于框架有用性的任何争论 - 我第一次使用
我被它的力量和简单所震撼。它设计精巧，实用，并且在SL / WPF世界中使用具有近似类似物的模式。 
在内部，我们评估了淘汰，骨干和扩展，下划线以及其他一些鲜为人知的数据绑定框架。 
虽然没有明显的赢家或明显的选择，但他们都有优势并且解决了数据绑定和模板的一般问题。  
同样，它们也会带来一些影响，因为LightSwitch对JavaScript的支持是新的，我们还没有很好地处理可接受的内容以及API的观点。&NBSP;

作为一个例子，knockout observables是函数，它允许knockout在旧版浏览器上运行不支持getter
和setters。  相对于淘汰赛提供的易用性而言，细微差别很小。 
然而，LightSwitch屏幕/页面的视图模型构成了客户编程模型的最大份额;对于不熟悉淘汰赛的人来说，使用函数表示字段可能会出乎意料。
API模式很难改变，因此我们对第一次迭代中引入的API特别敏感。  （还有一些其他的，主要是内部细节，专门为淘汰赛进行淘汰;我只是想给你一个
的例子，其中一些东西可以作出决定。）

在任何情况下，我们认为最谨慎的路径是最小化我们第一次迭代的依赖图，并保持开放到
的更大依赖关系未来。我们的视图模型今天非常简单，未来很容易调整到特定的框架。 
我们还记住，诸如knockout之类的框架具有非常强大的可扩展性模型，并且在LightSwitch视图模型和knockout，backbone等之间实现映射并不困难。 <跨度>&NBSP;
例如，我可以轻松设想一个通用实用工具，为LightSwitch JSON模型和/或屏幕视图模型创建一个淘汰映射插件。

与此同时，我们的数据绑定功能非常简单，并且表现在单个api-bind（对象，路径，回调）中。 
如果我们为更具表现力的数据绑定（foreach，count等）或数据模板添加了现成的支持，我们很可能通过使用现有框架来实现。

如果您有兴趣整合其他框架，请告诉我们。 
我们渴望了解我们可以提供的任何特定钩子，以允许人们使用对您最有价值的框架。

再次感谢您花时间传递您的问题和反馈。 
这是我们继续前进的重要讨论。

Joe

Watching the C9 video with Joe Binder and Beth Massi, I was happy to see the "don't reinvent the wheel, use what's out there!" stance for using jQuery Mobile (an excellent choice!), but then I saw a couple other areas where it seemed like the team could have leveraged existing frameworks.

The first (and IMHO more 'egregious' case) was the data binding, where the rebinding of the map data was present, and Joe mentioned the team had done a bunch of data binding work on their own.  Admittedly, not knowing much about LightSwitch, that comes across as kind of odd given how awesome knockout.js is, how much it makes transition from MVVM-in-Silverlight nice and easy, and how it's coming from ASP.NET team member Steve Sanderson.

If there's some fundamental reason knockout isn't a good fit for this, could the team explain that?  it would help explain things for the rest of us. :)  Also, there are many other data-binding types of engines (for instance, the meteor team has been packaging up liveui to be usable outside of meteor), so it seems like a particularly odd area to reinvent the wheel.  Leveraging knockout would make my transition to the HTML client much easier (admittedly, I've used knockout, but it's awesome!)

The other one is likely easier to explain "why we don't use that", but I figured I'd ask anyway.  Given the nature of the screen templates, it seems like twitter's bootstrap project and its grid system would be a great fit.

On a related note, whatever frameworks are used (or not) for things like templating (or whatever the team decides to call it) and layout, is this something that will be 'pluggable'?  I can imagine that it might be a PITA to do so (given the 're-plumbing' that Joe mentioned was necessary for the screen templates, so it sounds like the 'viewmodel'/tree might not be as decoupled from the generated html/javascript as necessary for such), but especially as a potential source of community effort, I think it'd be a huge win.  

Especially by the time this RTM's, you can expect many web dev teams will already have a given templating engine they use already, so not having to learn a new one and maintain it would be a huge advantage. Certainly teams will be able to make their own html clients 'by hand' (I'd imagine) talking to the lightswitch middle tier, but extensibility would be preferred over having to throw it all away and start from scratch. :)

Thanks!

解决方案

Hi James,

Thanks for the comments and feedback.  In response to your general question, yes, we do expect that you’ll want/need to plug-in frameworks to augment or supersede what LightSwitch provides.  Right now, we’ve really optimized for using JQuery and jQueryMobile plugins in a straightforward manner, but there is certainly opportunity for us to enable similar plugin-like experiences for data-binding, globalization, etc.

In specific reference to knockout, you will hear no argument from us regarding the framework’s usefulness—the first time I used it I was blown away by its power and simplicity. It is very well designed, pragmatic, and uses patterns that have close analogs in the SL/WPF world.  Internally, we evaluated knockout, backbone—and by extension, underscore—and a few other lesser-known data binding frameworks.  While there was no clear winner or obvious choice, they all had strengths and solved the general problem of data-binding and templating well.   Similarly, they also carry implications that gave us some pause because LightSwitch’s support for JavaScript is new, and we don’t yet have a good handle on what’s acceptable and what’s not from an API perspective. 

As one example, knockout observables are functions, which allows knockout to work on legacy browsers that do not support getters and setters.  The nuance is small relative to the ease-of-use that knockout provides.  However, the view model of your LightSwitch screen/page constitutes the lion’s share of the programming model for the client; and using functions for something to represent fields will likely be unexpected for folks who are not familiar with knockout. API patterns are hard to change, so we are particularly sensitive to the APIs we introduce in this first iteration.  (There were some other, largely internal details to sort out for knockout specifically; I just wanted to give you an example of some of the things that informed the decision.)

In any case, we felt that the most prudent path was to minimize the dependency graph for our first iteration and remain open to taking larger dependencies in the future. Our view models are quite simple today and could easily be tuned to a specific framework in the future.  We also kept in mind that frameworks such as knockout have a very robust extensibility model, and it would not be difficult to implement a mapping between the LightSwitch view model and that of knockout, backbone, et al.  For example, I can easily envision a general-purpose utility that creates a knockout mapping plugin for the LightSwitch JSON model and/or the screen view model.

In the meantime, our data binding capabilities are pretty simplistic and manifested in a single api—bind(object, path, callback).  If we do add in-the-box support for more expressive data bindings (foreach, count, etc) or data templating, we’d very likely do so by using an existing framework.

If there are other frameworks you’re interested in integrating, please let us know.  We’re keen to understand any specific hooks we can provide to allow people to use the frameworks that are most valuable to you.

Thanks again for taking the time to pass along your question and feedback.  This is an important discussion to keep going as we move forward.

Joe

这篇关于使用其他框架？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！