Announcement Announcement Module
Collapse
No announcement yet.
JSF Incorrect Form Action Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JSF Incorrect Form Action

    I posted this in the JSF Forums, but they passed the buck and told me to post it here.

    I am using Spring MVC 2.5 with JSF, and I'm running into a weird issue with the action attribute on the form tag.

    My application has a URL structure similar to http://webadress.com/org/user/edit. This is setup in the following way:
    PHP Code:
    <bean id="faceletsViewResolver"
            
    class="org.springframework.web.servlet.view.UrlBasedViewResolver">
            <
    property name="viewClass" value="org.springframework.faces.mvc.JsfView" />
            <
    property name="prefix" value="/WEB-INF/pages" />
            <
    property name="suffix" value=".xhtml" />
        </
    bean
    I also have a simple form, similar to the following:
    PHP Code:
    <h:form id="someFormName">
        ... 
    contents of the form ...
    </
    h:form
    The problem arises when the form is rendered to the page and the action tag is generated. Instead of posting back to the current page (/org/user/edit), it posts back to the path that the file was pulled from.

    It does this...
    PHP Code:
    <h:form id="someFormName" action="/WEB-INF/pages/org/user/edit" ...>
        ... 
    contents of the form ...
    </
    h:form
    Instead of this...
    PHP Code:
    <h:form id="someFormName" action="/org/user/edit" ...>
        ... 
    contents of the form ...
    </
    h:form
    Therefore, it posts to a page that is not accessible. I'm really not sure which framework is causing this or where/how to configure this.

    Any help is greatly appreciated! Thanks...

  • #2
    Hi!

    Is there any solution for this problem? Cause I'm facing exactly the same problem - probably it has to do that we want to use jsf with mvc instead of webflow ?

    Thanks
    Wolfman

    Comment


    • #3
      No Simple Solution...

      I did quite a bit of hunting on this issue, but did not find any easy solutions.

      While I no longer have the specific details of the solution, I was able to make it work by overriding a method in the default form implementation of Faces. This may be an option, though you would want to do extensive research on the side effects of rewriting the java code that generates the form information.

      When I asked this question, I was studying the feasibility of using JSF with Spring MVC. Due to time limitations, we decided against it and decided to use a different technology combination.

      I hope this helps in some way.

      Comment


      • #4
        I'm facing same issue with SWF 2.0.8 and <h:form tag.

        Comment


        • #5
          I have the same problem too. Anybody can help ?

          Comment


          • #6
            There is such a problem really. Actually that does show that Spring+Faces integration through Webflow is still immature.
            The simplest solution here is changing form's action through a javascript code on pageload, what is weird and unnatural.

            Comment


            • #7
              there has to be a solution

              Hey,

              there has to be a solution! I have exactly the same problem but I am new to Spring. I am working on a dynamic CRUD controller with RESTful URLs and JSF-Views.
              https://jira.springsource.org/browse/SWF-1341 seems to be solved but I am not able to see the solution. I've also consulted big google without success.
              Help, pls.

              regards,
              Max

              Comment


              • #8
                solved

                solved by defining a UriViewHandler extending ViewHandlerWrapper that returns current url in getActionURL()-method when the requested URI starts with /WEB-INF/ else returns the result of the wrapped ViewHandler.getActionURL() for normal JSF form action behaviour:

                myPackage/UriViewHandler.java:
                Code:
                public class UriViewHandler extends ViewHandlerWrapper {
                
                	private ViewHandler handler;
                
                	public UriViewHandler(ViewHandler h) { // thanks to decorator pattern
                		handler = h;
                	}
                
                	@Override
                	public ViewHandler getWrapped() {
                		return handler;
                	}
                
                	@Override
                	public String getActionURL(FacesContext ctx, String viewId) {
                		return viewId.startsWith("/WEB-INF/")
                			? ((HttpServletRequest)ctx.getExternalContext().getRequest()).getRequestURI()
                			: handler.getActionURL(ctx, viewId);
                	}
                
                }
                faces-config.xml modification:
                Code:
                <application>
                	<view-handler>myPackage.UriViewHandler</view-handler>
                </application>
                Although, this does not solve the problem of concept conflict between RESTful Controllers and JSF form handling it should be possible to use both. But Controller-driven JSF-Pages in /WEB-INF/ can not be accessed via <h:commandLink> or <h:commandButton> actions. In case <h:form> tags would not be used in JSF it could be used passive and fully controller-driven but then you will have to do validation in another way and disclaim a lot of other JSF features.
                I am not sure if this really makes sense.
                Last edited by MaxMan; Mar 6th, 2011, 06:46 PM. Reason: allowing normal JSF form flow

                Comment


                • #9
                  nothing is solved

                  Now actionListener in commandButtons doesn't work!
                  I think it might be a better approach to use another presentation framework with @Controller classes to get RESTful URLs or use web flow.
                  Last edited by MaxMan; Mar 6th, 2011, 06:32 PM.

                  Comment


                  • #10
                    I have the same issue. In our project webflow is used. If you want to use Spring IOC and JSF templating webflow seems to be required, since everywhere you are told to use it. But does it make sense to use webflows, even if you do not have flows? The flow description will degrade to a fully connected net, with transitions from every state to every state. There was no tutorial telling how to integrate a webflow in a Spring/JSF app.

                    Comment


                    • #11
                      I’m facing exactly the same problem. I don’t have any flows in my application, so using webflow doesn’t seem to make any sense. Has anybody found any solution to the above discussed problem? If yes, could you share the solution, please?

                      Comment


                      • #12
                        I unfortunately had to give up on the issue due to the project timeline and was never able to determine a solution.

                        Comment


                        • #13
                          It is 2013 and this problem seems to have remained with us.

                          I have a pilot Spring + JSF project and bumped into this immediately.

                          h:form and h:commandButton uses completely wrong URLs (at least for same-page actions). Instead of the URLs defined on the controller they include .xhtml references (which of course don't exist).

                          Spring doesn't support JSF's ViewScoped so you cannot have short-lived backing beans either. So by using Spring3 instead of EJB3, you loose some of the advantages of JSF2 as well.

                          It seems that Spring3 and JSF2 are only "somewhat" integrated and they cannot be used together properly.

                          I think I will cancel my current pilot and try to use Vaadin with Spring.

                          Comment


                          • #14
                            It's so refreshing to find articles like the ones you post on your topic. Very informative reading.Thanks

                            Comment

                            Working...
                            X