毕业设计的设计部分笔记2

刚刚说道了这么一件事情，就是，上面设计的表并不是一个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问题没啥关系的说。