|
锁定老帖子 主题：YUI的一点优点
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-12-20
使用YUI在页面生成Widget时，我们可以使用markup的模式，在这种模式下，生成的widget是从已有的HTML Element中读取一定的信息，并适当的复用一些已有的HTML Element，例如，你可以用以下的HTML元素来生成一个Panel：
<div id="panel1">
<div class="hd">Panel #1 from Markup</div>
<div class="bd">This is a Panel that was marked up in the document.</div>
<div class="ft">End of Panel #1</div>
</div>
使用如下的JS： var panel = new YAHOO.widget.Panel("panel1", {
/* other properies */
});
那么，这种特点的好处是什么？有一种WEB开发的理论叫做Progressive Enhancement，意在在保证WEB程序对用户提供基本的体验后，再逐步加强应用的用户体验，这样，即使用户的浏览器不支持JS，你的页面他也可以查看的到基本的信息，并且，对于SEO非常有效。并且，YUI使用的markup是完全符合w3c标准的。（想到DOJO的dojoType了嘛？），YUI中的这种例子很多，例如Menu可以从ul li标签生成，DataTable可以从页面的Table元素读取数据…… 嗯，因为之前用EXT，整个页面就几个空空的DIV，所以才想找一种有利于在浏览器不支持JS的情况下也能给用户呈现基本视图的方法，于是重新拾起了YUI。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2007-12-20
ext也有这功能啊，属性好像是contentEl
Ext.form.ComboBox也可以直接从页面的ul li标签来 |
| 返回顶楼 | |
|
发表时间：2007-12-20
bagwg1127 写道 ext也有这功能啊，属性好像是contentEl
Ext可以指定applyTo和renderTo,但总觉得还是YUI做得比较好,比较实用
Ext.form.ComboBox也可以直接从页面的ul li标签来 |
| 返回顶楼 | |
|
发表时间：2007-12-21
关于Rich Client框架，我认为其主要适用范围是构建Application，而非制作网页，所以楼主所提出的方面在一定程度上可以被牺牲。
不知道谁能详细讲解下applyTo和renderTo区别，以及render()和applyToMarkup()方法的区别，上次问过，给丢到新手区了。看过源码，似懂非懂。 |
| 返回顶楼 | |
|
发表时间：2007-12-21
bigxxs 写道 关于Rich Client框架，我认为其主要适用范围是构建Application，而非制作网页，所以楼主所提出的方面在一定程度上可以被牺牲。 Ext与YUI都没有说过自己是一个专用于RIA的框架吧，主要是自已用EXT做了两个项目之后，感觉太像是桌面应用了，我不清楚用户是否一定能够接受这种应用。我的本意也不是说用YUI和EXT等框架来制作网页，主要目的是想找到一种“非侵入”的方法来增强WEB应用的可用性和用户体验。不如假如如你所说，使用EXT和YUI作为RIA的框架，我也希望我构建的Application在任意的情况下都可以被用户使用（比如用户禁用了JS），而且，单纯的使用JS作为RIA框架，很不利于搜索引擎的检索。
不知道谁能详细讲解下applyTo和renderTo区别，以及render()和applyToMarkup()方法的区别，上次问过，给丢到新手区了。看过源码，似懂非懂。 |
| 返回顶楼 | |
|
发表时间：2007-12-21
bigxxs 写道 关于Rich Client框架，我认为其主要适用范围是构建Application，而非制作网页，所以楼主所提出的方面在一定程度上可以被牺牲。
不知道谁能详细讲解下applyTo和renderTo区别，以及render()和applyToMarkup()方法的区别，上次问过，给丢到新手区了。看过源码，似懂非懂。 对于applyTo和renderTo，我们在Ext 2.0的官方文档上可以看到， 引用 applyTo : Mixed
The id of the node, a DOM node or an existing Element corresponding to a DIV that is already present in the document that specifies some structural markup for this component. When applyTo is used, constituent parts of the component can also be specified by id or CSS class name within the main element, and the component being created may attempt to create its subcomponents from that markup if applicable. Using this config, a call to render() is not required. If applyTo is specified, any value passed for renderTo will be ignored and the target element's parent node will automatically be used as the component's container. 引用 即applyTo代表一个在页面上已经存在的元素或该元素的id，该元素通过markup的方式来表示欲生成的组件的某些结构化信息，Ext在创建一个组件时，会首先考虑使用applyTo元素中的存在的元素，你可以认为applyTo是组件在页面上的模板，与YUI中的markup模式很相似。当你在config中配置了applyTo属性后，renderTo属性将会被忽略。并且生成的组件将会被自动置去applyTo元素的父元素中。
引用 renderTo : Mixed
The id of the node, a DOM node or an existing Element that will be the container to render this component into. Using this config, a call to render() is not required. 引用 renderTo主要用来表示新生成的组件在页面上的container
让我们来看看Component.js中的相应代码：
if(this.applyTo){
this.applyToMarkup(this.applyTo);
delete this.applyTo;
}else if(this.renderTo){
this.render(this.renderTo);
delete this.renderTo;
}
applyToMarkup : function(el){
this.allowDomMove = false;
this.el = Ext.get(el);
this.render(this.el.dom.parentNode);
}
可见applyTo在Component级别是取得applyTo的parentNode来调用render()，各种继承自Component的组件会在各自的onRender方法中来构建组件，使用CSS选择器来选择相应的元素而不是新生成相应的元素。 例如Panel.js中
if(this.el){ // existing markup
this.el.addClass(this.baseCls);
this.header = this.el.down('.'+this.headerCls);
this.bwrap = this.el.down('.'+this.bwrapCls);
var cp = this.bwrap ? this.bwrap : this.el;
this.tbar = cp.down('.'+this.tbarCls);
this.body = cp.down('.'+this.bodyCls);
this.bbar = cp.down('.'+this.bbarCls);
this.footer = cp.down('.'+this.footerCls);
this.fromMarkup = true;
}else{
this.el = ct.createChild({
id: this.id,
cls: this.baseCls
}, position);
}
|
| 返回顶楼 | |
|
发表时间：2007-12-25
ext最让人郁闷的地方就是页面上只有一堆div,对美工设计页面时的要求有点高.我感觉对我而言,能从html element中获取数据是最好的方法
|
| 返回顶楼 | |
|
发表时间：2007-12-25
LZ在YUI的看法上，我是非常赞同的。但是LZ提及的Progressive Enhancement，个人觉得，还不够完整。不过，这已经和主要矛盾十分接近了。且不论YUI和EXT的方式谁好谁坏，单纯从技术的角度来看。
基于JS的Ajax RIA，严格来讲，根本就不算是RIA，它与Flex、Applet等根本就不是用一个东西。我姑且这样定义，RIA是Web应用未来发展趋势，RIA比传统的基于HTML的ThinClient要“高级”很多。那么，很明显的，一个纯粹的基于HTML的ThinClient应用，可以通过多种方式“升级”成为AjaxRIA，而，一个完全的AjaxRIA（比如Ext）根本无法（或者很难）降级成为一个基于HTML的ThinClient应用。 不仅用户体验需要Progressive Enhancement，技术领域同样也需要Progressive Enhancement。如果说你不能肯定用户一定满意你的DesktopStyle，那么同样的，你也无法肯定用户的硬件环境就一定能够接受AjaxRIA（带宽、客户机浏览器环境、客户机性能等等都有很大的不确定性）。因此，仅仅高姿态的将自己的应用定义为AjaxRIA是一种冒险行为。 综上，我非常赞成LZ的想法——因为我也是这样想的，只是对于Progressive Enhancement，我小小的补充了一下，呵呵。 |
| 返回顶楼 | |
|
发表时间：2007-12-26
jellyme 写道 LZ在YUI的看法上，我是非常赞同的。但是LZ提及的Progressive Enhancement，个人觉得，还不够完整。不过，这已经和主要矛盾十分接近了。且不论YUI和EXT的方式谁好谁坏，单纯从技术的角度来看。
基于JS的Ajax RIA，严格来讲，根本就不算是RIA，它与Flex、Applet等根本就不是用一个东西。我姑且这样定义，RIA是Web应用未来发展趋势，RIA比传统的基于HTML的ThinClient要“高级”很多。那么，很明显的，一个纯粹的基于HTML的ThinClient应用，可以通过多种方式“升级”成为AjaxRIA，而，一个完全的AjaxRIA（比如Ext）根本无法（或者很难）降级成为一个基于HTML的ThinClient应用。 不仅用户体验需要Progressive Enhancement，技术领域同样也需要Progressive Enhancement。如果说你不能肯定用户一定满意你的DesktopStyle，那么同样的，你也无法肯定用户的硬件环境就一定能够接受AjaxRIA（带宽、客户机浏览器环境、客户机性能等等都有很大的不确定性）。因此，仅仅高姿态的将自己的应用定义为AjaxRIA是一种冒险行为。 综上，我非常赞成LZ的想法——因为我也是这样想的，只是对于Progressive Enhancement，我小小的补充了一下，呵呵。 很赞同你的观点，将Ajax Framework与Flex这类框架区分开是有必要的。今天早上我还在想，所谓的RIA，已经完全脱离了标准的HTML等技术，其运行的宿主也由浏览器迁移到了运行于但不仅限于浏览器之上的VM，现在RIA运行于浏览器之中并不是必须的。所以，利用HTML技术来实现完全的RIA是否是正确的做法，是值得商榷的。 |
| 返回顶楼 | |
|
发表时间：2007-12-26
air已经是这样做，号称是可利用当前的HTML/CSS/JS技术。迁移到桌面程序的级别来。
|
| 返回顶楼 | |
