1
villadora 2014-07-08 12:14:21 +08:00
demo项目: http://cortexjs.github.io/todos.backbonejs/, http://cortexjs.github.io/autocomplete/
欢迎查看demo, 和bootstrap, jquery, backbone这些框架都轻松集成哦 |
2
liaa 2014-07-08 12:37:44 +08:00 1
很酷,下次有应用场景时会试一试
|
3
airyland 2014-07-08 12:42:45 +08:00
重造轮子?看起来不错,但是确定转到spm后就不想折腾其他的了。。
|
4
chemzqm 2014-07-08 12:43:03 +08:00
当年TJ说 component 要实现自己的 registry,结果是不得已用了很变态的方式实现了 Semantic Version。
|
5
villadora 2014-07-08 16:22:52 +08:00
@chemzqm component用github做registry name/repo最后就弄的很复杂,而且在公司里面的生产环境就没法用了,不能直接用github也没法自己搭registry
|
6
pepsin 2014-07-08 17:51:16 +08:00 1
哈哈,支持一下
|
7
AlanZhang 2014-07-08 18:03:13 +08:00 via iPhone 1
这个类似bower吧。
|
8
chemzqm 2014-07-08 20:15:04 +08:00 1
@villadora 我到是觉得 name/repo 挺好的,经常是在用别人模块然后发现需要稍微改点才能更好满足需求,因为break api等原因让人家接受PR不太可性,所以干脆直接fork然后改成自己名很方便。
component 1.0支持bitbucket,也可以比较容易的实现自己的registry,我的实现是第一次从 github把代码拉下来,以后除了 master 的代码都直接从本地读取,只是现在版本管理都交给tag,效率很低,也不容易使用 |
9
iwege 2014-07-08 20:24:59 +08:00
cortex 能用来配合requirejs或者sea.js来用么?还是说只支持点评自己的模块系统?
|
10
kaelzhang 2014-07-08 20:49:36 +08:00
@iwege 感谢关注~
其实,无论是 browserify 还是 component,都会默认自带模块系统,因为 requirejs 还是 seajs 做的事情很有限,比如对 [semver ranges](https://github.com/mojombo/semver/issues/113) 的支持,对 [file module](http://nodejs.org/api/modules.html#modules_file_modules) 和 dir 的支持,对 __dirname,__filename 的支持,对 require.resolve 的支持。 当有了包管理器之后,模块加载器其实是不需要存在的,而且用户也不需要写 `define`, `define.amd`. 而且现在生态系统并不好,每个开源项目里面都要去写一大堆 AMD, UMD, *MD,它们基本上是我们平时开发过程中不需要去操心的,事实上,我们只需要跟 nodejs 一样写代码就好了。这也是为什么这些 *MD 一直都只是 proposal。 我们永远希望让开发者写更少的东西。 只有 [Module/1.0](http://wiki.commonjs.org/wiki/Modules/1.0) 是必要的 |
12
tinymao 2014-07-08 21:09:16 +08:00 1
待过10天左右点评,对 cortext 印象深刻,因为英语不好老是多打一个 t
记得当时是这样, node 起一个服务托管 css/js 。 然后 files:///xx.html 预览,好像没办法直接自动刷新,我做 APP 的,这个只是兼职,所以可能说错了。 |
13
kaelzhang 2014-07-08 21:29:37 +08:00
@chemzqm 阁下是少有的经常会用包管理的人哪,握个爪。最近正准备写个文章谈谈这个问题。不过从生态环境来看,它会潜在地让用户去制造更多的fork,并且去依赖这些 fork,这个长久来看会有问题的。嘛,而且tj一年前就已经基本上把项目给樱桃哥一个人来维护了,这个才是硬伤 D:
|
15
kaelzhang 2014-07-08 21:32:21 +08:00
@AlanZhang 其实 bower 在某种程度上只是一个脚本管理器,把脚本下载到本地,然后让开发者自己搞定后面的事情。另外 bower 并没有用 commonjs,这样一个直接的问题就是,模块间都是用全局变量来交互,这样很糟糕,也因此无法多版本共存。
|
16
JoyNeop 2014-07-08 23:39:01 +08:00 via iPad
名字不合适。。。已经被公众默认是 ARM 的商标了。。。
|
17
iwege 2014-07-09 10:55:43 +08:00
@kaelzhang 我觉得我不关系什么协议的,我只关心运行原理。
从给出的demo来看,你的解决方案按照我比较熟悉的描述就是requirejs的CMD风格, 但是略有不同的是你将__dirname和__filename作为一个参数传递进去。这个倒是不是关键点,不过这种方式却可以简单的解决混淆的问题。这样来看 cortex 只是起了一个server然后将代码包装了一下。把cortex 比作一个简单的express都可以,所以cortex要换成requirejs也相对简单,真正的关键还是在neuron的那套上面的。 按照我的理解,neuron是模块加载,neuron-builder 是模块打包的工具。 不过这里也牵扯出几个问题: 1. 单一模块依赖的第三方模块如何与其他的模块共享,如果采用node 的方式是每个人自带自己的依赖就违反了web领域的优化,唯一命名貌似是唯一的解决方案,但是感觉好麻烦。 2. 非JS层面的依赖无法解决,component 想要解决这个问题,不知道现在解决了没有。 3. 基于前两个问题,怎么解决当前前端共享和打包的问题。 另外neuron-builder 没有针对大小写敏感来设计么? 例如:你的文件名是: c.js,但是在testcase代码里面是:var c = require("./C"); 按照这样的处理结果,如果大小写敏感,应该会直接出错,除非你测试环境都是在windows或者mac非大小写敏感的server上。非大小写敏感的server,虽然会传递script的内容过来,但在requirejs里面,c和C是两个独立的模块(尽管code是一样的)。 |
18
iwege 2014-07-09 11:14:37 +08:00
另外这个东西还有硬伤:不支持代理。在有代理的公司里面基本上属于不可用状态。
|
19
villadora 2014-07-10 16:27:56 +08:00
@iwege 关于模块依赖,cortex的方案可以参考博客http://cnblog.ctx.io/post/91333512673/cortex.
非js的依赖其实依赖管理和js的一样已经解决,但非js层面的依赖问题主要在于页面如何按需载入以及如何避免冲突,css里面的资源又如何处理, 这方面实际上大家都还在探索,没有一个满足所有需求的方案。cortex目前也是在管理还依赖的情况下,提供了周边的工具来实现css在html页面的注入。 关于第三点, 不知道共享是指哪个方面,打包现在开发好的cortex项目,本地一个静态服务就可以跑起来,发布打包也就是把cortex install/build之后的项目文件打包好就是一个独立的站点了,比如现在的几个examples都是这么做的。 关于大小写,之前也碰到过,确实需要处理,至于是要像requirejs里面一样是两个独立的,还是统一成小写,这个还希望大家参与讨论, 可以到https://github.com/cortexjs/neuron-builder/issues新建issue. 因为如果是有文件名大小写的不同内容也不同的文件,在windows和mac里面本身这个模块里面的文件就会被自身覆盖, 从而导致出问题。 代理的问题现在还不支持,已经提到issue: https://github.com/cortexjs/neuropil/issues/52 有想法和建议,欢迎提issue~ |
20
iwege 2014-07-10 22:13:10 +08:00
@villadora 第三点和第一点是有联系的,但是应该不适合web领域。现在所知的模块体系都是源码级别的共享。假设
d |- a | |-b | |- c |-b 在源码级别是可以解决的b的依赖重复问题,但是一旦a build成为一个模块,c也同样,那么d在获取ac的时候就依赖了两份b的代码。当然这种主要是针对node-webkit / atom-shell 两个场景下的模块分享问题,而且也算是一个伪命题,因为JS是天然的开源属性... 至于非js依赖,也包含了模板,css,image等,当然都同样不属于web领域... 大小写的问题,最好是两个独立模块,毕竟linux上的server多一点,这种应该只能约束开发规范。只是在windows和非大小写敏感的mac上比较难易调试罢了。 |
21
villadora 2014-07-11 11:29:36 +08:00
@iwege 所以web领域都没有做套嵌树的模块管理。和node一样的模块管理方式更适合于文件系统,比如node, node-webkit也是这样,不用考虑overhead。像插件更是需要进行模块独立,即使有overhead也是在能不用共享的情况就不使用共享,而自己打包。这个是符合谁使用谁负责的原则的。外层不应该关系内层的实现。
web上的模块管理,cortex都是采用扁平化的,cortex的build的模块也不会包含依赖的重复代码,只会包含自己本身的代码。 d | - a | - b | - c a依赖于b这个信息都是模块自己申明而不是靠将b整体打包到a中实现, 只要版本兼容,d只会获取a,b,c各一份, 像之前说到的重复就不存在。但这种方式在其他的包管理下会存在冲突的可能,因为b只有一个。 虽然js是开源的,但是每次使用模块都需要用户去自己处理,选择代码甚至修改源码,比如我写d我需要去处理b里面的代码是很奇怪的,就像开发atom的packages的时候如果还要关心别的packages用了哪些依赖一样。 |