问题标签 [prettyfaces]

使用 JSF 在 Java EE 中开发 Web 应用程序。所有页面都通过带有操作“j_security_check”并输入“j_username”和“j_password”的身份验证表单进行保护，以免被查看。

但是，成功登录后，我被重定向到我想访问的页面而不是这个 URL

所以我正在查看包含所有 JS 代码的脚本文件 jsf.js，而不是我想要查看的页面。如果我访问 Web 根目录或任何其他页面都没有关系，我每次都会被重定向到这个 URL。然后我将 URL 更改为任何页面，它可以正常加载并且我已登录。

我不得不说我已经遇到了这个问题，它神奇地消失了，所以它正确地重定向了我。几周后它又坏了，但我不知道这是我的错，如果是我不知道原因。我根本没有搞乱重定向或导航规则。

值得一提的是，我也在使用 PrettyFaces。

编辑：

我想知道如何在操作调用中重定向到同一页面。

我有这个命令按钮：

这是动作：

但它不会重定向到同一页面，它只是刷新它，所以当我尝试按 F5 键刷新页面时，会发生重复提交。这可以在正常情况下通过 post/redirect/get 解决。但是，当操作方法返回与发送请求的页面的 viewId 相同的 viewId 时，人脸不会发送重定向。

我用漂亮的面孔。

当我使用接缝安全登录到我的页面时，它会将我重定向到 /WEB-INF/pages/index.xhtml 而不是简单的 /。这是我的@ViewConfig 的片段：

你知道问题可能出在哪里吗？

通过 Seam3 @ViewConfig 接口使用漂亮面孔时，如何获取 urlMapping 的 id？

在 pretty-config.xml 中，id 在 url-mapping 元素上指定。

使用 Pretty Faces 提供的 @URLMapping 注释，我可以使用 id 属性。

但是 Seam faces 提供的 @UrlMapping 注释没有任何 id 属性，所以我想知道这个映射的 id 是什么。

我们一直在尝试解决为什么我们使用 JSF 1.2 构建的应用程序似乎呈现 HTML 源代码而不是按预期呈现页面。我们正在使用 PrettyFaces 来美化 URL。Mozilla Firebug 偶尔会为网页显示“text/plain”的 Content-Type 响应标头，但是当我们刷新同一页面时，它显示为“text/html”的 Content-Type 没问题。

为了确定，我们还在响应过滤器中包含了一个显式的 response.setContentType("text/html")。

1. IE 9.0：大部分时间运行良好，但偶尔会出现问题
2. IE 8.0：经常出现问题，有时有效，有时无效
3. Safari (Windows) 和 Chrome 20：经常出现问题，有时有效，有时无效

HTML 源代码

.htaccess

任何解决此问题的帮助将不胜感激。

我正在使用以下技术开发一个项目：

• 春天
• ShiroFilter
• 漂亮的面孔
• Tomcat服务器

当我在 tomcat 服务器上部署它时，我"JSESSIONID 456jghd787aa"在 URL 的末尾添加了一个。

我试图解决这个问题，但我无法做到。

我对 p:menuItem 有这个问题 - 使用 PF 3.3.1、PrettyFaces 3.3.3 和 JSF/Mojarra2.1。

所以我有一组 p:menuItems 需要从当前页面传递一个“ID”参数。但是，我不希望构建以下形式的 URL：/page/targetPage?id=id&faces-redirect=true。我想做的是，在页面操作处理程序上，重定向到有问题的 URL。但是，问题是生成的重定向将 windowId 附加到末尾，我无法访问 targetURL！

在我的小脸上：

在我的支持 bean 中：

使用 PF 3.3.1、PrettyFaces 3.3.3 和 JSF/Mojarra2.1。

我有一个自定义导航处理程序来处理我的应用程序页面上的“取消”按钮 - 取消按钮需要返回到上一个（引用）页面。我已经实现了一个基于堆栈的解决方案，它保存了用户导航的踪迹，并且几乎完成了 navigationHandler 的实现——但现在我遇到了一个障碍。我似乎无法获得取消操作以导航回我想要的页面。我尝试了以下方法：

FacesContext.getCurrentInstance().redirect在我的 NavigationHandler.handleNavigation 中。

所以接下来我尝试了类似的东西（同样，在 NavigationHandler.handleNavigation 中）：

现在的问题是 URLMapping（漂亮的面孔 3.3.2） - 抱怨没有 ID，这是必需的：

PrettyException: Exception occurred while building URL for Mapping Id Required value was null

我在它的末尾有带有 ID 的完整 URL - 我想在我的重定向中使用它 - 但是，在我的自定义 navigationHandler 的 handleNavigation 方法中，重定向似乎无法正常工作。

有人对我如何能够优雅地解决这个问题有任何想法吗？附加在 url 末尾的 ID/参数可能因每个屏幕而异，我并不特别想一起破解解决方案 - 如果我能以某种方式将 url 提供给 PrettyFaces 中的某个预定义类，那就太好了会工作或做一个完整的重定向（我无法上班）

在此先感谢您的帮助！

我需要为我的应用程序实现文件下载功能。我按照这个示例从 JSF 应用程序的任何 Web 浏览器强制保存为对话框，但是在代码正常执行时，保存对话框永远不会出现。在查看我的 http 响应后，我看到它包含在漂亮的面孔响应中，因为我也在使用漂亮的面孔。有什么我应该改变的，让它与漂亮的面孔一起工作（假设这是不工作的原因）？

编辑：

看来问题不是漂亮的面孔，而是冰脸。通过将 icefaces 库添加到我的应用程序，下载方法不起作用，并且对话框永远不会出现。通过删除它可以工作。有任何想法吗？

I'm working with JSF2.1 and RichFaces 4.1 in JBoss AS 6.1.0.Final. Right now, I'm focused in rewriting the URLs. After trying different approaches I decided to stick to PrettyFaces since it's really intuitive to use (and got it working in a couple of minutes).

There's a problem tough. The relative links to scripts/css got messed up because the URLs changed and the relative paths end up in 404. I can use absolute paths but that would force me to change many of the pages and to expose application's structure in the page's source code.

I'm thinking about a temporal workaround: Giving the backing bean the responsibility of managing the different levels of those relative links but re-using beans makes this a delicate matter.

My question is, is there defined way or best practice to manage this relative paths while rewriting the URLs?

EDIT

h:outputStylesheet and h:outputScript worked like a charm. All that remains is solving a little issue with CSSs referencing images in a relative way. Take this structure:

A CSS file in the folder _css references the image image1.png located in the _img folder with the relative path ../_img/image1.png. The problem is that this ends up in 404 because it does not find the image in /myApp/javax.faces.resource/_img/image1.png.

Changing every ../ for #{request.contextPath}/resources inside the CSSs seems to work just fine but I wonder if there is a better way to do it. The relative path approach not working seems strange to me.