访问和使用数据库中的 .jsf 文件
使我的 Web 应用程序能够使用数据库中存储的 JSF 文件的最佳方法是什么? 我希望能够动态(在运行时)创建新的 JSF 页面,无需重新部署应用程序即可使用该页面。
换句话说:我希望将 JSF 页面的大部分存储在数据库中,并希望 JSF 使用该数据库作为获取 JSF 文件的数据源。
我思考了很长时间的解决方案并找到了一些可能的方法。然而,我还没有能够实现它们中的任何一个。
- 每当需要添加/删除新页面时: 操作类路径中的文件(例如,删除或添加文件到 .war 文件)
- 扩展 Web 应用程序的类路径,以便能够从运行时定义的位置获取文件(即/tmp或直接使用数据库连接)
- 为JSF提供另一种方式查找资源的方法(这似乎不可能?)
我的环境:
- Java SE 6
- Jetty作为servlet容器
- Mojarra作为jsf实现
现在,我的问题:
是否有人可以让 JSF 在默认类路径以外的位置(最好是数据库)查找页面?
非常感谢您的任何回复!
What is the best way to enable my webapplication to use JSF files stored in the database?
I'd like to be able to dynamically (during runtime) create new JSF pages which will be made available without having to redeploy the application.
So in other words: I would like to store the bigger part of my JSF pages in the database and would like JSF to use the database as a datasource for getting JSF files.
I've thought long about a solution and found some possible ways. However, I haven't been able to implement either of them.
- Whenever a new page has to be added/removed: manipulate the files in the classpath (e.g. remove or add a file to the .war file)
- Extending the classpath of the webapplication so it will be able to get files from an at runtime defined location (i.e. /tmp or directly using a database connection)
- Provide JSF with a way to find resources another way ( this doesn't seem possible? )
My environment:
- Java SE 6
- Jetty as servlet container
- Mojarra as jsf implementation
Now, my question:
Is it possible for someone to let JSF find pages at a location other than the default classpath, preferably the database?
Any response is greatly appreciated!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果 WAR 已扩展,这绝对是可能的。我不确定 Jetty,但它适用于 Tomcat 7 和 Glassfish 3 上的 Mojarra 2.x。只需按照通常的 Java IO 方式将文件写入扩展的 WAR 文件夹就足够了。
这需要在
FacesServlet
启动之前执行。Filter
是一个完美的地方。另请参阅此相关答案:您可以将 Facelets 文件打包到 JAR 文件中,然后将其放入类路径中并提供 Facelets
ResourceResolver
当 WAR 中未找到匹配项时,它会从 JAR 中提供文件。您可以在以下答案中找到完整的代码示例:在自定义
ResourceResolver
中您有足够的发挥空间。This is definitely possible if the WAR is expanded. I am not sure about Jetty, but it works for me with Mojarra 2.x on Tomcat 7 and Glassfish 3. Just writing the file to the expanded WAR folder the usual Java IO way suffices.
This needs to be executed before the
FacesServlet
kicks in. AFilter
is a perfect place. See also this related answer:You can package Facelets files in a JAR file and put it in the classpath and provide a Facelets
ResourceResolver
which serves the files from the JAR on when no match is found in WAR. You can find complete code examples in the following answers:You've plenty of play room in the custom
ResourceResolver
.好问题。 BalusC 的回答一如既往地完整且正确。
但是,如果您的目的是创建一个动态构建 gui 的应用程序,那么有一种方法可能会更好地为您服务(取决于您真正想要实现的目标)。
JSF 视图与 Swing 表单类似 - 它们只是一堆粘合在一起的 JavaBeans(tm)。最大的区别在于,当字段绑定到 EL 表达式时,您不使用标准访问器,而是使用特殊方法 (setValueExpression)。
这意味着您可以以纯编程方式从对象(具体类可以在 javax.faces.component.html 中找到)构建 GUI,然后使用绑定属性将其显示在页面上。类似于:
然后在托管 formBuilder bean 中:
上面的示例构建了一个静态面板,但可以:
这样,您就可以拥有一个带有单个标签的静态 xhtml,并使用它来呈现任意数量的动态表单。
正如我所说,这种方法可能比仅仅存储文件更好,但也不一定。如果您只是想省去重新部署的麻烦,那么这是一个巨大的杀伤力(话又说回来,您不需要仅仅为了更改表单而重新部署 JSF 应用程序)。另一方面,如果您的目标是拥有用户定义和编辑的表单之类的东西,那么拥有一个良好的对象模型并以正确的方式存储它可能是一个好主意。
前面的障碍是:
Nice question. BalusC's answer is - as always - complete and right.
However, if your point is to create an application where gui is built dynamically, there is a way that might serve you better (depending on what you really want to achieve).
JSF views are similar to Swing forms - they are just a bunch of JavaBeans(tm) glued together. The big difference is that when a field is bound to an EL expression, you do not use standard accessors, but rather a special method (setValueExpression).
This means you can build your GUI from objects (the concrete classes can be found in javax.faces.component.html) in a pure programmatic way and then use binding attribute to show it on page. Something like:
And then in the managed formBuilder bean:
The example above builds a static panel, but it would be possible to:
This way you could have just one static xhtml with a single tag and use it to present any number of dynamic forms.
As I said, this method could be better than just storing files, but not necessarily. If you just want to save yourself the hassle of redeployment, this is a huge overkill (then again, you do NOT need to redeploy JSF applications just to change forms). If on the other hand your goal is to have something like user-defined and edited forms, having a good object model and storing it in a proper way could be a good idea.
The bumps ahead would be: