我們有一些JSP代碼可以在我們的頁面中運行。JSP/HTML UI設計
有一個UI設計師將不斷更新用戶界面，但沒有Tomcat服務器。我們更喜歡他並不是因爲他不是程序員。
但是，每次更新UI時都必須剪下和粘貼JSP相關代碼，這讓人很煩。
無論如何要處理這個問題？我們更喜歡保留相同的文件，但仍然擁有它，這樣他就可以看到他的UI工作而不用擔心JSP，並且當他檢查新文件時，我們不必剪切和粘貼我們的JSP相關代碼。
這樣的代碼的一個例子是有某些導航菜單項根據用戶顯示。
我們正在使用Tomcat身份驗證。我們可以使用AJAX來獲取用戶信息，但安全性較低？應用程序中的其他所有內容都是AJAX。
這裏的問題在於這個人沒有與團隊合作。相反，他正在爲他們創造工作......而且這是雙向的。請繼續閱讀。
我都做和管理前端開發。如果這個UI人員在我的團隊中，我會強迫他建立一個Tomcat服務器。他只需要學習一些東西。
實際上，當正確實施時，JSP與任何其他服務器端視圖標記語言（例如Rails + ERB，PHP，.NET等）沒有多大區別......甚至Javascript模板引擎（小鬍子，把手，等等。）。相同的條件檢查，for循環，auth檢查 - 所需的所有基本視圖層邏輯都可用且可用。
如果他在Java項目/團隊中，他需要學習Java前端。就這麼簡單。
他的主要任務應該是基本的，坦率地說，他甚至不需要安裝Java IDE來完成它們。它們是：
（*）最後一部分是事情變得棘手的地方。如果您直接在正在運行的服務器上工作，然後在複製更新之前意外運行新的部署，那麼就搞砸了。如果您使用符號鏈接（在Windows中也可用），則可能存在僅在編譯後出現的文件，或鎖定或在獲取最新代碼時同步問題 - 這些都會產生問題。
我已經找到了最好的工作方式是對代碼回購位置（預編譯）工作，並創建兩個腳本：
這就是說，它現在應該是顯而易見的：Java是最困難的生態系統，開發UI對之一。編譯後的自然環境和複雜的環境要求使開發變得緩慢乏味，並且對不同的人員或系統有着顯着的依賴性，從而製作出體面的產品。
JSP本身，而能夠如上所述，幾乎總是組織得厲害，有包括各種方式，標籤文件，諧音，框架 - 它成爲一個UI人的噩夢。 GSP（來自Grails）解決了很多組織問題，但需要開發團隊的靈活性。即使那樣它也不是一個「理想」的解決方案。
JSP語法 - JSTL，C：標籤等造成更大的麻煩。不編程的前端人員不使用IDE，因此在編寫或自定義條件邏輯或循環時沒有查找方法，對象，參數等的方法。開發團隊可以通過在頁面上預先寫出這些信息來提供幫助，但每當需要更改或增強時，都需要開會，交談和妥協。
從長遠來看，你應該從抽象的獨立，更靈活，更強大的前端技術棧的Java應用程序，使用REST /基於JSON的服務，兩者之間的交談。 （注意：對於具有縮放的性能/應用程序，請確保您使用的是自定義協議或Web套接字）。
我的選擇是node.js的，因爲前端開發人員可以用他們最熟悉的語言堅持：的JavaScript/JSON。但它可能是你的特定前線球員感到舒適並且可以進行設計的任何東西。
的關鍵是要消除在兩個前端和後端的瓶頸。這兩個軌道應該能夠快速開發和迭代，RESTFUL API是協作的關鍵點。
最後，對於那些你誰是有抱負的前端開發/設計，但只知道Java（或其他一些服務器端技術），我挑戰你學到新的東西。面向用戶的技術處於持續變化的狀態，最近這種變化已經加速。如果你想擁有用戶界面競爭力的產品，你需要投資於能夠使其具有競爭力的技術。
問題是關於推動設計更改或有關登錄AJAX的安全性的問題？ – 2013-03-11 19:01:48
如果他在前端工作，他需要站穩腳跟並保持當地的環境，並學習一些JSP/JSTL，如果這就是他目前正在使用的東西。從長遠來看，對他（和你們）來說會更好。 – prodigitalson 2013-03-11 19:02:58
你們都可以包括（他在SSI中的SSI，你的JSP：包括）拉動靜態HTML文件。 他的Apache設置可能有一個靜態包裝器，其中包含一個硬編碼版本的JSP代碼。然後，他會在自己的文件中編輯HTML代碼片段，這樣可以按原樣使用。 雖然這是一個妥協。正如ProDigitalSon所說，最好讓他習慣於使用JSP。任何值得他的鹽的前端開發人員都不應該有問題。 – anotherdave 2013-03-11 19:09:50