我使用前台模板+AJAX的样例站

道理有,
不过代价太高,并没有实实在在的依据,我所说的代价不高,都说出了具体的细节,
还有就是template转移到前台后,后台服务器的压力就小了.
那么这个压力的减少相对于代价来说到底值不值,不同的开发者会持不同的观点的.
就我本人来说,目标是后台用本地的exe来做.
因为我本来就是c/c++/delphi程序员,现在在学习D,
自从做WEB以来真的对WEB开发中的什么框架,平台,模板,html,css,js,php,java,asp,........
这些纷乱的选择,配合,规则,团队.....给弄烦了.我要摆脱这个局面.这也就是我一直在研究这个的原因.

也许有朋友会奇怪团队怎么也在这里出现,
对,团队中最多的事是什么?
沟通.
那.团队还应该干什么?我认为是如何减少不必要的沟通是很重要.
前后台彻底分离了,我的这些想法才有可能实现.

不少朋友会觉得为了这个去搞个前台的javascript template的代价高.
呵呵这个不能强求,谁都有自己的选择.

不错的尝试，但可能存在2个问题。
1、如果用来做内容网站，前面提到的搜索引擎友好肯定是个难题。
2、如果用来做应用系统，如果用例比较多——数百个，没有独立的Controler肯定会相当麻烦。

考虑用来做一个个功能不复杂的模块，倒是个不错的方式。

这个前面已经提到解决方案了,不敢说方案没有问题,也不能说方案绝对不行,让事实说话吧,我们今天正在实施我的方案



这个我也不敢乱说,毕竟我这个做法是个新的尝试,在我们的应用里就好像你看到的我们的站,我觉得用起来很顺手,有配置的功夫,代码就写完了.但肯定还需要不断的实践来检验.
还有就是我们这个站是有用户制定样式的,不是简单的样式模板(用我们这个方法目前还没有提高到样式模板高度),
也就是说我们会做出不同布局效果的很多内容相同的站,用来实践这个方案.实践多了,就会由感性认识上升到理性认识.

另外就是例子再多对于我们的设计来说都没有任何影响,
因为对于后台:
我们的后台设计的就是所有的域名以及参数,也就是url的变换,可以随时通过简单的配置转向到特定的网站目录去执行,
如果你登录的话(虽然会失败),你监视数据会发现:
CK xxxx  验证码
Q LOgin 请求
S login 站点跳转 其实是把数据提交给 后台 对应的模块
SEL #denglu
u_name yourname
u_pass yourpass
虽然提交的url是www.xxx.xxx,但是其实执行的模块是http://login.xxx.xxx/对应的后台模块,
这两个域名对应的模块根本就不在一个目录下.后台唯一入口程序就是处理这种需求的,S 变量就是site站点模块转向的意思.
所以不管用例有多少有方法提交到正确的后台,

对于前台:
这个就需要有一套管理模板,调配模板的方案了,现在的确欠缺,我也曾经发帖子讨论这个问题,不过没有朋友提出实质性的意见.呵呵.偶不担心这个,就像上面我们谈到的内容一样,这些谈到的东西也可以说很复杂,这样的东西我都做出来了,
调配管理模块的问题,我自信也能搞定,程序员就是干这个的,只有效能如何,随时间的推移总会提高的.

程序员就是造轮子的.不造轮子的程序员.他的程序人生是不完整的.

简单的使用的话可以从jct模板开始,复杂的话,就要自己根据自己的习惯和业务需求设计整套体系了,很多问题要解决的.

现在的js模版还是搞一个隐藏得textarea作中转吗

刚刚出差回来.
模板数据的调入方式/存储方式和模板本身是无关的,那是根据应用的不同采取不同的方式.
也就是说.js模板使用的流程里,模板的调入方式/存储方式不是模板负责的内容,是应用的问题.
js模板只要求在正确的时间传递给他正确的参数就行,这个参数是怎么来的.js模板本身是不负责的.
所以.textarea作中转只是方案之一.其他的什么ajax动态模板,html静态模板,js模板生成静态js文件都是可选的方式.
这要看应用了.
当然可以把js模板设计的足够复杂,同时满足/自动适用上面这些方案.但理论上这是外围的事情,不是js模板本身要解决的问题.

我有一个系统，后台完全是OO的，发向struts的数据是各种聚合关联的对象，struts的标签库轻松的把我的对象在界面上全部展开，如果这个系统我要用楼主的方法改写，与后台彻底分离的js模板可以很轻松的显示我的数据对象吗？我的后台具体还要做些什么工作？

[quote="xzs"]我有一个系统，后台完全是OO的，发向struts的数据是各种聚合关联的对象，struts的标签库轻松的把我的对象在界面上全部展开，如果这个系统我要用楼主的方法改写，与后台彻底分离的js模板可以很轻松的显示我的数据对象吗？我的后台具体还要做些什么工作？[/quote]

这个问题很具体,我还没有这方面的经验.无法直接提供方案. 不过可以提供我现在应用里的一些代码,您自己考虑一下问题的解决是否有途径.

举一个菜单条的例子:

此菜单条是一个2级的菜单条,是根据1级的菜单条动态生成的.我直接把注释写到对应的行上.

		<div id="fenlei">//菜单条的布局控制元素
			<ul id="daohang1">//导航条就是直接用ul,li的结构
				<!--var TOUP=1,	JSONQUEUE="Q:'dmxw',SEL:'#dmxw..mutex'";-->//为下面的存储模板提供默认的数据,
//也就是说初次页面显示的时候,这些变量提供了默认数据,如果再次触发模板生成菜单,那么给对应存储模板的参数当然要注意保持变量名的一致性问题,
//当然这个变量名一致性的问题是可以更优美的解决的,不过现在没有实现,只能是笨一点了.
                               <!--!@ daohang1-->//这里是存储模板,注意是非分离的,也就是默认直接显示在页面上,在初次运行的时候上面的变量就是传入的参数了.
				<li><span>分类:</span></li>
				<!--for var F in FenLei-->//FenLei是一个存储菜单条数据的数组,是我们的应用定义的.属于全局变量
				<!--if FenLei[F].toup==TOUP-->//判断1,2级菜单的从属关系了
				<li class="fenlei1">
                                      <a onclick="return jsonQueue({+-JSONQUEUE-+,fenlei:+-FenLei[F].id-+});" href="#">//jsonQueue是全局的函数了,用于和后台通讯
                                      <span>+-FenLei[F].f_name-+</span>//取菜单的文字f_name
                                      </a>
                                </li>
				<!--end-->
				<!--end-->
				<!--if TOUP==14-->//对于有特殊表现形式的菜单进行特例处理,这个特例就是TOUP==14的菜单要怎加一个字母分类索引的表现
				<li class="fenleiszm">||<span>首字母:</span></li>
				<!--var AZ='ABCDEFGHIJKLMNOPQRSTUVWXYZ';FENLEI=14;-->
				<!--for var S=0;S<26;S++-->
				<!--var ZM=AZ.slice(S,S+1);-->
				<li class="fenleiszm"><a onclick="return jsonQueue({Q:'dmxw',fenlei:+-FENLEI-+,abc:'+-ZM-+',SEL:'#mhlb..mutex'});" href="#"><span>+-AZ.slice(S,S+1)-+</span></a></li>
				<!--end-->
				<!--end-->
				<!--! daohang1-->//存储模板定义结束
			</ul>
		</div>

 由于我贴出来的是我们应用的具体代码.可能对你意义不大.

通过上面的代码,可以看到在设计中的通用需求:

默认显示:这就是存储模板的基本功能了,实施的时候设置默认的变量是最必要的,同时再次触发存储模板要保持变量名的一致

特例处理:这个只有结合应用需求才知道应该如何写代码,

确定(向后台)通讯参数:我的例子里也就是根据数据的不同,定义jsonQueue的参数了.我这个方法完全是手工的,和大家习惯的写配置的方法不太一样,比较的话,很难讲,那又将是一场口舌之争

经过上面的描述,如果要我来判断您的需求的话,完全可以实现.

你的需求中的各种聚合关联其实是有结构的,结构只要确定,就可以代码化,理论上和分级的菜单(字母检索的)差别不大.然后根据数据的不同确定通讯参数就实现了.

说句自己的体悟:
聚合关联和菜单的区别不大.最终目标都是要确定通讯参数,至于通讯完成后数据的处理那就是另一个环节了.

也就是说,要向您这样的需求,是要自己写一套调配的库函数的.

我虽然一直在研究这个问题,但是自己也是很初级的水平,处于尝试阶段,还没有上升到严谨整体解决的理论高度.

你可以在我给的样例站点上看到三个主要的js文件,

app.js,看名字就知道是何应用有关的文件,应该随应用的不同自己写的,不过里面有一些函数基本可以上升到库级别了,主要的通讯逻辑控制都在这里面,

        无非就是几个函数

        jsonQueue,异步的方式向后台提出请求

        jsonSync,同步方式向后台提出请求

        parseQueue,处理后台给出的数据,要注意,是所有的数据,当然模板本身也是数据了.

        view,表现后台给出的数据

abc.js,jquery的扩展,通过dom标签的class属性来控制页面表现.这个说起来麻烦,感兴趣的话看看代码先

lib.js,都是一些小的常用的库函数了.其中的processXDOC是处理标准的xhtml写法模板的,我的应用里采取的是标准的xhtml.你不一定要这样

差别不大这句话要按我的解释的话:

前台表现就是表现后台的数据的,数据怎么来的,数据见的关系如何,并不关心,只要有可以代码化的结构就行了.

因此数据的提取是后台的事情,前台不予负责.

其实后台给的数据多数情况下就是一个数组.结构是你应用里确定的,模板根据结构写就玩了.

在我的应用里,要求模板用标准的xhtml写.你的应用里就不一定这样了

楼主 能否给点建议，JCT 如何入手。目前也正准备改造项目。前台是用楼主的JCT好些还是Javascript 呢？？  优势在哪里？ 那个开发的速度更快，用户体验的效果更明显。 如果有好的学习资料或例子可以分享下。谢了 guichenguang@gmail.com

JCT就是用javascript写的模板工具呀！
一下是个人观点，毕竟我用的熟
jct优势..........首先是灵活性，其他的一些就不提了，jct的主页上有。
开发速度.........我是配合jQuery用的，除了jct外，还有abc(Action By Class name,也是自己写的),开发速度真的很快。
用户体验.........这个和jct没有关系，要看你的设计了。jct和这些没有冲突。
我不知到你的应用具体是怎样的。我很愿意提供一些支持，能够帮到你，我希望更多的朋友参与，在实践中完善出一个前台的系统。
你可以把你的应用先拆分出一些小的模块，写出需求，我直接把实现出来，这样你就会清晰的明白工作流程了。
我们还是在论坛上说吧，这样方便吸引更多的朋友。
如果文字不容易表达的话，我们可以gtalk交谈.
abc 的帖子.