2008年2月16日

http://www.webhostidc.cn/web-design/30.html
開源的CMS基本上是php的天下，選擇時主要看授權模式，不過很多人不關心這個插件和模版的數量，開發社區是否活躍。有更多的人參與你才能源源不斷地獲得資源中文的支援系統需求，支援那些資料庫，這會影響對空間的選擇擴展性，不過不是所有的人都有能力和興趣自己做擴展。

Mambo 曼波

http://www.mamboserver.com/

http://www.mambors.org/

http://www.mamboforge.net

中文站點：

http://www.mambochina.net/

http://www.mambo.cn

Mambo是一個老牌的opensource建站程式，獲得過“最佳開源方案”，“年度最佳自由軟體專案”等很多獎， 國外比較熱門，但是在中國不夠熱，中文支援比較弱，中文資源相對來說不夠多。

Joomla 逐浪

http://www.joomla.org/

中文站點：

http://www.mambo.cn/

http://www.joomla.org.cn/

Mambo的分支，Mambo核心開發團隊另起爐灶的產品。，2005年度最佳Linux開放源碼系統獎(八卦來自bbs.joomla.org.cn)

曼波開源核心開發團隊致社區的公開信

致社區的公開信

--曼波開源核心開發團隊

越來越多的人關注曼波開源項目，曼波商會 ( Mambo Foundation Inc *) 應運而生，它的初衷是為了更好的發展曼波。我們，曼波核心開發團隊，一致認為：

1、所謂開源專案，是致力於開發一個免費的和開放源碼的軟體的人們，組成一個團隊而服務社會的行為。

2、開源專案體現協作精神，並享受協作過程帶來的樂趣。它存儲社區的資訊回饋，提供好的管理，允許商業機構放心地投資于它的開發。

開源專案對任何人都敞開大門，歡迎那些能貢獻價值和願意在社區一起工作的人加入。

我們，曼波開發團隊，認真關注曼波商會及其和社區的關係。我們堅信，曼波的未來，應該由使用者的需求以及開發者的能力所掌握。然而，曼波商會卻受Miro公司所控制，因此商會同社區之間的自由協作將變得不再現實。

1、曼波商會組建之初，並沒有聽取曼波核心開發團隊們的意見。我們、社區成員，對曼波的管理和未來的發展方向，沒有任何的發言權。由開發團隊組成的曼波籌委會和 Miro 公司的代表，聯合組成曼波商會，並成立第一屆理事會。但 Miro公司的CEO Peter Lamont完全將商會置於自己的控制之下，在沒有和開發團隊的兩名代表，Andrew Eddie和Brian Teeman商議的情況下，擅自任命了理事會成員。

2、儘管Lanmont先生向曼波籌委會許諾把Mambo的版權轉移給商會，但Miro公司現在拒絕這麼做。

我們將要做的是：在GNU規範下繼續開發和改善這個獲多項大獎的開源軟體。我們希望Miro公司及曼波商會一路走好，很遺憾，我們不能夠再和他們繼續合作。我們聽取了軟體自由法律中心關於這次事件的建議，將很快就近期發展計畫發佈更多的資訊。

2005年8月17日，曼波開發團隊：

Andrew Eddie

Emir Sakic

Andy Miller

Rey Gigataras

Mitch Pirtle

Tim Broeker

Alex Kempkens

Arno Zijlstra

Jean-Marie Simonet

Levis Bisson

Andy Stewart

Peter Russell

Brad Baker

Brian Teeman

Michelle Bisson

Trijnie Wanders

Rey Gigataras

Shayne Bartlett

Nick Annies

Johan Janssens

The name Joomla! is a phonetic spelling for the Swahili word "Jumla", which means "all together" or "as a whole"

Swahili -- 斯瓦希裏人，穆斯林民族中的主要一支，居住在東非從索馬里到莫三比克的沿海和島嶼上。斯瓦希裏語作為坦桑尼亞官方語言的斯瓦希裏班圖語，在東非或中東非被廣泛地用作通用交際語言。

 drupal

http://drupal.org/

Drupal模組功能一覽

http://www.verydummy.com/drupal_demo/node/8

一些Drupal中文網站供參考

http://www.todaylog.com/node/44

 PhpNuke

http://www.phpnuke.org/

中文站點：

http://www.postnuke.cn/

http://www.postnuke.ws/

老牌的CMS工具了，最早的php cms工具，用戶很多，能找到很多phpnuke搭建的中文站點。最新的版本是7.9，功能很豐富，社區也很活躍。

 postnuke

www.postnuke.com

中文站點：

http://www.postnuke.cn

phpnuke的分支，目標是在更少代碼，更少的伺服器負擔，更多模版地情況下實現phpNuke的功能，Postnuke在顯示上和php-nuke非常相似，但是postnuke功能更多。

XOOPS

http://sourceforge.net/projects/xoops

http://www.xoops.org/

中文站點：

http://xoops.org.cn/

PostNuke的分支，最近很流行，插件很多，中文支援得也不錯，模組組合的能力強大，wordpress，osCommerce, ipb等很多工具都可以整合成為XOOPS的模組。(www.xoops.org.cn/)

XOOPS - eXtensible Object Oriented Portal System, 面向物件的可擴展門戶系統XOOPS 框架穩定靈活，適應於web2.0 的各類功能的開發與集成，目前已經實現各類 RSS/ATOM 資源管理，集成 WordPress 等著名blog系統和各類wiki管理系統，並實現與 Flickr, Delicious, Technorati 等社會資源的互動。

 xaraya

http://www.xaraya.com/

中文站點：

http://zh.xaraya.com/

xaraya也是nuke系列發展起來的，基本擺脫了Nuke架構的束縛，架構上兼具 PostNuke/Drupal的優點，評價很高，模組開發潛力大，但是漢化進展緩慢更多的可以查看www.opensourcecms.com 。

dotnetnuke用過一段時間，已經決定放棄繼續使用了。

  2008年1月30日

• Overview

jquery gets a lot of its inspiration from the power behind the Prototype library. This is immediately noticeable with jquery's use of the $() function, inspired by the prototype function of the same name. However, there are some things that should be known about the prototype and jquery interact, and how the $() behaves differently.

Using prototype and jquery Together

To include both Javascript libraries, and have them work in unison, you will need to first include prototype, then jquery. For example:

  <script src="prototype.js"></script>

<script src="http://jquery.com/src/latest/"></script>

Loading jquery first, then prototype, will cause your code to break - as a reminder, jquery throws an exception saying: "You are overwriting jquery, please include jquery last." (If you see this error, that's what it means)

Differences in $()

A side-by-side comparison of how the $() function works *ONLY WHEN prototype IS USED* would be best to explain the differences. If you're not using prototype, please refer to the documentation, instead.

  $("pre")

prototype: Looks for the element with an ID of pre, if found, returns it, otherwise returns null.

jquery: Looks for all elements with the tag name of pre.

• If none are found: It then looks for an element with an ID of pre, if one is found - it returns that element, if not, it returns a jquery object, with an empty set of matched elements.
• If elements are found: jquery returns a jquery object, containing the all matched pre elements.

  $(DOMElement)

prototype: Returns the DOMElement.

jquery: Attaches all of the jquery object methods to the DOMElement, then returns it. The result should still be usable by prototype and jquery. Note: See the bottom of the page for more information on this.

What to do about $()?

Because the behavior of prototype and jquery is different, when it comes to the $() function, it is recommended that you do one of two things:

Un-ambiguous Selectors

Always be explicit when you search by a single ID. For example, use this:

  $("#pre")

and not this, which is ambiguous:

  $("pre")

Doing that will solve any problems straight away.

prototype Short-hand

If you want to continuing using the prototype short-hand, you must keep one rule in mind: Never name any of your IDs the same as a DOM Element type, otherwise you will have strange results. For example:

  $("pre")

would work, if there were no pre elements in the page, but once one was added, your code would break. A better example is:

  $("body")

which will always break (since the body element is required).

In a nutshell: Either use smart un-ambiguous !IDs, or don't name your !IDs the same as element names.

Wrapping of DOM Elements

In order to support both prototype and jquery users at the same time, returned DOM elements have additional jquery functions attached to them. It should be noted, however, that just because the original DOM Element is being returned, its original functions and properties should not be accessed directly, for example:

When using both prototype and jquery $("wrap") will return a modified DOM Element, so if you were inclined to do:

  $("wrap").style.display = 'none';

That would work, but only when using prototype. If you then, later, stopped using prototype, that code would break. To be safe, you should only use jquery-sanctioned functions and terminology, for example:

  $("#wrap").hide();

would be the proper way of doing the above - it will always work, even if you are (or aren't) using prototype.

Using prototype and jquery Together (other solution)

If you need use jquery and also prototype + Scriptaculous + ... , you need rename jquery $ function. For example:

 <script src="http://jquery.com/src/latest/"></script>

<script type="text/javascript">

JQ = $;  //rename $ function

</script>

<script src="prototype.js"></script>

Then you can access to jquery function with JQ and for access to prototype $ function use the normal name. For example:

 <script type="text/javascript">

JQ(document).ready(function(){

JQ("#test_jquery").html("this is jquery");

$("test_prototype").innerHTML="this is prototype";

});

</script>

NOTE: Be carefull with jquery plugins, you will need rename all $ references to JQ or other name.

  2008年1月26日

By Michael

转自：Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1860317

　　1，静态:就是为每种语言分别准备一套页面文件，要么通过文件后缀名来区分不同语言，要么通过子目录来区分不同语言。

　 　例如对于首页文件index_en.htm提供英语界面，index_gb.htm提供简体中文界面，index_big.htm提供繁体中文界面，或 者是 en/index.htm提供英语界面，gb/index.htm提供简体中文界面，big/index.htm提供繁体中文界面，一旦用户选择了需要的 语言后，自动跳转到相应的页面，首页以下其他链接也是按照同样方式处理。从维护的角度来看，通过子目录比通过文件后缀名来区分不同语言版本显得要简单明 了。

　　2，动态:站点内所有页面文件都是动态页面文件(PHP，ASP等)而不是静态页面文件，在需要输出语言文字的地方统一采用语言变量来表示，这些语言变量可以根据用户选择不同的语言赋予不同的值，从而能够实现在不同的语言环境下输出不同的文字。

　　例如:语言变量ln_name，当用户选择的语言是英语时赋值为“Name”，当用户选择的语言是简体中文时赋值为“姓名”，这样就可以适应不同语言时的输出。

　　采用静态方式的优点是页面直接输出到客户端，不需要在服务器上运行，占用服务器的资源比较少，系统能够支持的并发连接数较多，缺点是要为每种语言制作一套页面文件，很多内容即使是和语言无关的也要分不同语言来存储，因此占用的存储空间较多。

　 　采用动态方式和静态方式的优缺点正好相反，它的优点是动态页面文件只有一套，不同语言的文字使用语言变量来存储，和语言无关的内容只存储一份，占用的存 储空间较少，并且扩展新语言比较容易，缺点需要在服务器上运行，然后把结果输入到客户端，占用服务器的资源比较多，系统能够支持的并发连接数较少。

　　动态数据存贮涉及的一些技术问题

　　由于现在网站上动态应用日益增多，相当多的网站还会使用文件或者数据库来存储应用信息，因此如果文件或者数据库中存储的内容与语言相关时，还需要特别注意。对于存储在数据库中信息，可以采取以下几种方式支持多语言:

　　1，在数据库级别支持多语言:为每种语言建立独立的数据库，不同语言的用户操作不同的数据库。

　　2，在表级别支持多语言:为每种语言建立独立的表，不同语言的用户操作不同的表，但是它们在同一个数据库中。

　　3，在字段级别支持多语言:在同一个表中为每种语言建立独立的字段，不同语言的用户操作不同的字段，它们在同一个表中。

　　由于数据库中有大量的信息(如标志，编码，数字等)是用于内部处理使用的，与语言无关的，因此在数据库级别支持多语言会导致空间的极大浪费，在字段级别支持多语言最大的问题是一旦需要支持新的语言，由于需要修改表结构，维护起来非常麻烦，可扩展性不好。

　 　相比之下，在表级别支持多语言比较好，因为并不是所有的表都需要支持多语言，对于与语言无关的表，不同语言的用户共用一套，那些和语言相关的表根据支持 语言的种类来建立，不同语言的用户存取访问不同的表格。这样使得维护简单，节省了存储空间，即使是扩展起来也比较方便，只要把需要支持多语言的表，多建立 一套即可。

　　还需要注意的问题是:有些表中某些字段是不同语言版本的表共享的(例如库存量)，由于各种语言的表之间的相对独立性，使得数据共享有些困难。解决的方法有两个:

　　1，不同语言的表的共享字段同步:也就是说，只要修改了其中一个表的共享字段，其他语言表中该字段也作相应改变，实际上当不同语言的用户同时访问时处理还是比较麻烦的，并且扩充新语言时修改工作比较大。

　　2，增加一个新的表:把所有语言共享的字段(例如货物编号，产地编码等)全部放在这个表，支持多语言的表只存放与各种语言相关的字段。不同语言的用户在使用数据库时，需要操作两个数据表。

　　比较而言，第二种方法比较简单，并且效率比较高，维护也比较方便。

　　应用字符集的选择

　　一个定位于不同语言国家的企业网站势必需要提供多种语言版本的产品和销售信息来满足其世界各地使用不同语言的客户和合作伙伴，其中包括法语、德语、意大利语、葡萄牙语、西班牙语、阿拉伯语等等。但有一个问题却极易被网站设计者们所忽略。这就是网站的字符集设置问题。

　　一般我们使用的是简体中文(GB2312)字符集，而对多语言网站来说，中文字符集却可能会使你辛辛苦苦的努力功亏一篑。原因很简单:就是这个毫不起眼的小小字符集在作怪。

　　计算机应用领域中存在着几十种互不相同的字符集，而不同语言客户在浏览不同语言网页时，往往会因为相互间所使用字符集无法兼容而出现乱码情况。我们在浏览国外一些网站时，往往也会出现为了能正常地看到网站上的信息而不得不在各种字符集之间来回切换的情况。

　 　试想一下:如果一个网站提供了中，英，法，德等多种语言版本的内容，内容全之又全，设计美仑美奂。我们在中文编码环境下浏览这些非中文版本的页面觉得非 常完美，现在一个法国客户对你的产品发生了兴趣，当他进到法语版面一看—乱码多多，甚至可能整个版面都一塌里糊涂。你的网站再下大工夫又有什么意义呢?

　 　所以对提供了多语言版本的网站来说，Unicode字符集应该是最理想的选择。它是一种双字节编码机制的字符集，不管是东方文字还是西方文字，在 Unicode中一律用两个字节来表示，因而至少可以定义65536个不同的字符，几乎可以涵盖世界上目前所有通用的语言的每一种字符。所以在设计和开发 多语言网站时，一定要注意先把非中文页面的字符集定义为“utf-8”格式。

　　这一步非常重要，原因在于若等页面做好之后再更改字符集设置，可说是一件非常非常吃力不讨好的工作，有时候甚至可能需要从头再来，重新输入网站的文字内容。

　　HTML中的META标签:

　　<META HTTP-EQUIV=“Content-Type” CONTENT=“text/html; CHARSET=字符集">

　　不写，根据浏览器默认字符集显示

　　charset=gb2312 简体中文

　　charset=big5 繁体中文

　　charset=EUC_KR 韩语

　　charset=Shift_JIS 或 EUC_JP 日语

　　charset= KOI8-R / Windows-1251 俄语

　　charset=iso-8859-1 西欧语系(荷兰语,英语,法语,德语,意大利语,挪威语,葡萄牙语,瑞士语.等十八种语言)charset=iso-8859-2 中欧语系

　　charset=iso-8859-5 斯拉夫语系(保加利亚语,Byelorussian语,马其顿语,俄语,塞尔维亚语,乌克兰语等)

　　charset=uft-8 unicode多语言

Powered by:
博客园
Copyright ©2008 睿枫