- 浏览: 2106189 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
sunzeshan:
找了很久,用了这个插件解决问题啦。谢谢
eclipse jetty debug source not found -
xiaosong0112:
您好,请问为什么要这样设置呢,原理是什么?在网上很多转帖都没有 ...
maven的jetty插件提示No Transaction manager found导致启动慢的解决方法 -
eimhee:
tjzx 写道畅搜谷歌:http://dian168.cc/打 ...
Google 镜像站搜集 -
tjzx:
畅搜谷歌:http://dian168.cc/打开的是“最火源 ...
Google 镜像站搜集 -
eimhee:
finallygo 写道你这属于"头痛医头脚痛医脚& ...
解决linux下too many file问题
I'm just getting back into Ext and have noticed that Ext now has the YUI dependencies as a part of its own distribution. For example the connection, event and dom libraries. It also includes reset-min.css and appears like the next version uses the YUI grid.css and fonts.css in Ext reset-all.css.
So is the idea that people wanting to use Ext as their primary JS toolkit don't need to download YUI at all? If so, what if YUI makes bug fixes to these libraries - is Ext planning on synchronizing up with them in subsequent builds? Also it was my understanding that BSD requires preserving the original sources copyright notice. I don't see this in Ext's version of the YUI code.
I have a lot of catching up to do on Ext so forgive me if this has been asked before.
Thanks,
Sanjiv
So is the idea that people wanting to use Ext as their primary JS toolkit don't need to download YUI at all? If so, what if YUI makes bug fixes to these libraries - is Ext planning on synchronizing up with them in subsequent builds? Also it was my understanding that BSD requires preserving the original sources copyright notice. I don't see this in Ext's version of the YUI code.
I have a lot of catching up to do on Ext so forgive me if this has been asked before.
Thanks,
Sanjiv
#2
03-04-2007, 01:16 PM
|
Sanjiv,
The new Version of Ext does not rely on YUI as its base library alone. You can use it with YUI or with jQuery. More adapters (e.g. to Prototype) will come. I think because of the decoupling of YUI Jack had to add some parts to the CSS that were done by YUI before. I don't know whether he took them from YUI or from somewhere else. |
#3
03-04-2007, 02:11 PM
|
|
Quote:
I realize that Ext now supports either YUI or jQuery for some core functionality but that wasn't what I was asking. However on that note, I don't get the reason to support alternate code libraries unless it was purely a strategic decision to attract the jQuery user base. If that wasn't the only reason, then why not just pick one library that works well and move on. Supporting alternate core libraries means making sure that all things are equal and fully tested (from my understanding there are some behavioral differences and gaps in the jQuery adapter presently). Adding prototype to the mix as an alternate core library would just add complexity. As an end user, a choice of base libraries is not something I care to have (esp since YUI is BSD). I just want something that is stable and the fewer options, the better.. This reminds me of a thread : http://www.yui-ext.com/forum/viewtopic.php?t=1882 where a user tries to build a XUL'esque abstraction potentially over different library implementations. Like I said, I have some catching up to do on Ext and maybe the rationale behind this was explained somewhere but I'd like to know why.. any pointers would be appreciated. Thanks, Sanjiv |
#4
03-04-2007, 09:31 PM
|
> I don't get the reason to support alternate code libraries
That's because you are using YUI. If you were using jQuery and you wanted to use Ext widgets, you would be a happy camper. > why not just pick one library that works well and move on Why? If we can support multiple libraries, then there's no reason not to. In fact, there is probably going to be a 4th option - Ext standalone - which requires no additional libraries. > As an end user, a choice of base libraries is not something I care to have You have made your decision, and so the choice of additional libraries don't mean anything for you. But if you were already using another library (like jQuery) then it would be more appealing. Adding support for additional libraries gives other people who are not using YUI a chance to use the Ext widgets. It's a win for everyone. |
#5
03-04-2007, 09:44 PM
|
I'm not using YUI specifically, just Ext so it wouldnt matter to me if jQuery was being used under the hoods, but I see what you mean.
The point I was trying to make is that even if I were using YUI and Ext only supported jQuery (or vice-versa) it would be fine as I'd just have to include another small js file. Its not like these libraries are monsters in size. I like the 4th option of standalone Ext the best |
#6
03-04-2007, 09:48 PM
|
Me too. When I get time, I plan to make it a reality.
|
#7
03-05-2007, 11:08 AM
|
One point that's worth fleshing out, which relates to the OP's point and a couple of other threads that've been floated here and on the YUI mailing list: I completely respect the decision to make Ext independent from YUI, but there is, I think, some risk that Ext loses a bit of what made it such a compelling technology choice before (as yui-ext).
Let me explain. YUI is not the most feature-rich JS library. It doesn't have the most widgets; it doesn't give you mind-blowing capabilities you never thought browsers could do; etc.; etc. But it is remarkably well-documentated, stable, and predictable from a programmer's standpoint--once I know how to plug into a Slider's events, for example, I'm not going to have too much trouble doing the same with a Dialog. I do find it frustrating sometimes that new components like a grid take as long as they do to come out (while an army of one like Jack is doing all he's doing!), but clearly they've made a conscious decision to release in a way that reinforces the advantages I mentioned, sort of the tortoise (as opposed to the hare) strategy. During the day I work for a large company, actually a competitor of Yahoo's (well, much smaller than Yahoo, and none of us exactly "compete" nowadays anyway), and several months ago I recommended yui-ext for a rich internal app. (note: I don't use Ext/yui-ext for my work app yet, but do for personal projects.) The technology group involved loved the idea of using a stable, not-going-anywhere JS library like YUI, and of course thought Jack's stuff was ridiculously awesome, and so is using it. But , when I think about what decision they would've made if Ext had been standalone at that point ... I dunno. I'm not sure they make the same call. And maybe that's completely illogical; after all, Ext can still be used with YUI, and if Jack has been able to break it out this quickly, maybe yui-ext's codebase was never all that dependant on YUI in the first place. Still, in terms of perception, I really think yui-ext got this fantastic piggyback benefit from being an "extension" of YUI, in terms of dependability and enterprise-worthiness. It's always going to be popular in forums and message boards to do more and bigger things, but I wonder, in terms of large commercial customers (possibly better sources of $$$ than hobbyists), if putting distance between Ext and YUI is such a good thing. Again, again again again, I completely respect the decision to split it. Heck, for my personal project, Prototype is required (bundled with Sun's excellent Dynafaces for JSF) so I am actually psyched to get that 3rd adapter and cut down my page loads. And I don't doubt the ability of one person (especially Jack "Bauer" Slocum) to outproduce a group of paid programmers, but, it ought to be said, there's quite a morass of JS libraries out there, and quite a few communities coalescing around these libraries; and maintaining the sense of stability/dependability that yui-ext had without the "yui" will take lots of work. Obviously it's not my decision and there's no reason for anyone to listen to me, but I'd love to see Ext really focus on being an "Extension" for popular libraries. The big boys with wads of resources can nail down the basics like Events, Drop 'n' Drag, Dom manipulation, Ajax, etc. ... Ext doesn't reimplement these things, but wraps them in a conventient, consistent way; and instead focuses on the kind of high-quality, high-style, high-functionality widgets like the Grid and Tabbed Panel that we all know and love. Nothing on the JS landscape today can touch what Jack does in terms of pre-built, skinnable components, and this oughta be the value proposition. "Pick your library, whatever technology your organization has committed to, and then plop in Ext and get all this goodness." To me, that seems like potentially a real sweet spot in the market, whereas trying to be a better Mootools or Dojo or whatever is going to be a grind. Anyway, just my 2 cents. |
#8
03-06-2007, 05:14 AM
|
Rogers, that you for your post.
I also agree on keeping Ext "Ext", if that makes sense. The library it "extends" can now be chosen, and for those who are Ext junkies (like me) who never use the underlying library there will be an option of Ext standalone. Which is best for each project will be up to the developer, which I think is a great (and unique) option to have. |
发表评论
-
jquery dual list 插件
2010-12-21 17:24 2345In my work, I came across the n ... -
Start PageIndexHistoryLast Change
2010-12-15 00:22 997The specifications should provi ... -
ajax upload
2010-11-19 13:22 0ajax upload The following cri ... -
兼容IE和FF获取Referer的JS方法
2010-11-11 10:11 4435众所周知,我们web开发人员痛恨IE浏览器,因为IE不支持标准 ... -
jQuery优化
2010-09-16 08:30 5474之前,我们减少字节数和请求次数以及加载顺序以使页面加载的更快。 ... -
jQuery add table row
2010-08-23 13:39 0The approach you suggest is not ... -
Add and Remove items with jQuery
2010-08-23 13:25 0Add and Remove items with jQuer ... -
extjs和struts、json的整合
2009-08-13 09:52 4493使用extjs配合struts的MVC架构是目前流行的做法,两 ... -
extra 1px space in dialog handle style - Ext JS
2009-04-20 23:33 1556Im developing a new style and h ... -
Grid - Custom header renderer? - Ext JS
2009-04-20 23:33 2043Is it possible to create a cust ... -
Inputs to DatePicker - Ext JS
2009-04-20 23:33 2139I thought I had read that you c ... -
dateFormat with timezone - Ext JS
2009-04-20 23:33 3567If I create JSON data on server ... -
How to use Ext.each? - Ext JS
2009-04-20 23:33 4457I'm trying to use Ext.each. It ... -
afteredit event ... new value? - Ext JS
2009-04-20 23:33 1489the new value is not set before ... -
problem qith iframe's - Ext JS
2009-04-20 23:33 1115I want to have dialogs and wher ... -
[Grid] Ext.data documenation - Ext JS
2009-04-20 23:33 1447I'm porting my grids to use the ... -
Last column to auto-adjust - Ext JS
2009-04-20 23:33 2681I can't see that this is curren ... -
Tree non-async creation "bug" - Ext JS
2009-04-20 23:32 2375When building a tree without us ... -
Bug - reload method of AsyncTreeNode - Ext JS
2009-04-20 23:32 1987Happens when the tree config o ... -
Minor grid paging toolbar issues - Ext JS
2009-04-20 23:32 1494When a grid toolbar is displaye ...
相关推荐
sonar安全扫描插件
dependency-check-7.1.1-release
dependency_injection-1_0-final-spec
maven-dependency-versions-check-plugin-2.0.2-sources.jar
maven-dependency-versions-check-plugin-1.0.0.jar
maven-dependency-management-extension-1.1.0-sources.jar
maven-dependency-management-extension-1.0.1-sources.jar
maven-dependency-management-extension-1.0.0-sources.jar
maven-dependency-update-trigger-1.2-sources.jar
maven-dependency-update-trigger-1.1-sources.jar
maven-dependency-update-trigger-1.0-sources.jar
maven-dependency-versions-check-plugin-2.0.1-sources.jar
maven-dependency-versions-check-plugin-2.0.0-sources.jar
making-sense-dependency-injection-test-execution-listener-源码.rar
python库。 资源全名:dependency_injector-3.24.1-cp36-cp36m-win32.whl
资源分类:Python库 所属语言:Python 资源全名:dependency_injector-3.26.0-cp35-cp35m-win_amd64.whl 资源来源:官方 安装方法:https://lanzao.blog.csdn.net/article/details/101784059
python库。 资源全名:dependency_injector-4.36.0-pp27-pypy_73-win32.whl
bcprov-jdk15on-***.jar中文文档.zip,java,bcprov-jdk15on-***.jar,org.bouncycastle,bcprov-jdk15on,***,jar包,Maven,第三方jar包,组件,开源组件,第三方组件,Gradle,bouncycastle,bcprov,jdk15on,中文API文档,手册,...