| 晓鸥 的个人资料Single Running照片日志列表 |  工具  帮助 |
|
|
9月21日 关系子项的处理一个类/表/实体，一定会对应若干相关关系项目。 比如：订单和订单物料行，这里就存在一个关系，订单和物料列表之间的关系。 事实上，经常会出现类似的需求。
一艘船舶，在海事管理中，通常有很多单据，记录与之相关。而这些相关的信息，都是在元知识中已经设定了关系的。 我们通过的元知识的关系解析，了解到船舶这个信息实体，对应有多少个其他实体与之有关系，一艘船舶又可以获得多少的相关信息。 通过在主界面中，增加一个TabPanel的方式，将相关信息进行展示。 1、需要获取元知识中关系对象列表，我通过编写asp代码，很方便的获得了元知识关系列表 2、客户端，进行对元知识的解析，通过一个for循环，依次生成grid，在这个工作之前，extend一个grid类，专门用于处理我们as matrix对应的grid，输入元知识对象code，即可生成对应的grid对象。通过对as_grid的处理。 3、编写listener，针对各类操作进行数据的load。grid.getStore().load({params:{…}})，这个方法的需求，需要我们输入一个keyValue进行数据过滤，保证grid中的数据一定是更当前main中选择的数据对象相关。 ==================================================== 问题： 1、派生的各个类尚不够强大，需要精细化工作； 2、各个界面元素之间有相关影响，应该进行完整的界面规划，消除各个element之间的不兼容； -------- 需要全面的界面重新布局和设计，派生出各个类，以更加有效的下一步工作。 9月11日 找出App_Func模块不能被载入数据问题对Web2.0中关于grid改造之后，发现大部分的类都可以顺利加载数据，就是一个不行。 很奇怪，我找了半天，也没有发现问题在哪里。经过思考，基本排除了客户端的问题，于是就是服务端的情况啦。 可惜，我发现服务端同样返回数据，可为什么没有反应呢。 在store.load中添加了listener，结果发现，每次当遇到几个数据行被response之后，load就是没有执行。 在详细查看了网上的高手文章：http://javahappy.blog.hexun.com/33514736_d.html 发现，可能是response的JSON格式不对，于是我通过firebug获得的response数据，复制到http://www.jslint.com/ 进行检查，终于发现，原来是note字段中，存在回车字符，而在asp端根本没有做任何的处理，导致的结果就是response的字符串直接被回车掉了，于是不符合JSON规范。 后来的解决方法就是在asp中增加对回车等各类特殊字符的转义方法，后面就顺其自然了。 不过通过这次事情，再次发现编码过程中，程序必须有针对exception的代码，以及是发现错误。 现在，grid中增加了load exception的listener，以后再有数据load失败，就可以及时发现了。 这里要感谢高手liyanqing_01的博客中记录的分析方法，很受用。 然后还需要对java script代码进行全面的检查。尽可能进行派生工作，下一步也是重点，就是完成子项列表界面，即可完成初步的Web2.0版本。 9月2日 嵌套panel中遇到的妖问题今天终于搞清楚了Ext中panel嵌套遇到的问题。 以前在border布局后，无法add一个query form，原因是我采用的form.id = code + ‘_query’，现在发现，Ext目前对’_’的解析有问题，如果我修改成form.id = code + ‘-query’，问题马上解决。 8月26日 为grid增加分页comboBoxgrid的分页已经完成了，那么分页的选择也需要提供。 首先定义了一个comboBox，然后为这个comboBox加载固定的store，就是基本的“10，20，30，50，100” 估计是应该满足日常用户的需要了吧。 然后根据用户选择的结果，更新grid的分页。 一开始还以为pageToolBar的pageSize属性是只读的，经过尝试以及在网络上查找信息，才知道是读写的，是public的属性。Ext有时候API写的太简单了。 -------------------------------------------------------- 然后就简单了，通过监听comboBox的select事件，进行修改grid的bbar中的pageSize属性，同时修改load中的参数，这样就可以确保没有问题啦。 当然还没有具体测试，可能还有小问题。
然后选择20页，就可以看到grid的pagetoolbar的相关信息也会改变。
可以看到页数从3变成2了。挺好的，只是翻页还没有测试。 ------------------------------------------------------------------------------------ 8月25日 grid的分页处理网络上有很多的grid分页处理，我参考了很多。 基本上都是先取数，然后指定页大小。 分页的数据整理各有千秋，我最后还是决定在SQL server上分页，也就是说asp端传输一个sql语句，查询出分页的结果。 分页的算法很简单： select TOP @pageSize [fields list…] from @tabName where [conditions..] and ID not in (select TOP @pageSize*(@pageIndex-1) ID where [conditions…] order by ID) order by ID --------------------------------------------- 听说这个是效率很好的算法，很多人都是制作存储过程的。不过由于我们平台的特点，还是在ASP上制作可执行的sql语句更加实际。因为元知识提供了基本的select语句，只需要稍微的修正一下，就可以满足算法。 当然，测试算法是个很要命的过程，通过无数的response.write，我终于测试通过了算法改变后的结果。
response的大概结果就是这样啦，可以看到，实际上外键的足够丰富，会导致改写分页算法很郁闷的。 ---------------------------------------------------------------------------------- 这里需要一个特别注意的地方，Ext的pageToolbar中显示一共多少页，是通过response返回的JSON对象中，指定record count的结果。这个结果是在定义Ext store的时候，JSONreader分析出来的。由于pageToolbar是和store绑定的，因此可以肯定分页工具的很多参数是依靠store的。 因此，我不得不在服务器上多执行一次sql，为的就是不分页的情况下，能够select count（id）from tabName where….. 不过还好，效率低了，但是更加契合我们的平台才是重要的。 ------------------------------------------------------------------------------------ 然后就是通过pagetoolbar中post的参数：start，limit来进行分页的计算。 计算出pageSize=request("limit“)，至于pageIndex也很简单，我每次都是初始start=0，因此只需要加法除法即可。善用asp的FIX()函数即可。
================================================ 最后，需要在store中添加一个监听，每次load之前，需要预先准备查询条件，否则在Ext下，pageToolBar只会post两个分页参数：start和limit，而先前查询条件就没有了。 这里需要用到store的 -------------------- 由于以前已经把grid进行了个性化派生，因此现在就很简单，只需要增加一个方法，返回当前form中的数据，进行对象化，然后返回即可。 然后就是定义store的事件：
于是就可以达到如下效果：
------------------------------------------------------------------------------ 通过测试，基本可以使用，每次都会提交查询条件。 ASP端也进行了相关改造，适应分页。 由于实际调查发现，用户并不喜欢或者没有意识到每次查询后都填写分页的页大小。 因此打算取消query中的页大小textField，而在grid中进行改造，让pageToolBar可以修改页大小。这样才是合理或者更加简单的做法。 因此用户不喜欢，也不理解页大小的概念，还不如默认多少，然后有层次的用户可以在grid中进行修改实际显示的页大小。 因为form中经常或者必须的才需要，否则就不应该安排在form中，减少form的item数，其实就是让用户有更加简洁，容易操作的视觉感官。
8月13日 grid改进2越来越进入状态了，我感觉很好。在grid上增加了删除功能，以及提供了刷新数据的功能。
保存后，我们去查询一下数据吧。
在grid中，罗列出来。 选择一行，也就是我们刚才输入的，再点击删除。 提交到asp端，通过pk value的传递，可以进行删除数据的操作。一句简单的sql 语句就可以完成。 --------------------------------------------------------------------------------------------------- 现在需要对form中的数据进行删除工作。自然，相对来说简单多了。 只需要再次传递pk value值就可以实现。 由于自己派生了一个form，因此有一个自主属性pkField，因此获得pk value变的很容易啦。 ----------------------------------------------------------------------------------------------------- 最后，在ajax响应之后，通过判断，如果确认成功，那么需要刷新grid数据，以及关闭content form。 修正grid的选择模式本来最初的设计中，采用简单的rowSelect模式，也就是说，选择一行，就是一行。 今天重新下一步开发delete的过程中，参考一些案例，发现还是使用checkBoxSelectionModel更合适一些。 效果：
------------------------------------------------------------------ 同时修改event：rowdbClick，当一行数据被选择后，如果是双击，那么弹出content form 界面，form嵌入到一个web Windows中。 通过简单的设计，就可以轻松获得当前行所在的record，通过的数据record的load，那么form就可以轻松加载数据啦。这个网络上有很多案例可以参考。 -------------------------------------------------------------------- 为了给删除工作准备，首先搞定grid中的topBar，增加一些选择相关的按钮，这些按钮可以对数据行进行选择的操作，基本来说需要：[全选，取消选择，反向选择，查看选择记录的详细内容，删除选择的数据] 全选和取消选择都比较简单处理，直接使用selectionMedol中的方法：selectAll和clearSelections. 反向选择就比较搞，不过也不难，就是分部走 先全选，然后根据选择的行，一次取消选择即可。 至于这样的效率如何，我就不敢说了，目前还没有进行数据测试，功能实现是第一目标。 另外还需要对数据进行分页处理，毕竟Web上还是需要效率的，不像C/S上那样，所有数据全部堆出来，也问题不大。 查看功能比较简单，直接获得当前selectedRow的record对象，然后调用contentForm就可以啦。 ---------------------------------------------------------------------- 接下来就是搞删除功能了。 获得选择的数据，然后提交ID_array，应该可以轻松的进行删除工作。
8月12日 修正grid的选择模式本来最初的设计中，采用简单的rowSelect模式，也就是说，选择一行，就是一行。 今天重新下一步开发delete的过程中，参考一些案例，发现还是使用checkBoxSelectionModel更合适一些。 效果：
------------------------------------------------------------------ 同时修改event：rowdbClick，当一行数据被选择后，如果是双击，那么弹出content form 界面，form嵌入到一个web Windows中。 通过简单的设计，就可以轻松获得当前行所在的record，通过的数据record的load，那么form就可以轻松加载数据啦。这个网络上有很多案例可以参考。 8月10日 form功能添加经过一周的工作，基本完成了asp服务端的代码，使得web2.0中提供了保存数据的功能。 通过的form表单中PK字段的检查，确认是insert或update语句，然后编辑sql语句，最后使用ado命令进行sql语句的执行。 将返回的结果回覆到前端，extjs就可以根据成功或失败的json字符串进行用户提示。
基本布局没有改变，争取后续工作是根据group的元知识，进行fieldset布局处理。 点击保存按钮， 根据返回值，获得用户提示，这样比较自然直观。 技术方案很简单，就是折腾Ext的post参数有点累。asp方面还是依旧的稳定。 ------------------------------------------------------------- 另外，顺手做了一个和C/S部分一样的view/edit切换按钮。当form中的fieldset处于edit状态，提示“查看”，点击后使得fieldset变成disable状态，否则相反处理。将来可以和权限等相关功能对接。 下一步就是删除的操作了。嘿嘿，争取本周基本完成吧。 3月6日 使用cookies完成last page记忆通常，需要对最后一次操作的页面进行记忆，下次再登录的时候，可以直接使用。 所以我们一般都是用cookies技术完成这样的记忆工作。 今天对ext的cookies组件进行了测试，并让系统可以给客户的添加一个cookies记录，记录当前的actTab的信息。 如果再次登陆，则系统自动将上次激活的页面load进来，方便用户操作。 如果cookies完成测试，那么结果可想而知，我们可以一次性load元知识，这样在一次会话中元知识始终在客户端作为json对象存储，效率可想而知了。 --------------------------------------------------------------------------------------------------------
第二步骤就是每次激活一个Tab之后，将当前被激活的Tab元知识信息保存到cookie中。
最后，我们在声明对象之后，加载已经保存到本地的Tab。十分的方便自在。 这里需要说明的是，cookie控制器必须在onReady中声明。 ------------------------------------------------------------------------------------------------------------ 2月26日 修正datetime控件，增加new功能主要完成了new功能的添加，包括工具栏的新建功能，以及content界面中的new按钮 1、对于工具栏，设计思想主要为用户的快捷工作提供便利。用户通常启动一个功能后，最直接的工作就是添加新的记录，因此添加一个new按钮很有必要。主要的handle方法为启动content界面，然后初始化数据。 整体的效果就是这样啦，点击新建，出行content，如果工具中的按钮已经通过开发测试，则caption改成中文，这样也可以提醒自己还有什么没有开发完毕。 看看content的细节：
上面也有一个tool bar，也提供了新建按钮。 这个新建按钮的工作也一样，可以初始化界面。 并且把默认值：激活填写。 ----------------------------------------------------------------------------------- 下一步是开发save功能，保存到数据库很重要，得好好想想。 必须有一些可配置的余地，并且严格按照元知识进行，不能独立在界面上。 元知识如果是保存到access那就保存到那里，界面要纯洁，与数据，与业务都无关，与界面知识有关。 ----------------------------------------------------------------------------------- 另外，通过调整测试，发现原来日期时间控件的宽度设置问题，主要是布局的设置问题，把ancher属性注释掉就可以控制控件的宽度了。 终于解脱了日期太宽或者时间太宽的问题了。 2月24日 基本界面完成首先修正了列表中的外键字段的caption显示，然后开始进入content的开发工作。 首先做了嵌入到grid之下的做法，但是发现在Ext中，如果panel的border模式layout，则位于center的panel貌似不能折叠（collapse），所以不能完整显示content，如果显示，又过于偏于下部，不美观不说，用户实际操作也不方便。因此考虑到实际操作中，对数据的修改还是集中在屏幕的中间比较好。 所以还是改成别的模式来显示content：
使用一个window嵌入一个panel来显示我们需要的content界面。 通过的全局id的判断，我可以轻易的控制数据的更新。 ------------------------------------------------------------------------------------- 到目前为止，我已经完成了web 2.0的第一期目标中的大部分。 最根本的功能点：导航树、queryform、grid、contentform都完成了。 经过测试，发现Google的chrome浏览器中JS的执行效率中高居首位。 ------------------------------------------------------------------------------------- 好了，接下来就是完善我们的2.0版本。 1、new 2、delete 3、select 4、navigation 2月23日 添加了grid了在tabPanel中，进行了分区 region：west为query from region：center为main panel，今天为main panel添加grid控件。
grid中的数据是通过query form提交后实现的，并且是ajax异步提交。 有时候感觉异步并不是什么好事情，无非就是没有页面刷新罢了。 ----------------------------------------------------------------------------------- 在点击查询后，展开query form部分
输入有关的郁闷参数，于是再点击submit 我修噶了submit的代码，使之可以在成功获取数据后，展开grid部分，并且对grid中的数据进行load操作。
代码十分简单，如果返回数据，这获取queryform的对象，然后收起界面。 再获取grid对象，加载返回的数据对象，于是就可以展现。 ------------------------------------------------------------------------------------ 最最重要的关键，还是全局对象的获取。 由于是单页面的问题，所以全局id的设计很重要。 我采用了metaCode+属性的方式进行编码，这样很明白，也可以做到全局唯一。 ------------------------------------------------------------------------------------ 好了，grid加载成功后，明天的工作就是在main panel中加载content界面的问题。 并且需要实现grid和content的联动数据加载效果。 然后是为content依次添加 new update delete display/edit切换等功能。 至于grid的delete可以延期实现。 这样基本功能实现后，可以逐步进入发布状态。 2.0应该尽快发布，然后再升级完善。 ------------------------------------------------------------------------------------ 在main panel中有grid和form 点击new收起grid 展开form ------------------------------------------------------------------------------------ 发现页面的单次加载效率不高 考虑实现先布局，对于默认需要expand的container进行元知识加载并展示 其他在需要expand的时候再加载元知识，然后dolayout即可。 这样做的好处是页面一次性加载快，但每次功能使用需要再加载元知识，比较郁闷。 2月20日 搞定tabPanel分页今天经过再次代码调整，把原来混合的代码分离为模块。 新增了GetQueryItem的方法，用于根据metaField数组，进行拼装一套适合queryForm的item序列。 经过调整，更加模块化，对EXT使用也更加仅仅限于界面的表现部分。 ------------------------------------------------------------------------------------ 只要对每个内存对象进行唯一的ID编号，就不会发生混乱，和重叠生成的问题。 于是，我就把界面重新布局一下，现在的设计也许更加符合用户使用需求。另外针对EXT字体的问题，从网络上找了帮助，下载了一个新的字体补丁css，使得在FF下浏览，字体也达到了舒服的程度。
tabPanel中分为三个主要模块：queryForm，mainPanel（listGrid和contentForm），relationGrid。 上部为基本常用的toolbar： 查询：handler为打开查询界面； 新建：handler{收起queryForm，收起grid，展开contentForm界面，然后初始化所有默认值等工作}； 子项：handler{收起queryForm，收起grid，展开content，展开relationGridPanel；加载所有子项，并生成所有tabPanel，但不生成relTab中的内容}； ------------------------------------------------------------------------------------- 后续工作： 1、完成在mainPanel中配置grid和content 2、通过查询，将结果集输出到grid 3、生成子项的tabPanel 2月2日 单页面，tabPanel中加载元知识对象生成的界面1、在单击tree的节点； 2、传递元知识对象； 3、根据元知识对象，启动对应的queryFrom界面； 4、激活tab，在tab中load对应的form界面； ----------------------------------------------------------------------------------- 经过一个春节之后，得马上开始Web2.0的开发。由于海事局的事情，着实耽搁了好长的时间。这个时间段导致web开发拖后。 坏：进度一拖再拖； 好：重新回头审视和计划； 不管如何，重新回头看看，重新和过去的自己做交流还是好处很多。 现在必须要解决的功能点分析如下： ！tree和tabPanel的联动； ！单记录的增删改，也就是contentForm中的new，delete，update三个基础方法； ！对存储过程的执行方法，也就是在contentForm中开通button，可以执行对应的存储过程； ！方法界面的设计，单独方法应该有一个methodForm展示，提供输入输出参数，以及执行的button。 由于目前web上的定位，还是基础的数据录入为主，报表查询为主，因此这样的基本功能，必须完成。 通过web应该足够完成基本数据应用，实用性为主。可用性为主。 ----------------------------------------------------------------------------------- 完成tree和tabPanel的联动，至少从形式上，web版本已经达到可以查询数据的效果。也就是达到了web版的基础意义。 点击treeNode之后，传递metaCode的string值，这个是第一步。 我修改了原来的asp，增加了每个leaf节点的metaCode属性。 于是在js代码中，仅仅需要如下的测试，就知道是否可以管用了。
简单吧，还好原来是用派生来的tabPanel，否则今天也就不好玩了哦。增加一个方法，loadForm 参数就是metaCode，嘿嘿。 那么在tree的onClick事件中， 好了，当我做了相关工作，reload页面，点击一个leaf node 可以看到如下效果：
看来获得metaCode已经完成。下面就是根据这个鸟code生成对应的queryForm才是正经活。 ------------------------------------------------------------------------------------ 经过一个下午的折腾，基本搞清楚了布局的问题。 原来Ext中Panel这样的基本容器，对容器内的item是有布局管理控制的方案，布局方案或者叫布局形式如下几种： AnchorLayout, BorderLayout, ColumnLayout, FitLayout, TableLayout 如果没有设定布局，直接在panel中add一个对象，比如formPanel，则该form是不能被布局出来的，必须进行配置。 在tabPanel中，每次Add一个tab其实就是一个容器，该容器应该采用一个布局方案，其中滚边border方案是最常见的，也是唯一目前我测试成功的。 1、p = new Ext.Panel(...,layout:'border',...); 2、p.add(getMetaQueryForm()); 3、tabPanel.add(p); tabPanel.setActive(p); 大体算法就是这样3步骤即可完成我目前的需求：点击tree上一个node，生成一个容器panel，设置为滚边布局模式，然后把读取的查询界面form作为一个item添加到容器中，最后激活这个容器作为tab其中之一。 form本身也是容器，所以form必须在父容器上有个定位，因此form=new Ext.formPanel(...,region:'center',...); 好，到此，基本解决了点击tree后的响应工作。 经过测试，fromPanel可以成功输出，但是如果再次点击其他node，那么node之间存在相互影响。
再点击一个node之后：
如果回头点击上一个tab，则：
一波刚平，一波又起。 估计过去，是因为loadQueryForm的时候，采用全局变量的关系。 明天继续，优化原来的测试代码，实质上应该全部在function内部处理元知识，而不要轻易使用全局变量，太危险了哦。 ------------------------------------------------------------------------------------- 下一步，主要还算梳理模块，重新审视设计一番，将测试代码成熟化，而不是混乱得继续使用。 同时，还要搞清楚其他布局模式的效果。 12月18日 form功能性开发01首先确定form的各种要素： 1、基本按钮的toolbar； 2、根据元知识生成的Content字段数组； -------------------------------------------------------------------------------- 按钮的问题于是就需要设计一下： *新建 *打开 *保存 （后期，可以考虑让用户选择：是否后台保存，如果后台保存，这直接关闭该form） *打印 *查找 *剪切 *复制 *粘贴 *撤销 *刷新 *重复 *删除 *查看/编辑 * ---------------------------------------------------------------------------------- 优先处理如下功能： 1、新建 2、保存 3、删除 4、打开 5、查找 之后，应该实现基本编辑功能： 复制、粘贴、剪切 ---------------------------------------------------------------------------------- 路漫漫～～～ 12月17日 处理FK字段展示这个算是打了个补丁。 今天打算对grid和form做一次测试为增删改做准备。 结果发现外键字段还是很不稳定，主要原因： 1、外键值与外键显示值之间的相互调用； 2、grid对form传递外键值与显示值的问题； 现象就是： 1、当读入的时候，外键显示为显示值，即通过FF_Caption获得的查询结果，通过join表做到； 2、当经过修改后，外键字段向外传递的值，依然还是显示值，始终对于获得外键值不爽； 如果做修改保存，则grid或form中的值必须是外键值，而非显示值，因此必须动手彻底弄清楚。 --------------------------------------------------------------------------------- 后来，我决定还是做一列隐藏的数据列保存外键显示值。也就是说，在查询结果中增加一个字段，将原本外键字段只处理一次，变成了两次。 吐出的JSON字符串为： 'ParentID':'1','ParentID_FF_Caption':'ASIE平台' 通过元知识处理，可以明确知道当前字段是否为外键字段，如果是，则紧跟增加一列外键显示值字段。 于是，在grid所引用的store中，即存在外键值，又存在显示值。这样就不需要再去服务器获得数据了。 然后，在comboBox的fkstore没有load之前，则通过renderer直接返回紧跟在后的显示值，如果一旦load了，则直接根据当前值，去fkstore中匹配显示值。这样，不论grid中的外键字段如何情况，都兼顾了效果与效率。 ---------------------------------------------------------------------------------- 12月3日 查询界面处理2今天处理了bool类别 发现bool类型的字段其实在物理层以及逻辑层均为单一元域，仅仅在查询界面中为了用户方便才分离出2个checkbox。因此，经过讨论，其实可以定义一个界面中使用的域类型（Field Type）来表明该bool类型的field在查询界面中需要分离真/假两个checkbox。 对于目前的元知识结构来说，我对代码稍微的处理一下，即可完成对bool字段的界面处理：
其实很简单，对第二个行，进行字符代换。并且对循环index进行++处理。即可跳过第二个Hi部分。但是，这样是极度不严格也不规范的。因此还是需要进行double Bool类型来支持，以保证引擎的严谨。 ------------------------------------------------------------------------------------ 今天最后发现，对于查询语句中，原来的外键字段均直接使用对应表的AUX字段来代换，因此外键字段中查询中仅仅作为一个TextField，其实作为查询条件的处理，应该一样可以为用户提供comboBox的选择比较妥当。因此需要对外键字段中查询结构中的类型处理进行标识，与编辑模式下一视同仁才好。 最后，经过sql语句的拼接，可以直接执行并获得数据了。还是很顺利的。
通过firebug检查response结果，可以得出一个完整的select语句。复制出来，可以在 服务端目前需要再进一步处理的就是权限的处理。 针对不同的权限，添加where子句来对数据行进行限制。 ------------------------------------------------------------------------------------ 成果页面如下： 12月2日 Query结构的处理1连续2天空闲，做了查询结构的处理。 1、先输出查询值，搞清楚Ext的form的原理和操作。然后制定简单实用的方案； 2、测试一下，在asp中更加form提交的内容，获得value值，然后拼接处理成查询语句；
第一次搞定query按钮，发现会因为没有登录，session为空的情况没有处理，顺手搞了一下服务器返回的内容，于是便有了如下的小东西。虽然搞技术的人觉得没有什么，但是对于用户来说，感觉很重要。其实，小东西也应该养成好习惯才可以。不用中是架构好了，到最后小修小补的，没有意义。
开启sql server的查询器，进行对query的字符串的测试。 1、处理范围查询字段，以及普通字段。 默认情况下，普通字段均是采用模糊查询的机制。 2、日期字段，着需要对字符串进行转换格式才可以提交。 结果如下：
搞了一天，搞清楚日期时间控件的问题，以及修正一个bug。当然，我没有自己研究，是完全请教了原创人的。这里也应该贴个链接： http://www.blogjava.net/alexwan/archive/2008/07/21/216328.html 非常感激这位高手提供的控件，很方便很好用。 另外对于枚举值，能同样获得后台的值，而非界面上的Caption，这个也是研究Ext的HiddenName之后才知道的。看来以后常常去javaeye很有必要。 日期，枚举字段处理完毕后，现在要掉转枪头处理bool以及外键字段了。 11月14日 下一步的开发工作1、子项列表显示： 也就是根据关系组元知识，准备grid，把子项数据store准备好，在点击tab标签的时候，进行store.load()； 2、桥表操作。 桥表有点搞 3、查询结构 4、form提交，增删改 5、tabPanel中独立处理不同模块 |
|
|
