⑴ liferay portal6.1門戶網站建設最佳實戰怎麼樣
您好，很高興能幫助您，
功能要求：a.單點登錄。b.系統集成。c.自定義樣式。d.信息發布。e.搜索(對於OA，實現起來還是有點為大現實)。
b.系統集成：
系統集成主要有以下幾種方式：
1、iframe:利用liferay自帶的iframe portlet可以直接把其它的web系統以url的形式集成進來，不過這裡面會出現session丟失的問題。iframe中的系統在執行Login操作的後，習慣性的選擇redirect操作，這樣會強制瀏覽器中的顯示地址變更為轉移的地址。事實上這是個很正確的做法，在正常境況下，不會有任何問題，而且還可以很好的防止頁面刷新等所帶來的問題。
你的採納是我前進的動力，還有不懂的地方，請你繼續「追問」！
如你還有別的問題，可另外向我求助；答題不易，互相理解，互相幫助！
⑵ liferay 是什麼
Liferay的企業門戶是一個自由和開放源碼的 企業門戶寫在爪哇和分布式根據GNU通用公共許可證 。 [1]它主要用於電力企業內部網和外部網，並提供強大的企業功能，包括系統支持外部文件管理，LDAP集成，社會的工具，和wiki。
Liferay的Portal允許用戶方便地設置常用的網站強大的功能。 它來了，出來的飼料箱用戶注冊，驗證碼，文檔庫，Lucene的檢索，維基，社會新聞聊天，等等。 [2]門戶系統是建立在portlet的 ，因此，有許多協力黨的社會貢獻的插件和插件。 Portlets允許用戶添加新的功能或自定義Liferay的行為和外觀。 由於此插件可擴展性和模塊化設計，Liferay是有時稱為內容管理框架或一個Web應用框架 。 Liferay的插件支持擴展到多種編程語言，包括支持的PHP和紅寶石的portlet。 [3]
雖然Liferay的開發人員提供了一個復雜的編程介面，無需編程技能都需要安裝和管理的基本網站。
Liferay的Portal是基於Java上運行的任何計算平台能夠運行的Java運行環境和應用伺服器 。 Liferay是可作為捆綁的應用伺服器，例如Apache Tomcat的
歷史
Liferay的公司是一家專業的開源公司，提供專業的免費文件和有償服務，軟體用戶的。 主要對重點企業門戶技術，該公司已經在總部洛杉磯 ，加利福尼亞州，美國。
創建於2000年Liferay的由首席軟體設計師布賴恩陳提供的企業門戶的解決方案， 非營利性組織 。 [5] 2004年，該公司注冊成立公司的名義下Liferay的，其德國子公司正式Liferay的股份有限公司。 2007年，公司開辟了新的亞洲總部在大連 ，中國和西班牙的子公司Liferay的sl的。 2009年3月，公司開辟了新的辦公室在班加羅爾 ，印度。
該公司的企業門戶產品已經承認幾個顯著的組織。 這是公認的電子內容的雜志在其「電子內容100」領導人名單的行業[6] [7] ，2007年InfoWorld的命名，「這是」科技的新年。 [8] 2007年7月，他們宣布ICEsoft夥伴關系技術，提供的ICEfaces的庫，用於開發的Ajax的技術企業門戶軟體[9] 。 2008年1月，公司聘請的工程師帶領jQuery的用戶界面，工作時間獨家全JavaScript庫 。 [10] 2008年Gartner的認可Liferay的9月作為有遠見的領導者象限的水平門戶產品。 [11]
Sun微系統和Liferay分享協議簽署2008年5月一個技術。 [12] 。 Sun微系統公司更名發行GlassFish的網路空間伺服器 。 ZDNET.UK進一步描述了平台的關系在2008年5月文章太陽和Liferay推出網上演示 。 [13]
2009年10月宣布了一項Liferay的夥伴關系的技術提供商與IT廠有限公司， Vaadin捆綁它與未來Liferay的版本的用戶界面庫。 [14]
[ 編輯 ]產品
Liferay的Portal是一個的JSR - 286 企業門戶 ，其中包括一個應用套件（例如， 內容管理系統 ， 博客 ， 即時通訊 ， 留言板等）。 這是分布在兩個不同的版本：
Liferay門戶社區版 -社區版本與最新的功能和支持，通過積極的。
Liferay門戶企業版 -一個商業產品，包括支援服務，包括更新和充實。 此版本經過附加的質量保證周期，通常在社區版後的1或2個月內推出。
Liferay的協作套件還提供了一個平台上的Liferay的基礎：
Liferay的社會辦公室 -一間套房，為企業社會協作
真是..發個鏈接都不行,我消息你吧
⑶ 什麼是LIFERAY
代表了完整的J2EE應用，使用了Web、EJB以及JMS等技術，特別是其前台界面部分使用Struts 框架技術，基於XML的portlet配置文件可以自由地動態擴展，使用了Web Services來支持一些遠程信息的獲取，使用 Apahce Lucene實現全文檢索功能。
主要特點：
1、提供單一登陸介面，多認證模式（LDAP或SQL）;
2、管理員能通過用戶界面輕松管理用戶，組，角色；
3、用戶能可以根據需要定製個性化的portal layout;
4、能夠在主流的J2EE應用伺服器上運行，如JBoss+Jetty/Tomcat,JOnAS；
5、支持主流的資料庫，如PostgreSQL,MySQL；
6、使用了第三放的開源項目，如Hibernate, Lucene, Struts；
7、支持包括中文在內的多種語言；
8、採用最先進的技術 Java, EJB, JMS, SOAP, XML；
⑷ 調試實戰：判斷Liferay中編輯WebContent 時使用何種富文本編輯器分析 ，順便分享下頁面調試經驗
這個控制項是如何被集成在我們的頁面中的呢？這是我們要解決的問題。調試分析：我們還是從原點開始，（小插曲：這也受益於我中學時代數學老師的教的一句話，學習就是用已知的東西解釋未知的東西，而學習的過程就是建立從已知知識到未知知識的橋梁，要讓A->B的每一步都滿足A是B的充分條件，而不要想當然，只有這樣，知識體系結構才足夠牢固）我們肯定從頁面點擊開始，當點擊下圖中圖標按鈕最右邊那個帶綠色加號的圖標時：它會發出如下請求，我們可以從web工具中看出來，這個對應請求參數的struts_action是/journal/edit_article所以我們去struts-config.xml中去找action mapping:這里可以看到，它會把請求轉發到portlet.journal.edit_article 這個key對應的頁面中：我們去tiles-def.xml中找到這個key 對應的頁面，結果是edit_article.jsp因為我們的目標是富文本編輯器，所以我們必須在edit_article.jsp中找到對應的代碼，我一看這個頁面，傻眼了，它全是用的自定義標記寫的，要看內容我不得不單獨調試標記對應的java代碼。 而且這裡面充斥著scriptlet，所以我很難直接命中代碼片段。我只能用排除法。顯然，在頁面上"New Web Content"對應的從Web調試器返回的代碼是：
它一定滿足以下代碼(edit_article.jsp的第173行）：而這個<table>元素從第173行一直延伸到了第311行，所以我們的目標代碼就在這從173-311行這些代碼之間。（旁白：這就是縮小目標范圍，也是警察甄別犯罪嫌疑人的常用方法）但是這段代碼非常復雜，各種邏輯判斷，我用肉眼已經沒辦法准確的判斷走的流程了，只能藉助調試器了。首先，調試器在第88行到第93行會去獲取當前languageId，這里是"en_US", 然後toLanguageId為""然後當運行到第107行mainSections時候，我眼前一亮，因為以往經驗，為了讓jsp片斷能更好的重用，多數是以section的形式來存放一個一個小的頁面片斷的，稍微初級點的人一般會在頁面上用N個 jsp:include來引入這些頁面片斷，稍微高級點的人則會定義一個頁面片斷數組，然後把所有片斷頁面的名字都存放在這個數組中，至少我以前經常這么做，所以感覺很熟悉。結果果然和我猜想一致（旁白：果然經驗和感覺很重要啊）因為我們是點「綠色加號」頁面圖標進來的，所以它的mainSections的取值就是上圖第107行的PropsValues.JOURNAL_ARTICLE_FORM_ADD指定的值，我們去portal.properties中找，果然找到了，而且從注釋上看也證實了我們的猜想：結合調試信息：所以我們確定，要在這里添加多個jsp片斷的內容，包括content.jsp,abstract.jsp等。並且categorySections：然後因為我們的toLanguageId為"",所以符合第281行的條件Validator.isNull(toLanguageId)==true：所以我們斷定，這個標記對應的jsp片斷就是應該包含若干jsp頁面，它要包含的頁面名字數組放在剛才生成的categorySections，而頁面的路徑應該是jspPath指定的路徑，我們現在來證明這個猜想：為此，我們去liferay-ui.tld中找到這個標記對應的處理類：所以，它對應的標記處理類是FormNavigatorTag類：
而這個類的getPage()方法會吧頁面轉到/html/taglib/ui/form_navigator/page.jsp中：我們看到，它會在第48行循環的吧所有的sectionJsp從傳入的categorySections入參中讀取出來,，然後分別拼接頁面路徑前綴(jspPath),最後在第56行，分別包含這些頁面內容插入到當前頁面中。因為我們剛才已經分析了，這些頁面列表都在categorySection入參中，而jspPath前綴也傳遞進來，叫/html/portlet/journal/article,所以一切謎底都解開了，他們會從webapps/ROOT/html/portlet/journal/article中吧相應的頁面片斷包含進來。我們現在來看第一個頁面content.jsp，這個頁面還是比較簡單的， 它是一個典型的自頂向下結構：
結合頁面很容易就把每塊區域和對應的代碼聯系起來：其中Structure:Default 和Template: None 這些所在的容器對應的是conent.jsp第211行的article-structure-template-toolbar接下來Default language:所在的容器對應的是content.jsp第347行article-translation-toolbar接下來Title(Required)所在容器對應的是content.jsp第480行journal-article-general-fields：接下來的Content以及富文本編輯器對應的是content.jsp的第488行journal-article-container:很快的， 我們就在journal-article-container下面找到了富文本編輯器對應的代碼，它也是用liferay-ui標記庫中的標記寫的：為此，我們又回到liferay-ui.tld中找input-editor對應的標記處理類為InputEditorTag：從InputEditorTag類的調試信息中，我們終於發現，它使用ckeditor作為富文本編輯器的內容：（長嘆一下:終於找到目標了）從調試信息中看到，它會在108行包含一個頁面叫/html/js/editor/ckeditor.jsp。我們進入這個頁面繼續調試後發現，這個ckeditor使用的配置信息(存於變數ckeditorConfigFileName中）位於文件ckconfig.jsp中：稍微瞄了一眼ckconfig.jsp，發現它提供了ckeditor很多配置參數包括定製顯示的按鈕，甚至包括樣式，這也能解釋為什麼我們看到的ckeditor和我們看到原版的有一定的區別.第62-68行定義了ckeditor的主要樣式，讓其絕對定位：然後第74行指定了ckeditor控制項的具體呈現，原來它是封裝在一段叫ckeditor.js的javascript代碼中的，它的路徑在/html/js/editor/ckeditor/ckeditor.js中最後，在我們用ckeditor編輯完文章後，liferay會自動收集這個控制項產生的內容和數據，並且進一步處理。
總結：頁面調試經驗：我從事框架研究，架構很多年了，雖然自己沒怎麼寫過jsp頁面:)。我看過很多同事，對於這種復雜頁面嵌套頁面的調試，他們的做法是：直接打開Firebug然後對照Dom樹去找對應的jsp文件，但是這樣效果不好，一來是現在主流網站多數用了很多前端框架，比如tile框架，還大量使用自定義標記庫，jstl等，所以你很難直接從最終的Dom找到對應的jsp片斷來滿足你要求。二來是這樣泛搜經常搜不到結果或者搜到很多結果，你無法判斷到底哪個片斷才是你所需要的， 也許這些片斷彼此都很相似。我的經驗是：對於簡單的，你直接一目瞭然就可以看到頁面，頁幀的嵌套包含關系，那麼只要go-through一下就可以了，但是對於復雜的，尤其是頁面中嵌套許多<c:if><c:choose>這種分支，判斷的，你也許無法直接判斷走那個分支，那麼必須通過調試器。java調試工具對於jsp頁面的調試支持並不完美，但是至少其中的scriptlet和expression部分是可以敲斷點調試的，而條件分支，判斷，循環中用到的變數值往往來自於這些scriptlet和 expression，所以知道這些代碼段中出現的變數的值可以幫助我們正確的選擇分支。還有就是如果頁面很亂很雜，那麼就可以先盡量排除不想干代碼，而把目標代碼局限在很小的范圍中，然後斷點打的細一點，就很容易搞定了。在我寫著文章時候，雖然我猜想可能是用ckeditor,但我沒查證過，我完全是邊寫博客邊調試，然後結果就自動出來了。本文中的知識：本文其實大多數我的篇幅都是在如何進行調試和從各種復雜文件包含，引入中准確定位我們的目標的。
⑸ liferay是怎樣配置到哪個具體tomcat伺服器上的
把服務部署到tomcat上有多種方法，有的直接把編譯後的應用拷貝到tomcat的webapps目錄下面，有的是導出成.war文件拷貝到webapps下面，這樣的話啟動tomcat會自動生成一個同名的應用文件夾裡面會有tomcat解壓後的應用目錄，還有些不用拷貝到webapps目錄下，通過tomcat的server配置指定任意的文件夾為web應用的發布目錄。基本上目錄結構是這樣的，首先根目錄就是以你的項目名稱命名的文件夾，根目錄下面會有各種前台展示相關的代碼文件，比方說包含jsp文件、css文件、js文件、image文件等前台展示相關的文件夾或文件都可以放在根目錄下面，根目錄下面還有一個WEB-INF文件夾，該文件夾下是一些應用配置文件：web.xml、應用庫文件夾lib文件夾該文件夾下是應用用到的一些第三方jar包、應用編譯文件夾：class，該文件夾下是你的應用開發中的src目錄下面的所有java文件或者其他配置文件的編譯後的文件目錄，目錄結構跟你的開發src目錄結構一致。
⑹ liferay 是什麼
liferay是個開源的門戶平台，它主要面向企業提供其內部的web內容發布、內容、集成和協作的解決方案。與新浪、搜狐等門戶網站從面向用戶到業務范圍都不相同。
⑺ liferay 怎麼進行二次開發
當系統開發完成，部署實施上線時，需要初始化大量的用戶數據，如果一個個的錄入，數據量少時還好，如果數據量比較大，還是讓人很崩潰的。此時，我們可以使用Liferay的API進行用戶的導入，Liferay本身並沒有提供CSV或EXCEL的用戶導入方法，需要我們有一定的二次開發。
導入的方法大概有幾種：
（注意：本文的說明是基於Liferay6.2.1的版本，其他版本可能稍有差異）
1、LDAP的導入，就是我們在的用戶在LDAP中，讓Liferay從LDAP中自動導入，這樣的方法，可以參考前面的文章《Liferay 6開發學習（二十七）：OpenLDAP與Liferay的集成》；
2、我們Liferay中寫一個Portlet，調用Liferay的API進行導入。
3、我們在遠程或者另外獨立的工程中，調用Liferay的WebService介面進行導入。
寫Portlet進行導入
只所以要建立一個Portlet，是因為我們在Portlet裡面可以方便的調用Liferay的API，新建一個Portlet工程或者添加一個Portlet。調用下面的方法進行添加。
UserServiceUtil.addUser(companyId, autoPassword, password1, password2, autoScreenName, screenName, emailAddress, facebookId, openId, locale, firstName, middleName, lastName, prefixId, suffixId, male, birthdayMonth, birthdayDay, birthdayYear, jobTitle, groupIds, organizationIds, roleIds, userGroupIds, sendEmail, serviceContext)
說明：
1、添加時請保證使用超級管理員帳號登錄，不然會可能會提示許可權不足。
2、上面的companyId，可以從上下文件中使用PortalUtil.getCompanyId(request)獲取。
3、autoPassword，一般設置為false。為true時，會自動的生成密碼。
4、password1,和password2，就是密碼，保持一致即可。
5、autoScreenName，一般為false;
6、screenName，屏幕名稱，一般是字母和數字的組合，默認不能為全數字，如果要讓他支持全數字，可以添加users.screen.name.allow.numeric=true，的配置到Portal-ext.properties文件中。
7、emailAddress，默認郵件地址為必填項，如果用戶中沒有郵件地址，則可以在後台中添加配置， users.email.address.required=false，設置為郵件地址為非必須。此時emailAddress可以傳空值，否則會報錯。
8、facebookId,openId等，這些一般沒用，我們傳值是可以facebookId傳0l（facebookId為long類型）,openId傳""；
9、local，根據具體的情況吧，這個地方來存的是用戶的語言項和時區，國內的一般可以使用固定值，或者是從request裡面取，PortalUtil.getLocale(request);
10、firstName, middleName, lastName這幾個值，很明顯。一般是firstName為必值，其他幾個可以傳空。根據實際情況來傳吧。
11、 prefixId, suffixId，前綴和後綴。國內我們一般都不用這些的，傳值都傳0即可。
12、male：是否是男性，傳true或false;
13、birthdayMonth, birthdayDay, birthdayYear：生日的月、日、年，int類型，根據情況傳，如果沒有，可以傳成1，1，1970.
14、jobTitle，職稱等，根據情況傳，沒有的話傳「」；
15、�0�2groupIds, organizationIds, roleIds, userGroupIds：long類型的數級，分別為當前用戶屬於的站點、組織機構、角色、用戶組等，如果不需要可以傳null，如果有需要傳long類型的數級，裡面的值為相應的站點ID，組織機構ID等。如果不是以管理員賬號登錄，此處傳值的話（傳null不會），可能會出現許可權錯誤。
16、sendEmail，是否給用戶發郵件，根據情況來定吧，一般為false。
17、serviceContext，可以從上下文件中取ServiceContext serviceContext = ServiceContextFactory.getInstance(request);
特殊情況
比如現在有一個場景，是我們自己寫一個用戶的注冊界面，又想在這個注冊後就關聯上相應的站點或組織機構，上面的介面必須要有許可權才能添加，如何繞過相應的許可權呢？調用下面的這個API。
UserLocalServiceUtil.addUserWithWorkflow(creatorUserId, companyId, autoPassword, password1, password2, autoScreenName, screenName, emailAddress, facebookId, openId, locale, firstName, middleName, lastName, prefixId, suffixId, male, birthdayMonth, birthdayDay, birthdayYear, jobTitle, groupIds, organizationIds, roleIds, userGroupIds, sendEmail, serviceContext)
這個API和上面的相比多一個參數，也就是第一個參數，創建的用戶ID，這里可以傳defaultUser.getUserId()。
User defaultUser = UserLocalServiceUtil.getDefaultUser(companyId);
其他的參數和上面的沒有差別，用這個方法添加站點等時，不會再要有相應的許可權。