| Powered by: |
 |
| Blog Provider: |  |
| Designed by: |  |
function Save(result,title)
{
if(document.queryCommandEnabled('saveAS'))
{
var para = 'toolbar=0,titlebar=0,menubar=0,resizable=0,Height=7,Width=8,status=0,top=2000,left=2000,scrollbars=0'; win=open('about:blank','',para);
win.charset='GB2312';
win.document.write(result.innerHTML);
win.document.execCommand('SaveAs',true,title + '.xls'); win.close();
}
}
| 面向对象软件开发和过程——优化代码的组织 | |||
相信任何一位程序员都曾经见过面条状的代码，这种代码给人留下的只是噩梦。面向对象能够支持较好的代码组织方式，基本的处理思路是先将问题于分而治之，然后再把分开的代码整合起来。分而治之和整合，成为组织代码的关键思路。 抽象是面向对象中优化代码组织的一个重要的思路。抽象的目标是消除细节，让开发人员的注意力集中在重要的目标之上。抽象的思路在计算机世界中无处不在。TCP协议栈的不同层次都提供一种抽象，对上层隐藏了下层的细节；业务模型也提供了一种抽象，对领域分析人员隐藏了具体技术细节；设计模式同样提供了抽象，它隐藏了具体的实现细节；甚至汇编语言也是一种抽象，它隐藏了机器指令；而我们这里的讨论也是一种抽象，因为我们忽略了应用类型、设计语言这些细节。对于开发人员来说，最重要的是识别出本层次的抽象，应该表现什么，应该隐藏什么。按照抽象的原则进行组织的设计将会是清晰的设计。 抽象的另一个好处是能够便于交流，在设计模式未被提出之前，我们不得不花上大量的时间来澄清设计的思路，但是设计模型的抽象使得我们用一个简单的名词来提到一个设计思路，这就大大提高了沟通的效率。而UML语言的设计目标也是如此。 下面我们提到的一些具体的技术，包括委托、包、分层，他们都在不同的角度体现出了抽象的思路。 1.1 委托 委托是面向对象中最为常用的一种技巧，它是那么的基本，我们在整篇文章中到处可见它的踪影。在一些重要的例子中，我们会指出它的用法，一般的我们就不说了，大家注意些就能够观察到。有人说，用C语言编写代码，代码量超过10000行就会失控，用C++，这个限制可以放宽到100000行。这种说法是否正确我不敢肯定，但有一点是很明确的，面向对象语言要比非面向对象语言更加的结构化，能够支持更大规模的软件。那么，为什么呢？这个问题的答案并不是在面向对象语言本身，而是在其它非软件的学科中。我们知道，在一个小企业中，他没有什么管理成本，管理人员也很少。但是一个大企业，他就有很多的管理人员，因为企业规模增大之后，需要付出管理成本。这些管理人员的主要职责，就是管理那些能够直接产生利益的工作人员。我们还知道，现代社会存在的基础是分工，分工明确，每个人做的事情少而精，这样整个社会就会有效率。而面向对象正体现了这两种思路。首先，一个面向对象的软件，其中一定会有很多什么都不做的代码，只是简单的把对它的调用转给另一个对象的方法，有的有做一些判断，或是类型处理，有的干脆什么都不做。这些代码看起来并不产生效益，甚至有些浪费。但是它们就好像是企业的管理者一样，虽然消耗了一些资源（所幸的是，面向对象语言设计的高效性让这种资源消耗是可接受的），但是它们能够让其它产生效益的代码工作的更加的有效。在后面的例子中，我们会看到很多这样的代码。其次，面向对象非常注重类的职责，每个类处理的事情尽可能的少，每个方法的目标都十分的单一。但是一件事情一定是几个专业的类共同完成的，而不是象传统方法那样，一个函数一包到底。 委托使用的多寡和面向对象语言本身有一定的关系。委托从某个角度来说也可以算是一种重用的技术，在不支持多重继承的语言中，委托将会更为重要一些。而支持多重继承的语言中，从不同的父类继承能够替代一部分的委托使用。如果继承和委托同样都能够实现目标，那么继承要比委托更加简单和直观一些，但是多重继承引入了额外的复杂性。事实上，以Java语言为代表的单根继承的语言，向来都认为委托是比继承更好重用方式。 在软件过程中，通过委托来将代码组织起来是非常普遍的做法。但要注意两点问题。委托给谁，和如何委托。前者说的是调用哪一个方法，后者说的是方法的参数、返回值和异常。两个都是基本问题，但却是最重要也最容易忽略的问题。在异常的案例中，我们知道需要约定异常的处理方式，以及为异常提供文档。委托的使用也是这样，给出类的说明，这样客户端就知道如何使用这个类，统一类接口的设计方法，形成一种约定，即便没有足够的文档也可以保证客户端正确的使用类。相应的，如何委托需要注意的也是类似的问题。这里我们只是简单的提到处理思路，因为后文中还会详细的讨论。 1.2 使用接口来组织代码 继承除了重用之外，另一个用处是定义规范。角色和演员模式中，两个对象职责分离，演员负责实现人在多个环境中恒定不变的特征和行为。而角色用于表现人在不同环境中的不同行为。但是很多时候，为了方便起见，角色也应当能够扮演演员的一部分职责。因此，我们就需要用到委托机制，角色本身并不真正回答问题，而是把问题转交给演员。但是，这样一来，演员和角色之间就缺少了一个规范，那些是演员负责的，那些是角色负责的，没有一个清晰的界定。对客户端也是一件困惑的事情。所以我们最好是为它们定一个规范：
PersonProfile是一个接口，这里之所以采用接口，是因为我们的目标在于定义一个规范，而不是进行代码重用。比起实现继承，接口继承具有更佳的灵活性。定义了这个接口之后，两者的职责就已经非常的明确了。这里使用到委托机制的这些代码都可以算是管理代码，本身并没有太大的价值，它们的管理价值是在客户端体现的。 看到了吗，在实际运用中，一定是多个技法同时使用的。可能有人问，我的设计思路和这不同。这并不是问题的关键，问题的关键在于，我们如何使用这些技法来描述问题、解决问题。在软件开发的过程中，象这种代码级别的规范是必须勤于制定的，因为这种规范往往是客户调用方和代码提供方的一种约定、一种契约。针对这些规范进行工作的衔接、文档的撰写、测试的设计都能够达成事半功倍的效果。久而久之，在软件设计中就能够形成很明显的"块状"的设计和代码，这对软件的质量是很有帮助的。 1.3 包 当早期编写程序的时候，缺少一种对代码的组织技术，因此在大学时代写项目，靠的就是目录结构。在开始设计软件之前，会先在磁盘上建立需要的目录，例如有的目录用于存放全局的函数，有的目录用于存放数据库的DDL文件，有的目录用于存放文档。短短几年后，我们已经不需要使用这么老土的技术了。在现代的语言中，有很多新的机制能够帮助我们更好的组织代码。 我们这里讨论的包主要是对源代码的组织，同时，各种平台中还存在对执行码的组织形式，例如Java平台中的Jar、.Net平台中的程序集。在C++和C#语言中，代码组织形式为命名空间（namespace），在Java语言中，组织形式为包（Package），在Eiffel语言中，组织形式为群集（cluster）。它们产生理由各不相同，命名空间主要解决的是名字冲突的问题，而包提供了一种对类和子包的打包技术，并能够和文件系统优雅的结合，此外，包还提供了额外的可见性（包内可见），群集技术就相对比较松散，它不是Eiffel语言的组织部分，仅仅是对源代码进行打包而已。 包在软件过程中是非常重要的，它是建立统一愿景的重要工具。软件开发的初期，类的设计还不明确，这时候首先确定的就应该是包图。包图不但表现了对业务领域的初步划分，还表现了开发团队以往的经验。 此外，我们知道，类和类之间最重要的就是它们相互作用，形成一个网络。但是当这个网络过于复杂的时候，我们就需要一些办法来组织这张网，使它更加的清晰。包的作用就是对网络进行分块，并降低块和块之间的交互。记得设计模式中的fa?ade模式吗，这个思路是一样的。例如Java中包的成员能够看见彼此之间的保护和私有成员，这种做法就是加强了包内的类之间的耦合度，限制了包间的耦合度。 在前一章中，我们很难为重用来定义规范，因为重用的设计需要对症下药，很难定义一个标准的设计。但是代码组织则不同，可以想出很多代码组织的规范。例如，命名规则、自文档的代码、业务实体的设计规范。代码组织的规范应该从整体开始考虑，这样的效果最为明显。 所以，最佳的规范应该是从分层设计上和包的设计上入手。软件按照什么样的原则进行分层；每一个包的含义是什么，在分层设计中起到什么样的作用；如何保存数据，如何处理数据，如何传递数据，如何表现数据。这些是非常值得，也是非常必须建立规范的。 设计上的规范能够从整体上规范代码，而代码规范能够在细节上规范代码。代码级别的规范有很多，例如sun的网站上就提供了很多的规范。 而像接口设计这样的技巧就很难定义一个规范，所以它的规范和上一章制定重用规范的思路类似。 不过，一如之前的案例，制定规范只是第一步，更重要的是在后面。 之所以要组织代码，其中的一个原因就是为了满足组织的需要。在单人的开发环境下，代码要不要组织都是次要的，只要开发人员本人没有问题，那就没有问题。但多人的开发环境下就不同了。不同的开发人员需要对软件和软件开发有着一致的了解。在组织环境中，每个开发人员都在一定的抽象层次上为其它开发人员提供服务。开发人员之间通过这种提供服务和使用服务的方式耦合起来，如果服务效果不好，那么开发就会打折扣。 一个人写出的类或框架，别人用起来是否方便，理解起来是否容易，这些都很重要。在上面讨论接口的例子中，我们为什么一边要分离两者的职责，一边又要让角色对象具有演员对象的特征呢？既然是这样，用一个单独的类解决它们不是更好吗，何必要多此一举呢？注意到，这是两个层面的问题。一个是分工问题，一个是便利问题。回想以前我们缴费的时候，需要去电业局缴电费，去自来水公司缴水费，很不方便，后来发明了银行代扣，这样，原先要去好几个地方的，现在只需要去一个地方。角色和演员就好比电业局和自来水公司，它们的职责不同。但是这对客户端来说是不方便的，为了获取演员的姓名，我们必须这样：
为了不需要在演员和角色之间切换来切换去，我们希望客户端的代码能够简单一些：
所以呢，这时候角色就变成了银行（当然也可以引入第三个对象来扮演银行，有的例子中确实需要这样，但这里没有必要）。客户端的代码就简化了，至于怎么获得姓名，那是你角色的事情，和客户端没有什么关系。那么，PersonProfile接口是一个什么东西呢？其实就是一种约定，是我们知道在银行可以代缴水电费这样一种知识。如果缺乏这种知识，我们就会向银行询问，你这里能代缴些什么费用啊？银行就会回答说，可以代缴水电费。这就使得接口变成了一种动态接口了。 如果我们把类本身看作是服务端，对类的调用看作是客户端。那么这里表达了一种面向对象的设计思路，就是宁可服务端复杂，也要使客户端简单。这其实也就是抽象的思路。 面向对象设计的这种特点决定了面向对象软件开发过程中的一些特色。首先，软件设计的工作量分配应当基于类进行。每一个开发人员都是为其它开发人员服务，任何一个人都需要用到其他人的代码。这种关系是分工的关系，要比非面向对象开发的分工化程度高许多。当然，这种分工是有着一定的原则的，是按照软件的分层体系来划分呢？还是按照业务需求来划分。只要能够划分清楚，任何一种方式都是可接受的。 其次，每个人保证代码质量，并维护自己的代码。在活用XP一文中，我们曾经讨论，是否采用代码集体所有制。我比较倾向于个人代码所有制，因为在这种分工的情况下，代码的质量和接口的稳定是非常重要的。所以，采用面向对象设计的团队，往往能够同时进步。正是因为客户端的要求非常的严格，迫使服务端不断的改进。 再次，对使用程度不同的类进行不同的资源分派。虽然每个类都会被其它人所使用，但有些类是很重要的，例如基础的类，或是重要的业务实体。这些类被频繁使用，保证它们的质量。 所以，代码组织的优劣对于组织来说是非常重要的，但是它还需要有过程的保证。 执行规范需要有相应的过程保证。而规范的执行结果也同样需要有过程的保证。可能很多的软件组织都拥有自己的软件过程，但是过程是否涉及代码组织的问题?可能有，也可能没有。代码组织的上游是设计的组织，而设计组织的上游是需求的组织。上游水源的清澈与否直接影响到下游。所以在开发过程中，有两件事情是非常重要的，一是尽可能保证需求组织的正确性，而是保证代码的组织能够正确的反映需求。要做好这两点并不容易，更多的情况是，你以为自己已经做好了，其实未必。更好的做法是要求团队具备快速变化的能力，代码的组织是一个演进的过程，或者说是一个重构的过程。不断的改进，才有可能带来优秀的组织方式，不去改进，原本优秀的组织方式也会变得丑陋。 |
61条面向对象设计的经验原则
阅读 来自：Blog.CSDN 《OOD启思录》 作者：J.Riel 鲍志云 译 [2004/10/11] 原文：http://blog.csdn.net/cpluser/archive/2004/10/09/129291.aspx
(1)所有数据都应该隐藏在所在的类的内部。p13
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。p15
(3)尽量减少类的协议中的消息。p16
(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 p16
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。p17 如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。 p18
(8)类应该只表示一个关键抽象。p19 包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。p19 设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。p19 朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。p23
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。p30
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30 规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。p30
(15)对包含太多互不沟通的行为的类多加小心。p31 这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。p33
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。p36
(18)从你的设计中去除不需要的类。p38 一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。p39 系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。p40
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。p43
(22)尽量减少类的协作者的数量。p52 一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。p55
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。p55
(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。p55
(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。p55
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。p57
(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。p57 当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。
(29)让系统功能在窄而深的继承体系中垂直分布。p58
(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。p60
(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。p60
(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。p60
(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。p60
(34)类必须知道它包含什么，但是不能知道谁包含它。p61
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。p61
(36)继承只应被用来为特化层次结构建模。p74
(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。p74
(38)基类中的所有数据都应当是私有的，不要使用保护数据。p75 类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
(39)在理论上，继承层次体系应当深一点，越深越好。p77
(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。p77
(41)所有的抽象类都应当是基类。p81
(42)所有的基类都应当是抽象类。p82
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。p85
(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。 p88
(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。 p89
(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。 p89
(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。p89
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。 p96
(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。p97
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。p99
(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。 p103
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。p103
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。p108
(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。p112
(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。p120
(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？p121
(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。p122
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。p123
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。p140
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。 p149
(61)不要绕开公共接口去修改对象的状态。p164
Redirect 调用 End，该方法在完成时引发 ThreadAbortException 异常。
对 End、Redirect 和 Transfer 的调用在当前响应提前结束时引发一个 ThreadAbortException。
End(HttpResponse.End )方法的说明：
将当前所有缓冲的输出发送到客户端，停止该页的执行，并引发 Application_EndRequest 事件。
在调用 Abort 方法以销毁线程时，公共语言运行库将引发 ThreadAbortException。ThreadAbortException 是一种可捕获的特殊异常，但在 catch 块的结尾处它将自动被再次引发。引发此异常时，运行库将在取消线程前执行所有 finally 块。由于线程可以在 finally 块中进行未绑定的计算，因此必须调用 Join 方法以保证线程已死亡。Join 是一个阻塞调用，它要到线程实际停止执行后才返回。
想不太明白
这里是关于此问题的讨论，先研究一下。
Update：
看了晓风残月 写的一篇文章 Response.Redirect 与 异常（线程正在中止） ，提到一文：
原来 HttpContext.Current.Server.Transfer("ErrorReport.aspx",false);
是把异常挂起了，所以代码照样执行
按照文章试验了一下：
Response.Redirect(url)等同于Response.Redirect(ur,true),有异常
Response.Redirect(url,false),无异常
Server.Execute(url)无异常
Server.Transfer(url)等同于Server.Transfer(url,true)和Server.Transfer("ErrorReportView.aspx",false);都会出现异常
总之，要想避免异常，就用Response.Redirect(url,false)或Server.Execute(url)。
关于这三者的区别，另开新帖说明。
ps：
偶然发现Server.Execute(url)可以实现那种弹出框提示后紧接着跳转页面的需求，而其他两种情况下弹出框提示信息都不会显示。
转自：http://zjtopspeed.spaces.live.com/blog/cns!19E5B2E99F0F08DF!1354.entry
// for small pages with total width less then width of the viewport
if(xScroll < windowWidth){
pageWidth = windowWidth;
} else {
pageWidth = xScroll;
}
arrayPageSize = new Array(pageWidth,pageHeight,windowWidth,windowHeight)
return arrayPageSize;
}
这个函数返回一个长度为四的数组{页面宽，页面高，窗口宽，窗口高}
<style type="text/css">
<!--
#aa{
width:300px;
height: 150px;
padding-left:13px;
padding-top:175px;
}
iframe {
width: 200px;
height: 18px;
}
-->
</style>
<DIV id=aa><IFRAME src="/url.htm" frameBorder=0 scrolling=no></IFRAME></DIV>
不只是session，asp.net中application、cache都很容易丢失，特别是当任何一个访问的用户中遇到异常，都很容易把所有内存中的数据丢失掉。
.net为了session丢失提供了一个解决方案，他可以把session状态保存在一个独立的进程中，这个进程不受asp.net的进程管理，因此即使asp.net服务进程回收内存也不会导致session丢失。而这个过程也很简单，先在服务中aspnet_state服务开启（最好选择自动），而程序中，我们需要在web.config中配置
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424"></sessionState>
就可以了，关键在stateConnectionString中配置进程服务器的地址和端口（一般默认是42424），也就是说进程服务可以在别的服务器上。还有一点需要注意，session中的数据必须要可以被序列化，其实也很简单，比如，我们要把一个CUser类型的数据保存在session中，只需要在cuser定义前使用一个标签[Serializable()]就可以了。
除次之外，asp.net甚至可以将状态保存在数据库中，这样，即使服务器重起，用户状态也不会丢失。
用window.open打开一个窗口，会返回一个指向子窗口的句柄（hwnd）
在子窗口中可以用self.opener引用父窗口的对象
以下为简单的例子，没有写错误处理，有兴趣的可自己完善。
<html>
</head>
<script>
var childWin=null;
function showValue()
{
alert(document.all("pButton").value);
}
function openWin()
{
childWin= window.open("child.html");
}
</script>
</head>
<body>
<input type="text" value="" name="pButton">
<input type="button" value="Open Window" onclick="openWin()">
<input type="button" value="Show Value" onclick="showValue()">
</body>
</html>
<!--child.html-->
<html>
</head>
<script>
var parentWin=null;
parentWin = self.opener;
function closeWin()
{
parentWin.document.all("pButton").value=document.all("cButton").value;
window.close();
}
</script>
</head>
<body>
<input type="text" value="" name="cButton">
<input type="button" value="Close Window" onclick="closeWin()">
</body>
</html>
<html>
<head>
<script>
function closeWindow(){
if(window.confirm("是否要退出本系统","退出")){
window.opener=null;
window.close();
}
}
</script>
</head>
<body>
<p>系统测试</p>
<p>
<button onclick="javascript:closeWindow();">关闭</button>
</p>
</body>
</html>
<script>
function getDaysByMonth(year,month){
var monthOfDay = 30;
month++;
switch(month){
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:
monthOfDay = 31;
break;
case 2:
monthOfDay = 28;
break;
default :
monthOfDay = 30;
break;
}
if (((year % 4 == 0) && (year % 100 != 0)) || (year % 400 == 0)){
if(month==2){
monthOfDay++;
}
}
return monthOfDay;
}
function week(curr,offset){
var year = parseInt(curr.getFullYear());
var month = parseInt(curr.getMonth());
var day = parseInt(curr.getDate());
var monthOfDay = 30;
var flag;
var result;
var m='';
var d='';
var y='';
if(offset>0){
flag = 1;
}else if(offset<0){
flag = -1;
}else{
flag = 0;
}
monthOfDay = parseInt(getDaysByMonth(year,month),10);
if(day + offset < 1 || day + offset > monthOfDay){
if(month + flag <1 || month + flag >12){
year = year + flag;
if(flag > 0 ){
month = 1;
}else if(flag < 0 ){
month = 12;
}
}else{
month = month + flag;
if(month==0){
month = 1;
}
if(month==13){
month = 12;
}
}
}
if(flag>0){
day = (day + offset) % monthOfDay;
}else if(flag<0){
day = day + offset;
}
monthOfDay = parseInt(getDaysByMonth(year,month),10);
if(0==day){
day = monthOfDay;
}
if(day<0){
day = day + monthOfDay;
}
return new Date(year,month,day);
}
function weekofday(data){
try{
var array = data.split("-");
var dt = new Date(array[0],array[1],array[2]);
var dtT = new Date(array[0],array[1],array[2]);
var dtS = new Date(array[0],array[1],array[2]);
var dtE = new Date(array[0],array[1],array[2]);
var dt=dt.getDay();
var ww="";
dtS=week(dtS,-1-parseInt(dt,10));
dtE=week(dtE,5-parseInt(dt,10));
ww = (dtS.getMonth()+1)+"月"+dtS.getDate() + "日";
ww = ww + "-" + (dtE.getMonth()+1)+"月"+dtE.getDate() + "日";
return ww;
}catch(e){
}
}
function initDate(){
var dt = new Date();
dt = dt.getFullYear() + "-" + dt.getMonth() + "-" + dt.getDate();
document.all.item("test").value=weekofday(dt);
}
</script>
<body onload="initDate()">
<input type="text" value="" id="test">
</body>
Public Sub Modify(ByVal key As String, ByVal strValue As String)
Dim XPath As String = "/configuration/appSettings/add[@key='?']"
Dim domWebConfig As New System.Xml.XmlDocument
Dim addKey As System.Xml.XmlNode
domWebConfig.Load(HttpContext.Current.Server.MapPath("../web.config"))
addKey = domWebConfig.SelectSingleNode(XPath.Replace("?", key))
If addKey Is DBNull.Value Then
Throw New Exception("没有找到的配置节")
End If
addKey.Attributes("value").InnerText = strValue
domWebConfig.Save(HttpContext.Current.Server.MapPath("../web.config"))
End Sub
function weekofday(data)
{
try{
var array = data.split("-");
var dt = new Date(array[0],array[1]-1,array[2]);
var y= dt.getYear();
var start = "1/1/"+ y;
start = new Date(start);
starts = start.valueOf();
startweek = start.getDay();
dtweek = dt.getDay();
var days = Math.round((dt.valueOf()- start.valueOf())/(24*60*60*1000))-(7-startweek) - dt.getDay()-1;
days = Math.floor(days/7);
var temp =(days+2);
return temp;
}
catch(e){
alert(e);
}
}
