goldrain

决定做进：局部页面的引用，以支持局部刷新 cancel 使用include页面做

写点未细化的框架代码还是很有意思的

使用mock进行开发的一个好处：
更加支持并发开发
如直接进行数据库开发，则查询可能因为数据库没记录而查不出数据，分页效果什么的都看不到了。

弹出框还是少用为好，web交互的特征就是少弹出。
使用出部分页面
和返回url，
取代弹出框

都在主页面交互，至少便于调试，能看到源代码。

弹出框还是只适合做选择记录用：选一条或选多条。

joachimz Says:

June 25th, 2004 at 9:00 am
嗯，我们就是这么做的！因为一个企业的组织架构很容易变动，而且实际操作中普遍存在斑竹提到的兼职或者说借用行为(也就是员工的工作内容可以不依赖组织机构)，因此权限必须与组织隔离，才能各种应对变化。但同时这会带来另外一个问题：维护过于繁琐和易于混淆。因此在设计的开始就应该好好考虑维护问题。

berg Says:

August 2nd, 2004 at 2:53 pm
**例如，一些系统把Role和Group合并在一起，使得Role具有层次性。
这也同样可行。有时候甚至比分开更方便。
–我们就是样做的，没有group，只有role，role是层次的继承的，下层继承上层的所有权限和属性，我们感觉这种树形更符合物理世界中的情形。user只能对应树一个分支中一个role，如：
　员工
　　销售部员工
　　　销售部经理
　　采购部员工
　供应商
　　如一个user是销售部经理，那么他有所有上级role的权限，不在一个分支中时，一个user可对应多个role，如此人还可以是供应商。
　　这种方式，赋权限简单，与组织机构完全不相干

冰云 Says:

August 2nd, 2004 at 10:20 pm
说的好，实际上RBAC推荐模型就是H-Role的，没有Group概念。

组织机构与组
在系统中，有些类似的概念。
例如，对于一个单位，有组织机构，有员工。
每个员工都是个用户。

对这样的系统，如何设计建模呢？
以下是我的想法。欢迎指教。


明显的，需要对不同的人进行授权。
前面写了RBAC，这就是对授权的解决方案。

RBAC中有Group的概念，User属于Group，
那么Group和组织机构有什么关系呢？

可以这么认为，由于组织机构本身是物理的，客观存在的
而权限是人为制造的，具有变化性。
因此，为了把组织机构与Role相联系，与权限解除耦合，
就采用Group的方式。每个组织机构单位对应一个Group
但是Group未必对应一个组织机构。

例如，某处有2个副处长，其职能是一样的。
因此可以有个Group对应处，有个Group对应该处的副处长。
副处长Group.getParentGroup()==处Group

组织机构的设计，当然是Party模式。
Party包括Organization和Person，其中Person对应于User
Organization对应到Group。在建立组织机构的过程中，
自动建立对应的Group。

Party和Actor有一定的关系，但是不完全对应。
每个人（Person），即登陆系统的用户，对应于一个用户（User）
因此，User与Person是one-to-one关系。

这样，从概念上区分物理存在的组织机构和逻辑存在的权限，
就可以把这机构和权限清晰的表述出来。

当然，在一些不复杂的系统中，可以考虑合并某些项目。
例如，一些系统把Role和Group合并在一起，使得Role具有层次性。
这也同样可行。有时候甚至比分开更方便。
有时候有的系统为了简便，去掉了Group的设计并代之以部门（Department）

我不赞成这种设计。Role的作用是隔离权限和用户/组。
Group是Actor实际上也扮演了某个Role。
如果去掉了Group，让Role里面包括了组织机构信息，
那这个Role的复用性就降低了。系统的授权也会更麻烦。
例如，一个Role名称为文章发布员，如果与某个Group合并，
可能会成为：A部门成员，都可以发布文章。
那么，一旦我需要别的部门的人拥有发布文章权限，
难道要让这个外人属于这个部门？

在我们公司某个系统中，现在有同一系统不同子公司间通讯的需求。
客户要求可以具体到让其他公司的某个部门看到某些文章。

实际上这是对该部门对应的Group来进行授权的过程。
权限不应该直接授予到该组织机构。而是这个Group应该获得读取文章者这个角色。

Thursday, June 24th, 2004 11:43 pm, Modeling 建模
RSS 2.0 , You can skip to the end and leave a response. Pinging is currently not allowed.

组织机构与组
Thursday, June 24th, 2004
在系统中，有些类似的概念。
例如，对于一个单位，有组织机构，有员工。
每个员工都是个用户。

对这样的系统，如何设计建模呢？
以下是我的想法。欢迎指教。

明显的，需要对不同的人进行授权。前面写了RBAC，这就是对授权的解决方案。RBAC中有Group的概念，User属于Group，那么Group和组织机构有什么关系呢？可以这么认为，由于组织机构本身是物理的，客观存在的而权限是人为制造的，具有变化性。因此，为了把组织机构与Role相联系，与权限解除耦合，就采用Group的方式。每个组织机构单位对应一个Group但是Group未必对应一个组织机构。例如，某处有2个副处长，其职能是一样的。因此可以有个Group对应处，有个Group对应该处的副处长。副处长Group.getParentGroup()==处Group组织机构的设计，当然是Party模式。Party包括Organization和Person，其中Person对应于UserOrganization对应到Group。在建立组织机构的过程中，自动建立对应的Group。Party和Actor有一定的关系，但是不完全对应。每个人（Person），即登陆系统的用户，对应于一个用户（User）因此，User与Person是one-to-one关系。这样，从概念上区分物理存在的组织机构和逻辑存在的权限，就可以把这机构和权限清晰的表述出来。当然，在一些不复杂的系统中，可以考虑合并某些项目。例如，一些系统把Role和Group合并在一起，使得Role具有层次性。这也同样可行。有时候甚至比分开更方便。有时候有的系统为了简便，去掉了Group的设计并代之以部门（Department）我不赞成这种设计。Role的作用是隔离权限和用户/组。Group是Actor实际上也扮演了某个Role。如果去掉了Group，让Role里面包括了组织机构信息，那这个Role的复用性就降低了。系统的授权也会更麻烦。例如，一个Role名称为文章发布员，如果与某个Group合并，可能会成为：A部门成员，都可以发布文章。那么，一旦我需要别的部门的人拥有发布文章权限，难道要让这个外人属于这个部门？在我们公司某个系统中，现在有同一系统不同子公司间通讯的需求。客户要求可以具体到让其他公司的某个部门看到某些文章。实际上这是对该部门对应的Group来进行授权的过程。权限不应该直接授予到该组织机构。而是这个Group应该获得读取文章者这个角色。

还要加上委托客户：网上下单

用户账号也被停用，但其party信息还在db中，
账号也可以给别人用，当然账号对应的party就要修改了
party的父能否修改？主要考虑其维护的记录的归属也要被修改
从软件功能上，要提供
从管理经验上，建议不要修改，人员部门调动可以这么做，
在源部门禁用，在新部门添加。

看来从树选择一个party的弹出框还是要做的

考虑这么几种情况引起的记录归属问题：
部门变动
人员变动

不要做移除操作：对已选出的权限，只有保存操作

这样两个界面都是用选中来识别父。这样比较一致了。
要移除也很简单，取消选中一项即可。
于是复制也比较一致了：xmlnode到treenode
这样也好，毕竟移出的效果原来也没出来，左边一直是全部。

对树的处理：
XmlNode：DTO
XTreeNode:view层的结构

xmlnode到treenode的复制：
.全部节点复制
.list中有的节点才复制
.针对有子没有父的情况：子也要显示出来的
.针对叶子才记录的情况

大致这么做：模块权限和记录权限一致对待
对模块权限：
目录也有id，只是目录id虽然记录下来但不用于定义模块；
（做个样子而已，用于全选，全不选子用）
移除操作要求：开始不选中所有

对记录权限：
父子id都有用，父id往往用作超级权限。
所以右边的选择框必须用选中来区分其权限。
移除操作就很危险了，建议对移除操作做个警告，
不过记录权限往往比较少

矛盾是：两种权限操作界面不一致了。
怎么做才能一致起来？

service的权限配置在通过serviceModules.xml将service和module关联来实现，
module是模块权限的最小粒度，用户只要拥有service关联的一个模块权限即可访问该service.原因很简单，用户既然有模块访问权限，自然不应对在该模块内的可能有的多个必要的操作service做限制。
而没有配置关联模块或配置了service但关联模块数为0的service认为不做权限要求，可自由访问。

分页的效果要做好点 (OK)

看来您学过编译原理罗，所以要让编译器将文本：
String a = map.get("str");
识别为文本：
String a = (String)map.get("str");
在你就是不可实现的了？
编译原理果然深奥！

我使用什么语言不用你操心，
什么时候出来个强类型编译期语言，
但程序写起来简洁方便，我会考虑彻底放弃java的。

无法在网络其他机器登录访问xp机器

在共享里要安装一下

xp上安装了sql server其他机器无法访问

给sql 2000打了个sp3补丁就解决了

呵呵，别人看不到了

弹出小框可以指定位置

menu.html中main_frame当要往下的滚动条时界面变得不好看了
修改：要滚动也只有frame里面的滚动

提供当前页的button，可以刷新当前页

查询中的新增，更新都用弹出窗口做。

模块就是独立的模块，不要考虑跳转的问题，
考虑了跳转就导致模块间的耦合
比如新增完后跳到哪里，更新完后跳到哪里
模块做完后都到模块入口
比如新增完后就让操作者继续新增...

这样做的好处是，模块入口可单独的放到菜单
也可被其他模块引用（一般是弹出框中）

感觉费用制作里面的单条记录维护还是使用弹出对话框比较好。
在同一页面上操作也可适当使用，比如联系人，文件跟踪等
特征是：这种页面下面的空白会比较多。而如果本就会占满页面的内容就建议用弹出框来做了。
弹出对话框里再弹出也可以接受，注意控制弹出大小和位置以免完全挡住原来的对话框就可以。

所以对单表维护也倾向使用弹出框，因为查询界面往往要占满整个页面。

菜单
模块权限

客户查询选择做好

把港口查询选择做出来

查询使用session保持状态只在模块入口点可以这么做
主要是用来保持进入操作后返回能保持查询条件和page
而不是用于分页的需要，每次分页仍需要提交其他查询条件

在模块中的查询一般是弹出查询选择记录，则不要使用session保持任何信息。

面对部分页面刷新的需求，可否使用ignore标识的块，把这些块一起存放到模版里。
方便起见，再给eastm加个block标签，标示部分块。
这两种标签中的模版都可以在页面部分刷新时被调用。

发票，账单中都有对费用的查询和选择
考虑对费用的操作做成一个公用模块。

出账单新流程：
单个账单维护页面在主页面(session维护的component，一次提交)
选取费用在弹出框
选取费用中可能会有选取客户，再弹出框

账单对应结算单位一般与费用中的结算对象相符
即所有费用一般为同一个结算对象

特殊情况是：
一个账单多条费用可以有不同的结算对象。
A公司替B公司买单也可以理解，可能A,B公司有一定的关系。

出账单流程：
.选择结算对象（一个账单只能对应一个结算对象）
可通过工作号，客户查询等找到结算对象
.对结算对象查询其所有费用
.选中费用生成账单（应收应付账单）

代理账单和退佣账单如何做

在工作号内不出账单？
或可出账单，但只限于当前工作号产生的费用。
不能选取其他工作号中的费用?
从数据看，账单号不只与结算单位对应。
还和工作号（或总单号）有关联
所以目前软件的工作方式还是合理的？
即以当前工作号和当前结算单位为主
也可以容许有多种操作方式：
比如操作其他工作号，甚至是其他对象的费用。
但账单一定要和工作号关联么？
如果没有工作号入口，就不能生成账单么？

可否将所有出帐都放到账单模块做
而在总单，分单等模块，只能制作费用，查询出帐

费用要审核

制作账单的话，
既然是对一个公司，应收应付应该可以做在一起？

总单费用是与航空公司结算的

分单费用是和委托客户结算的

1, 使用java提供的方法，在ｊｓｐ或者servlet中都可以
<%
response.setHeader("Pragma","No-cache");
response.setHeader("Cache-Control","no-cache");
response.setDateHeader("Expires", 0);
%>
2, 使用HTML标记，如下面：
<HEAD>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="0">
</HEAD>

xmlhttp get出部分页面时常有页面不刷新的现象，调试时要让它刷新只能通过变换url,
看是否有解决的方法
比如在head里面设置nocach等 a href="#" onclick="addEntry();return false;" 把return false;去掉后解决了。

为有效减少dto数量：
新增dto，update dto,query dto可以考虑合并。
一些字段在新增更新里可能是code
在查询里却可以是name.

part页面的定位：
底部？
点击处？

服务器3：
cvs
开发效果展示。

更好的方案：
需要的话，tabs所有内容一次带出，tab切换就不用刷后台了。
零碎的交互也只是刷部分页面：粒度可定为一个tab所对应的整个部分页面，对tab内再细分的话可能太细了。
后台会有部分重复代码，比如刷tab part和刷整个页面中会有重复部分。
对部分页面，可以模版公用一个。 -------- nonono 如果刷新粒度定位为tab，还不如一个tab做成一个page，不要把把tab做进一个页面了。 不要把交互搞得太复杂，web不能等同于c/s开发，xmlhttp也只能起到一个增强交互的作用。 对部分页面的刷新工作还是暂时不要做为好，部分页面暂时只能用在单条记录的维护上面。 更复杂的交互还是用web开发的方式思考问题： .界面切换 .弹出框选择

>做梦啊, 编译器怎么知道obj0原来是MyClass, 强类型就是安全.
又要简单又要安全,有这种事吗?? 你当做java的是白痴啊.
他们不知道
MyClass myobj = obj0: 这样方便啊.

简单就不安全？安全就不简单？ 编译器怎么就不能从下面这句话判断obj0是MyClass的？
MyClass myobj = obj0:

做java的不是白痴，白痴还没能力把一门语言越搞越复杂。 做java的是一群自以为是的天才。

query使用innerHTML也可以实现局部更新
不过必要性不是很大，query往往要求对选中记录进入操作，
操作返回后还能刷新原query分页所在页面，所以用session保持这些信息就不可避免...

使用xmlhttp更新数据后都用get刷新
get一般是获得整个交互页面的数据
能否考虑刷新部分页面。

对界面雷同的数据维护，比如一条单表记录的新增，更新，做到一个html模版中去。
一个action，两个view.java，一个html模版 为了维护一个单表做三个界面实在不值的。 而使用include又使模版支离破碎。 当然新增和更新界面相差太多，比如更新有tab而新增没有得情况，还是要分别实现。

弹出对话框适合做什么？
觉得只适合做选择，尽量避免在弹出框做输入。
因为如果输入框又要求弹出，则是两次弹出框了。

对阿，我要的还是强类型，但写法要简单点嘛。

>例如流行的 hibernate
MYClass obj=(MYClass)session.get(MYClass.class,"myid");
應用泛型後
MYClass obj=session.get(MYClass.class,"myid");

这还不是我理想的java，只要是Object赋值，都要可以：
MyClass myobj = obj0:
而
MyClass myobj = (MyClass)obj0;则是编译器的事。

>理論上沒全沒有問題(現實更是不會發生)
而且 sun 都說了 package name 只用 lowercase
Class name 是 Capital letter


import无谓的多出个static，你说复杂了还是简单了？
既然包，类可以直接import，为什么静态成员不能一视同仁？
我也支持import常量，但应该是一样的写法

>而且面對任何重復名字, 都是用 FullQualifiedName 來解決的吧~?
“我倒覺得sun應該在java規範裡限制包名和類名重複”，我指的是语法规范，同一个包下的类名包名重复则编译不过，这才是sun要做的！
import加个static只能是属于令人恶心的修修补补，让java语言越来越丑陋！

〉〉〉goldrain只是在钻牛角尖而已。
呵呵，关于map不是我在钻牛角尖，我怕sun会钻。越钻越复杂。

泛型需要时可以用，也可以不用，我没意见；

我对强类型编译语言的立场也很明确：支持。

我只是觉得java在变得强大而复杂，而不是强大而且简单。
复杂的语言不会给开发带来好的体验。

为什么不用汇编而用c?不用c而用java?甚至不用java而用脚本python?说到底，还是一个简单与否的问题,是编码体验的问题。
而java显然走的是复杂路线，而且是越来越复杂，我觉得这么走下去，早晚要被抛弃！