canonical

目前我们主要基于witrix研发行业软件，本身并无意推广witrix平台。现在witrix所承载的核心应用对它的灵活性和性能都有着很高的要求。
1. witrix技术的创新之处在于提供了程序结构的新的抽象和融合方式，它所带来的价值主要是程序的持续改进能力。在公司里我们是严禁拷贝粘贴的。可以重用的业务逻辑总可以抽象为某种技术实体。
2. domain specific的语法我们认为非常重要。很多人倾向于使用非常强大的语言，这种语言允许构造所有复杂的局部结构，但是在我们看来，再复杂的通用语言也无法涵盖各异的业务逻辑，而语言本身提供的抽象能力至关重要。同时我们还非常关注于抽象出的技术结构的稳定性。假如做一件事情有n种语义等价的方式，而且没有一种强制手段可以进行形式校验，则任何一种抽象得到的结构都是不稳定的，因为我们总是会受到各种诱惑偏离一种固定的形式，最终造成形式的解体。
3. 我们在编译期作了很多工作，这是解决系统结构问题的一种重要手段。在没有得到全部信息的情况下（没有运行时的数据信息），即使没有类型概念，我们仍然可以在结构方面作很多文章。
4. 现在很多情况下其实是没有很好的抽象方式。比如说，如果把位图的每个像素都看作一个具有自我活动能力的对象，我们遇到的问题首先是巨大的管理成本，这远不如把它看作只接受外部控制的数据信息更直观，更简单。一些所谓优雅的设计只是在最模糊的印象上似乎很时尚， 但是真正细致到细节的时候，它远不能提供我们所需要的结构控制能力。
5. 代码是交流的重要工具。witrix设计的一个重要目标就是代码的可描述性，编码的过程就是描述系统结构的过程。我们正在尽力缩小需求描述与代码结构之间的概念差距。但是很多时候代码是信息不完全的，有些信息我们写在了代码之外的文档中，特别是一个设计的原因是什么，为什么采用当前的处理方式。
6. AOP的原始形式存在一些隐蔽的问题，直接应用AOP效果是有限的。在witrix中我们是对AOP的概念体系进行了补充，才定义出足够强大的结构组合方式。
7. 对程序员来说代码更加便捷，但是工具仍然是有效的，它可以限制程序的可能性，大大提高我们构造某种业务流程的可靠性。
8. 商业是一方面，人的精神和传统是另一方面。
9. witrix目前就在运行时管理着大量的代码版本，继承只是一种初级的结构融合手段。

对设计有兴趣的朋友可以通过 canonical.cqh@gmail.com联系我

我是在讲语言，讲的却是语言之外还有别的

我一直在讲物理，你现在来和我讲数学。。。

描述和解决能是一回事吗? 我写下一个方程,这叫描述. 求出它的解, 这叫解决.

sign, 很遗憾你这么想问题。 我在很认真的回答你的问题。因为这个问题有多个人问过我，所以写一篇文章。

我的专业是物理。在我本科的时候，我主要在读更多的物理和数学，而不是掌握具体的语言技术。 大四的时候我读了图书馆可以找到的大部分C++书籍。当然我更多的时间仍然是花费在数学和物理上，因为原本我就是打算去做理论物理研究的。

我的意思是基础很重要。大三之前都是学习最基础知识的时候，专业的限定并不是很大。在我们学校，大二各个系开的课都是类似的，只是难易，重点不同。 你年龄太小，还区分不出什么是真正重要的东西。 其实即使是电路分析，你搞清楚里面的物理和数学也是很有意思的。绝对不是让你按照考试的要求学习书本上的知识。

学习并不是为了有用，它只是让你接受教育，了解历史上人们所做过的一些工作。

温和的感想和例子未必是对你有用的。你还没有受过挫折，只是一味要求别人顺着你的心情。我写的东西如果你放弃成见体会一下，也许会发现并不是那么差。

高手不高手并不重要，关键是成为别人可以信赖的人，成为一个可以解决问题的人。

1. 语言中的时间观念这个论题绝对不是我的原创
2. 我一直强调思维的连续性。不是说"B这样搞来搞去还是达不到A的高度"， 而是说我们如果把系统的特征逐个分解，到底需要做哪些工作才能逐步增加最有价值的部分，特征聚集产生的增值部分又是如何显现的。
3. 一种实现总是包容了太多的思想。思想错了，实现对了。实现死了，思想活着。

在Witrix中我们系统化的应用[面向集合+通用组装规则]的技术手段，大大提高了代码的重用性

从指针到引用，虽然在C++中显得只是写法上的简化。但是仔细体会能够发现概念层面发生的一些变化。我们不再依赖取址这个具体过程，而在某种符号化的层面上理解引用所表达的信息关联。耦合不是一个合适的描述。

你还是不懂得

1+1=2只是个形象的说法，它可不是歌德巴赫猜想的内容

在数学和具体工艺之间还存在着所谓的物理学，这就是Witrix设计的方向。

我想你对Witrix技术还不了解。我在blog中所阐释的理论一般都是在Witrix中实践了的，这些技术包括AOP动态化，基于ORM的实体化等都是Witrix中对开发效率有重大提升的地方。 目前很多技术在业内确实处在一种言过其实的地步，而我们在理论方面有很多突破，而在具体实现上也作了很多精细的调整，这才最大限度的发挥了技术的效用。

开发工具并不一定是生产力的主要来源

JSF技术有一些真正有价值的东西，但是根据我们的实践，这些价值有其他更加优雅的体现方式。 JSF不是必须采用JSP Tag, 但是它需要一种类似的技术，而它在架构设计中必然要照顾到这种技术实现。 其实witrix中的tpl技术也是一种tag技术，只是它远比jsp tag要精致。

JSF架构最大的问题就是开发新组件很麻烦，完全基于JSF构建程序很繁琐，最终提供给用户的调用接口其实也有更加简明的方式.

关键正在于reference这个概念本身的分化和精细化

没有人认为核心对分支完全不影响，否则核心升级就没有任何意义。只是升级是可选择的，而且分支可以选择整体覆盖，即扩展后整个流程A->B->C都属于分支

分支版本可以是不同的产品，不一定是同一产品的不同实施版本。在设计上的要点就是尽量允许主系统升级后可以随意覆盖项目版本，因为项目版本针对主版本的修改是以追加方式进行的，即并不直接修改任何主版本的文件，而是写在独立的文件中，平台负责把custom内容和基础版本内容融合。如果分支版本完全需要采用新的实现，平台提供了完整的替换机制，同时可选择是否校验接口的兼容性。

witrix中meta的思想与一般人的第一感觉还是有着本质区别的。在witrix中，典型的开发过程是通过powerdesigner设计数据模型，然后自动生成meta数据，此时对于数据库的增删改查就可以进行了，包括对于one-to-one,one-to-many,many-to-many等关系的维护，高级查询条件的拼装，导入导出功能等。这些设计因为基于ORM模型，因此并不是仅仅针对单表的，而是可以很方便的处理关联表的情况。
如果界面没有特殊要求，一般最多调整一下meta中字段的属性。如果完全要求定制布局，则在前台通过<df:Field name="fieldName"/>等标签引入字段元数据，增删改界面可以共用一个定制页面。而后台依据meta对前台提交数据进行初步处理。在witrix的开发过程中，几乎不需要调用get/set方法，也不需要调用session.save, session.update等方法，前台也几乎不编制完整的界面。

to mixlee: 我们目前无意成为平台软件供应商，因此不对外提供witrix的资料。

Workflow中需要页面和流程配合的部分在Witrix中主要通过前台js选择实现，流程引擎实现的是事件响应而不是驱动界面。 这里倒不太用得上我所谓的PageFlow。 实际上我是反对基于action的flow设计的。

我所写的一般都是理论分析,并不是针对初学者的介绍性内容.
AOP是一种很少限制的结构操纵技术, 你可以去想象它的应用

数据到底是保存在session中还是request中，对于这个问题，基本上它的答案就是应该保存在哪里就保存到哪里。 对于一般简单的网页，应该少在session中存放变量，而对于复杂的企业应用，在session中保持状态是必要的，不过查出的数据一般放在request中就可以了。

一种flow关注的重点当然是协调某种类型实体之间的动态关系，这其中必然需要一种机制来保持状态信息。PageFlow肯定需要一种大于request而小于session的状态保持机制. Jsplet框架就提供了这种机制，而PageFlow是运行在其上的一个引擎。

嗯，我们对hiberante作了一些扩展，包括支持公式字段，附件上传字段等

使用hibernate不是为了从面向对象的观点思考设计系统这种纯学术性的目的，而是为了更快更好的解决我们所需要面对的问题。 witrix平台中对于hibernate的使用是相当深入的，包括对于hibernate的多处hack.
我们需要模型是因为我们需要一种控制力， 不在于是否native. 从物理模型恢复逻辑模型比较直接，并不复杂， 而且我们并不试图恢复整个逻辑模型，而是得到我们所需要的信息即可。
面向对象是什么？ 首先它是一种相关性的聚集。

@OneEyeWolf
如果你有兴趣, 应该读一读我其他的文章, 以搞清楚我在说些什么.
http://canonical.blogdriver.com/canonical/961298.html

operator的设计正在于它的可扩展性不够.

设计的实现方式是设计的内容之一

@OneEyeWolf
具体实现的策略就是 CRUD + Filter, 我已经写得非常清楚.

我们的bizflow实现是基于tpl技术的，而不是使用operator的概念， 那样太受局限了。

bizflow是由biz object 驱动的流转，而不是由步骤的先后顺序驱动的流转，所以它不是完整的工作流。

简单的bizflow可以满足众多不需要分支的流转需求，这已经足够做一些有意义的事情。

对于事件机制不是设计而是描述。

行为之间的顺序也是结构, 结构这个词的含义是非常宽泛的, 我所指的并不是数据之间的关联,而是泛指关联及关联的集合.

虽然我说过很多遍,但我相信大多数人仍然没有明白我所指的在复杂性级列之间过渡的含义. 正如我常说的, 一个人只理解他已经理解的东西

没有这样的计划

架构师之家是什么. blog帐号 canonical

jsp tag最核心的设计问题在于它所假设的模型是动态io处理，而缺乏对于xml结构的充分利用。对于具体的表现， 我已经在一篇blog中作了评述。
http://canonical.blogdriver.com/canonical/572201.html

应该是走高而不是走低。集成的需求促使复杂性上升。