组合组件放在哪里?(JSF 2.0)
我将继续我的 JSF 2.0 实践。 我认为模板是一件很棒的事情,而且它有很多优点。但今天我对此有了新的疑问。
我为我的页面创建了一个模板。 在模板中,我对不同的部分使用标签(这些部分稍后将在页面中使用组合标签结合一个或多个定义标签来实现)。
<ui:insert name="content" />
同样在模板内部,为了避免在模板中放入太多代码,我创建了 标签来添加一些其他 xhtml 块。
<ui:include src="/languageChanger.xhtml"/>
这就是我的文件夹结构的样子:
这一切都按我的方式工作,但是当我在网址中导航时到 languageChanger.xhtml 我看到 xhtml 的复合块:
我的疑问是:
- 该块是独立的代码放置在正确的地方?,还是错误的,不应该允许用户从 URL 中看到它?
-那个地方是否保存了其他组件,例如登录、注册......?
- 为了避免用户直接访问组件,我可以将其放置在 WEB-INF 文件夹中,但随后我遇到了一个问题,即包含标记找不到路径。我应该怎么办?
- 最佳实践是什么?在哪里放置这些独立的代码块?
I am continuing my practices with JSF 2.0.
I see templating is a great thing to do, and it has lots of advantages. But today i got a new doubt related to it.
I created a template for my pages.
In the template, i use tags for the parts that are different(Those parts will be implemented later in a page using the composition tag in combination one or more define tags).
<ui:insert name="content" />
Also inside the template, to avoid putting to much code in the template, i create tags to add some other chunks of xhtml.
<ui:include src="/languageChanger.xhtml"/>
This is how my folder structure looks:
It all works as i spect, but when in the url i navigate to languageChanger.xhtml i see the composite chunk of xhtml:
My doubts are:
-Is that chunk of independent code placed in the right place?, Or it is wrong, the user should not be allowed to see that from the URL?
-Is that place save to have other components like login, register...?
-To avoid user access directly the component i could place it in WEB-INF folder, but then i have a problem that the include tag does not find the path. What should i do?
-What would be the best practice, where to place this independent chunks of code?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
将其放在
/WEB-INF< 中的某个位置/代码>。容器不允许直接访问此文件夹。
我不明白你的意思。也许你想说的是“安全”而不是“保存”? “其他组件”是什么意思?
你的道路显然是错误的。 Facelet 模板、包含、标签和组合(不是复合组件)可以完美地放置在
/WEB-INF
中。将其放在
/WEB-INF
中。最佳实践是使用绝对路径,即以/
开始路径。它将相对于网页内容根进行解析。例如,只有“主”页面(通过URL 请求的页面)不能放置在
/WEB-INF
中。Put it somewhere in
/WEB-INF
. Direct access to this folder is disallowed by the container.I don't understand you. Perhaps you meant to say "safe" instead of "save"? What do you mean with "other components"?
Your path was apparently plain wrong. Facelet templates, includes, tags and compositions (not composite components) can perfectly be placed in
/WEB-INF
.Put it in
/WEB-INF
. Best practice is to use absolute paths, i.e. start the path with/
. It will be resolved relative to the webcontent root. E.g.Only the "main" page (the one which is to be requested by URL) cannot be placed in
/WEB-INF
.对于你的前两个问题:
模板及其使用的默认内容位于正确的位置。它们必须位于 Web 应用程序的文档根目录下,而不是其他地方。
对于你的最后两个问题:
上面提供了部分答案,其中提到了需要将包含的文件放置在文档根目录下。 JSF 运行时使用的“资源解析器”要求 Facelet 存在于应用程序的文档根目录下。由于这个原因,Facelet 不能放置在
WEB-INF
中。如果您需要阻止用户直接访问这些页面,那么您必须编写一个 Web 应用程序过滤器来阻止访问这些页面。
Mojarra 运行时不会在内部将任何 HTTP 请求转发到模板资源;相反,它包含以流形式检索的文件内容。这意味着您不需要限制过滤器仅调度
REQUEST
类型;您可以将过滤器应用于所有调度类型。将所有模板和包含的 Facelet 放在
/templates
目录中可以更轻松地在单个 URL -/templates/*
上应用过滤器。For your first two questions:
The templates and the default content used by them are in the right place. They must be present under the web application's document root, and not elsewhere.
For your last two questions:
The partial answer is provided above, where the need to place included files under the document root has been mentioned. The "resource resolver" used by the JSF runtime, requires that the facelet be present under the document root of the application. Facelets cannot be placed in
WEB-INF
for this reason.If you need to prevent users from accessing these pages directly, then you must write a web-application filter to prevent access to these pages.
The Mojarra runtime does not internally forward any HTTP requests to a template resource; instead, it includes the contents of the file, retrieved as a stream. This implies that you need not restrict the filter to dispatch types of
REQUEST
alone; you can apply the filter to all dispatch types.Placing all templates and the included facelets, in a
/templates
directory would make it easier to apply the filter on a single URL -/templates/*
.