2 Replies Latest reply on Nov 28, 2008 5:10 PM by Dean Hiller

    What the JSF lifecycle should have been

    Dean Hiller Expert

      Is it just me, or should this part of the JSF lifecycle...

      Apply valus to model

      should have been changed to

      Apply values to model
      commit to database

      90% of my problems have been related to skipping validation to get values applied and it seems like alot of work and if my values were always applied, BUT not committed to the database, I would have had a much easier time.  I am always dealing with immediate=true and valueChangeListener OR the AJAX stuff which when rerendering a form sometimes prevents me from deleting rows in a table until the dang validation passes...just let me change the model dangit...it is not like I am saving to the database in this case....That is what kicks butt about the long conversations, I can flush when I want to so commit to database may or may not be there and if validation failed, it automatically skips that phase and the transaction is not committed but rolled back.  Man, I dream of an easier framework after all the issues I have been through in the past week.

      I am seriously considering going back to GWT. At least the problems were not 3 levels deep and trying to debug the framework all the time.  I am curious, anyone else care to comment on this?  I would love to hear I am wrong and there are things I am not considering (which happens :) ).

        • 1. Re: What the JSF lifecycle should have been
          Daniel Young Novice

          Does that mean you'd need a revert model back to original state if your validations fail?  It seems a bit troublesome to me.

          • 2. Re: What the JSF lifecycle should have been
            Dean Hiller Expert

            why would I need that when hibernate supports it just find.  Here is how hibernate does it

            1. end the conversation
            2. create the new entity manager
            3. entity manager grabs the unwritten values from the db

            note that the commit to database above is optional depending on if you are doing a long running conversation.  Instead, it seems there are tricks to get around this problem like immediate=true which seemed to break using FacesMessages AND moves the validation up a level too.  we have had all sorts of problems that I think this change would solve.  Though it is not likely to change, it kind of sounds nice in theory....sometimes reality works out a bit differently and new problems creep up.