本文共 3107 字,大约阅读时间需要 10 分钟。
刚刚说道了这么一件事情,就是,上面设计的表并不是一个engine中解析时候用的分析对照表,而是一个engine用于生成时候的表。那么,现在我们来大概设计一个这个分析表吧。
分析表有那些呢?
最基本的component表,可以叫做为base_component表。
这个表包含了很多lv1的component。其实,也就是一个engine可以支持的表,1个column就可以啦。
类型 |
Button |
Frame |
Panel |
。。。 |
表格大概就是这个样子的。
然后呢,就要涉及到一个complex的component的表了。
这个表可以叫做complex_component表。
这个表除了包含一个type以外,还要一个叫做related的东西,也就是说,这个component是由什么东西构成的,那些basic component来拼成的,然后根据这些信息,组成这个type的关系网。
类型 | 关联 |
Tree | Textfield, button, list, link…. |
… | … |
因为组件还没要求复杂到这种程度,所以可以考虑的就是,先做这两个component的分析表。
好的,下面是attribute表。
Attribute表啊,也是2种,为的是更好的继承性。不过这就需要更多的分析了。
每一个component都有自己的attributes,那么很多component的attributes也是有交集的。比如说,button中有value,textfield中也有value,只不过在解析的时候,button被解析为一个复杂容器,textfield被解析为一个单一容器。Value也被放置在了不同的地方,但是他们都是有相同的attribute。这样的话,attribute表就不是那么简单的去做了。
Hint:
这里的attribute表是css的attribute。请注意!
这里有一个小方案:
首先,抽象出lv1中所有的components 的attribute,将相同的attribute放置在一个table中。
比如这个attribute表,叫做,basic_attribute表。
属性 |
Text-align |
position |
font |
。。。。 |
然后,根据每个component的不同,找到他们不同的attribute:
比如说是frame的:
Frame |
z-index |
Top |
… |
而这个属性,对于button来说是没有用处的,因为在这里,button仅仅需要的是一个绝对的相对container的定位。不尝试能够实现drag and drop 这个功能。
那么,在查表的时候,首先查得是这个basic的表,然后再根据type来查看相应type的表。
这样做的好处就是在于,如果有update,upgrade或者新的component加进来,仅仅需要的是CRUD,而不是需要再次update所有的表,从而避免了产生大量的资源waste以及冗余。
这两个表的关联就是通过解析器来完成的,因此在解析的过程中会在意到一定的顺序问题,这个也是需要考虑的,如果暂时不考虑一些其他的性能问题。
Ok睡了一觉,继续写到下班吧。
下面是关于特定的一些component的设计了。那些该有的我就直接在这里写,然后特殊的一些我标记出来,另外写过的我就不再做声明了。
Button
按钮,这里的这个按钮应该是两种,一种是普通的无逻辑按钮,一种是有逻辑的按钮,比如reset以及submit。所以说,在解析的时候,或者说在制定 GUIXML for HTML 标准的时候应该考虑到在button中增加一个attribute。比如说叫做buttonType。那么,当buttonType为默认或者为button的时候,那么就生成<button>标签代码,如果说是reset或者submit的时候就去生成<input>代码,并且给input的type指定类型。在不考虑是否存在event表的情况下,可以按照这种方式进行相应的解析。
Button本身还有一些attribute,不过这些attribute不是很special,比如说可以制定button的color,text-align等等这一类的属性。也就是说,是一个静态或者动态的样式。这里就不再说了。
Button如果是有事件的话,应该是集中于button中的那个onclick事件了。至于如何去实现这一个方面的东西,暂时还没有考虑到。
Hint:
对,另外在解析中,每一个component的名称将作为这个tag的id存放起来。这里说明一下。
说完button下面说一下textfield
Textfield
Textfield存在的目的就不说什么了,那么,对于textfield有这么几个attribute可以进行考虑。
比如说,text-overflow(IE6+),text-justify,等等,还有一些就是font啊,color啊什么的。
这些属性up2 basic attribute中的一些。不过,有关Text Property 中的一些可以尝试在规范中实现。
对于textfield不得不要考虑的就是他的event。因为,textfield是用户交互的一个重要的interface之一。Textfield接受用户的输入,在根据用户的输入情况对这些logic进行分析,最后反馈给用户。整个的数据流就是这样的处理。那么,逻辑的部分也就是他的event了。
包括button,还有一个要注意的就是他们的position。
在JavaSE 中, position在一种特定的情况下是可以绝对定位的,这种方法似乎在html情况下之后配合着div来进行绝对的这种定位。所以需要考虑的是,是否实现这种positioning。
Label
这个东西,存在的意义很特殊,因为,如果说不将这个部分标记为label,仅仅采用普通的html,也是可以达到相同的目的的。Label这个tag从属于form标签。可以被IE解释,似乎也可以被Firfox等其他浏览器解释,但是唯一不清楚的就是,真的解释了么。因为根本看不出来。。
Label同样有他自己的ID等等,其实,这样也体现出了label和普通的html文本不同的地方。Label相当于是一个container,这个container中包含了一些txt。整体的txt,也就是value是可以改变的,而不用在乎label的其他的attribute。这个可以算是label这个tag的一个重要的存在意义吧。可能需要尝试一下,用javascript写一段代码,比较用innerHTML和直接更改label的value属性的区别。
这个标签在这里就有很强的一个位置观念了。也就是说label,你要考虑到是否他需要一个position,按理来说,label是可以满处乱飘的,当然了,在frame这个框架之内。所以,可能会尝试给label装上div,如果label这个本身的container不支持position。当然那,这个也是后话了。
Passwordfield
密码框。密码框直接被识别为<input type=”password” id=xxx name=xxx/>就可以了。虽然说,css支持password的字体样式,可是啊,在IE,firefox,甚至是safari中就是一堆的点点或者是一堆的小星星,你说要字体干什么用。。可能会涉及到一些密码框的样式问题,那就是css上的border问题了,跟text问题没啥关系的说。
转载地址:http://aenpi.baihongyu.com/