如何使用 JSP 创建动态网页,部署后可以修改页面而无需再次重新部署?

发布于 2024-10-17 19:56:05 字数 890 浏览 1 评论 0原文

我对一个项目有一个要求,要求 JSP 中的特定页面在 EAR 并部署到服务器后能够动态更改其内容。客户不希望必须对代码进行更改以向页面添加一些内容,然后通过昂贵的提升来查看生产中的更改。

用例:客户有一个“联系我们”页面,其中有四个表单设置,其中包含 jQuery Accordian、“常规”、“付款”、“索赔”和“支持”。部署后一段时间后,客户希望轻松快速地向部署的页面添加“欺诈”表单。

使用的技术:

  • JSP
  • Struts2
  • jQuery
  • Spring

我是一个相对较新的程序员,所以我没有很多使用 Web 技术和最佳实践的经验,但我确实知道如何开始(无论这是否是可行的方法)。

  1. 使用数据库,将主题和路径/URL 等信息存储到可以为 jQuery Accordian 的每个面板显示的其他 HTML 页面。
  2. 使用 Struts2 迭代标签并利用 Struts2 Actions(此时利用 Java),从数据库中检索信息,并通过迭代并生成包含内容的标头和 div 来动态构建表单;内容来自存储在与部署的项目不同的位置的单独 HTML 文件,例如存储在 NAS 设备上......或其他方式。

我最初的想法是,当需要添加新表单时,可以制作一个简单的 HTML 页面并将其放在存储位置,然后可以根据表单的主题以及在哪里找到它来相应地更新数据库。页面加载时,将访问数据库以获取要加载的所有主题和 URL/路径的列表,从而使设置在将来需要添加新主题或修改/删除现有主题时变得非常灵活。

这完全脱离了墙壁吗?是否有更好的方法来做到这一点,或者实现这种类型的灵活性最终会比修改代码并完成步骤以将更新的版本再次投入生产更加痛苦?任何帮助、想法或见解将不胜感激!

I have requirements for a project that require that a particular page in JSP be able to have its content dynamically altered after being EARed up and deployed to a server. The client does not want to have to make changes to the code to add some content to the page and then go through an expensive elevation to see the changes in production.

Use case: Client has a Contact Us page that has four forms setup with a jQuery Accordian, "General", "Payments", "Claims", and "Support". After deployment and some time later, the client would like to add a "Fraud" form to the deployed page easily and quickly.

Technologies in use:

  • JSP
  • Struts2
  • jQuery
  • Spring

I'm a relatively new programmer, so I don't have a lot of experience working with web technologies and best practices, but I did have an idea of how to start (whether this is a viable method or not).

  1. Using a database, store information such as the topic and path/URL to additional HTML pages that could be displayed for each panel of the jQuery Accordian.
  2. Using the Struts2 iteration tag and taking advantage of the Struts2 Actions (Leverage Java at this point), retrieve the information from the database and dynamically build the forms by iterating through and generating headers and divs containing the content; the content being from separate HTML files stored at a different location than the deployed project such as on a NAS device... or some other means.

My initial thoughts were that when new forms needed to be added, a simple HTML page could be made and put at a storage location and then the database could be updated accordingly with the topic of the form and where to find it. On page load, the database would be hit for a listing of all topics and urls/paths to load thus making the setup quite flexible for the future when new topics need to be added or existing topics modified/removed.

Is this completely off the wall? Is there a better method of doing this or is implementing this type of flexibility ultimately more of a pain then just modifying the code and going through the steps to get the updated version placed in production again? Any help, ideas, or insight would be most appreciated!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

寒冷纷飞旳雪 2024-10-24 19:56:05

策略:

1) 创建一个公共测试环境,让客户看到所做的更改。如果您当前没有这样做,您可能需要研究一些事情:

  • 动态类重新加载(无需编译和重新部署!嗯,有......但它会自动发生,并且通常足够快,您可以获得动态语言的典型部署)
  • 创建一个ftp挂载来直接编辑公共测试系统的jsps。

2) 运行 xwiki(一个优秀的 FOSS Java EE wiki)之类的东西,并让它处理您的动态文档需求。任何满足一般需求的 CMS 可能都比手工制作的 CMS 更好,除非您非常认真。然后让您的应用程序专注于成为一个应用程序,然后由 CMS 来装饰它。

Wiki 很棒,因为您可以使文档流程具有协作性。

Couple strategies:

1) Create a public testing environment letting the client see the changes as they are made. Some things you might want to look into if you're not currently doing so:

  • dynamic class reloading (no need to compile and redeploy! Well there is... but it happens automatically and generally quickly enough you get the deployment typical of dynamic languages)
  • creating an ftp mount to directly edit the public test system's jsps.

2) Get something like xwiki (an excellent FOSS Java EE wiki) running and have it handle your dynamic document needs. Any CMS for general needs is probably better than a hand rolled one, unless you're very serious. Then let your application focus on being an application and the CMS dress it up.

Wikis are wonderful because you can make the documentation process collaborative.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文