simonw代码@痕记

sender=item[1]=source=window 这个就错了
item[1]=source, sender=button应该是这样

self.ClickEvent(self)在触发事件时会传入button, 这个self参数这时传入的就是Event.Call(table, ...) ...中的自定义变量了, 内部是item[2](item[1], ...)这个形式调用, 其中得第二个参数就是这个button,展开后得实际调用形式是
Window.Button_OnClick(Window, button)

只能py,py啊,py效率好低,导致wiki如此的慢

支持, 深入浅出的书非常好

参数详细说明已经完成, 见我wow blog

控制层负责和业务层交互, 比如textbox1.Text=User.Name 或者你控制button的显示或者隐藏等等

写这篇文章的时候是有的, 现在有段时间没有跟进castle了, 不知是否有改变.

老大做的好啊, 比我做的dz论坛+moinwiki整合强多了. 不过怎么论坛注册后wiki无法登陆创建页面呢

我的blog左上有写我msn

to slamfinger
以后主要在这里回复了
http://blog.cwowaddon.com/simonw

to 叶子
你下错版本了吧, 以前的版本才是这么配置, 而且已经失效了.
http://blog.cwowaddon.com/simonw 看这里. 不需要任何库支持, 记事本打开这个ShortKeyConfig.lua文件直接编辑就行.

提个建议, 我实在很想好好看你的文章, 但你的skin实在是让人看的眼睛疼,只好复制下来看了.

Sumtec说的有理.

我也使用了DreamHost主机, 开始选的bluehost, 刚注册发现ip被gfw封了, 无奈下只好退款选了DreamHost, 近期倒是没出现啥大毛病.

有失也会有得, 换个角度考虑心情就会变好, 被罚也是宝贵的经历和经验! 无法抗拒就只能选择顺从.

@FantasySoft
我认为应用WYSIWYG html 要比改进wiki语法效果好, 见效快, 成本低.

@bigtall
WYSIWYG html 一样能做到专注内容专注写作, blog的成功就是最有力的证明. 而在格式控制上要比wiki语法好用的多.

@FantasySoft
您可能没有注意看最后一段, 其实对于wiki最重要的莫过于内链接, 我们只需针对这点创造语法, 可以模仿ubb,vbb这样的思路实现, html一样可以被解析.

@随风流月
复制/粘贴, 永远无法避免. 我们不能对用户及应用场景做绝对化的假设.

@FantasySoft
从技术角度讲Wiki现有的语法优于html, 但html已然成为了标准, 更何况html比较于Wiki现有的语法并没有做不了的事情, 只是技术难度稍大些, 这些困难在10年前很难解决, 而在现在都可以处理妥当. 有了一个成熟而普及的技术为何还需兼容另一种.
我的思路是彻底抛弃wiki现有语法, 改html, 而非在现有wiki语法上修修补补添加html支持.

@chy710
wiki与ajax确实不好比对.

@JesseZhao
就写作习惯来说, 即便对于程序员, WYSIWYG也是更好的方式.

@FantasySoft
针对目前wiki结构化文本WYSIWYG的编辑器继续发展下去不是一个好的选择, 原因有三:
1. wiki语法并没有像当初的html成为标准, WYSIWYG技术发展下去难度很大.
2. wiki最终输出的还是html, 何苦使用其他语法在绕弯子.
3. 外界web上的文档大多为html格式, 若从他处粘贴, 必然又要经过一次多余的转换.
也就是说 wiki语法->html, html->wiki语法, 双向转换都要做到完美, 其实这又何苦.
将其写作语法替换为html而应用html上成熟的WYSIWYG技术必然会对wiki引擎大动干戈, 也不是一时半会能完成的事情. wiki需要逐步走向大众, 所以不能总以专业人员的眼光来看待, 很可能未来wiki引擎会因写作语法技术的变更而重洗牌.

Mobile上的crm实在是做的简陋

修改ShortStory.lua中的Timer配置改变时间, 修改ShortStory.Config.Channel 来改变频道

kiler 可能没有理解我的意思, 我的意思是orm不仅大项目适合, 小项目也同样适合.

不少orm提供了面向快速开发的特性, 也能为短期的小项目更加降低成本. 而小项目往往没企业级的那么多严格的要求, 如性能,稳定等等. 相反orm能带来更多稳定及一致性, 因此我认为非企业级项目尤其是小项目更加适用.

lua 虚拟机不是基于寄存器的么

楼主排版方式好似moin wiki的语法.

合理的分类才能让别人更好的理解程序, "并不是所有的行为都必须属于某个对象" 这个也需要合理的放置在相应部分, 而不是平铺.

非常好的分析, 我引用在http://wiki.cwowaddon.com/moin.cgi/WoWFile 这里了. 希望能多交流.

to dudu
谢谢支持,最近在阅读源码同时也在更深入的理解wiki概念,希望能为博客园的发展做出一份贡献.

to 戴南
wiki的概念现在还难以让大家普遍接受, 专业开发社区会好一些, 有很长的路要走.

to j
我同样非常喜欢啄木鸟站点

东亚大多数国家语言属于DBCS 字符.
A character encoding in which the code points can be either 1 or 2 bytes.
Scripts use thousands of characters (Chinese, Japanese, and Korean)
Chinese has 80,000+ characters
Korean has 11,000+ characters
Japanese uses 4 scripts

权限继承, 权责分离, 资源分类, 操作分类, user-group等因素也应该考虑进去, 越说越多了...

支持, .net这方面的东西实在不多.

to doko
pojo对于数据传输有很大的优势有利于计算机的思考方式, 但对于自然事物的描述却不得力, 人的思考方式是自然方式, 当系统规模变大, 非自然的设计方式会让人很难上手.

终于好了, 北京长城宽带都不慢~

支持~支持,欢迎到北京来

Office 2007 中文版 RTM 11.20也要发布了, en的11.6发布了

我对teddy的项目感兴趣~

早就期盼有个大的服务商来提供wiki服务了, MS的wiki服务一直在测试阶段, Google终于把wiki补到了产品线中.

极度同情中... 幸好..幸好..我从现在开始学.
跟进最新技术, 有好也有不好的一面, 尤其是应用方面的技术.

to ZergTant
我在flexwiki站点上看到他说最新版本已经能很好的支持中文了.

to 发条木偶
pmwiki看起来不错,不知你在哪里租的主机? 编辑不支持所见即所得很费劲, mediawiki让我用的头大.

相比起感觉第六个好些{}代表代码块有点寓意. 不过也赞同上面说法, 抽象点啊, 有些直白.

所有修改到下个版本吧, 郁闷的香烟, 我也忘记叫什么, lax一类得似乎, 你可以问问其他朋友

to pass
互换装备得, 函数我写道了扩展库中, 你可以仿照弄下饰品, 最近有点忙, 有空了我会好好完善下常用得库, say和yell你可以直接调用sendmessage来实现, 我那只是举了个例子

to 峰
可以这么理解的.

to try1
你直接在类内部使用接口就可以了, 他的实例化容器负责你看不到的

注意身体, 少吃麦当劳肯德基~

ppt写的好

to 可口宣
基本上没有用很专业的词汇, 只要有些项目经验, 应该会产生共鸣.

to 菌哥
谢谢支持~~

to 郁闷的香烟
你可以使用单独的经验条插件.

说的有理, 合作书评想法也好. 北京见到THIN本人长的也帅!

to 伏特
问题较多,头晕中...我再看看

to 关山飞渡
我尽量找个战士号测试下加上

to CY[匿名]
见上面的使用说明. 修改lua文件.

to TerryLee
感谢提醒, 确实疏忽了IOC与IOC容器的说明.补上了. 中秋同乐!