`
eimhee
  • 浏览: 2106189 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

questions on dependency of ext on yui - Ext JS

阅读更多
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
Reply With Quote
  #2  
Old 03-04-2007, 01:16 PM
Default

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.
Reply With Quote
  #3  
Old 03-04-2007, 02:11 PM
Default

Quote:
Originally Posted by dj
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.
I'm looking at the Ext source and it does include the yui code.

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
Reply With Quote
  #4  
Old 03-04-2007, 09:31 PM
Default

> 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.
Reply With Quote
  #5  
Old 03-04-2007, 09:44 PM
Default

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
Reply With Quote
  #6  
Old 03-04-2007, 09:48 PM
Default

Me too. When I get time, I plan to make it a reality.
Reply With Quote
  #7  
Old 03-05-2007, 11:08 AM
Default

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.
Reply With Quote
  #8  
Old 03-06-2007, 05:14 AM
Default

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.
Reply With Quote
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics