Andrew, thanks a lot for your very serious answer. I hope you are not too mad at me... ;-)
I do love Java and I do love JSF concepts. I made a hard decision more than 3 years ago (JSF was a bit younger), as a co-founder of a company to use JSF technology, and I am not sorry for a single minute (ok, there were times I was little...). The things I wrote about are not my complains only, I was dealing with these complains on a daily basis. I was not aware about all JSF complementing technologies you wrote about (I mainly know and used Shale framework). Maybe promoting these technologies on MyFaces site will be a bit helpful. Guy. -----Original Message----- From: Andrew Robinson [mailto:[EMAIL PROTECTED] Sent: Sunday, May 04, 2008 10:46 PM To: MyFaces Discussion Subject: Re: Pretty urls You are making some incorrect assessments of JSF in this email. You don't seem to be grasping how JSF works and what architectural APIs are available for you to work with. I want to address your misstatements first: First, JSF does not forward. There is only one servlet, the FacesServlet. This one servlet is not the cause of the URL not being in sync. The cause is the URL that is rendered in the default implementation provided by the JSF core libraries. You can fix this if you wish to work like struts, it just doesn't come that way out of the box. Second, you have chosen to use redirecting without intelligence as a solution to the bookmarking issue. This was your decision, not JSFs. JSF does not make it impossible to pass parameters using a redirect, so please do not use absolutes. Just because you have yet to find a way to do something does not make it impossible. More on this below. Third, your "pretty" URL can actually be considered ugly. You probably mean able to be bookmarked, not "pretty". I don't think any URL with QS params is "pretty". Fourthly, you keep trying to put business logic in a managed bean constructor. This is not a good idea as business logic should be reserved for methods, not business logic. How many people write EJB session beans that have a lot of logic in a constructor? You just need to correctly author you beans and look into what people are suggesting. If you want people to help, then you should spend the time looking into suggestions and doing some research before replying. I don't think that the one hour you gave in your reply gave you adequate time to look up and research managed properties, and the 3 on-load libraries documented in the WIKI. To address your problems: 1) JSF doesn't have to post back to the same page that rendered it. That is just the behavior of the default JSP view handler. The view handler has the functionality you need along with UIForm to be able to use struts-style actions. The restoreView function of a view handler is responsible for taking a request and turning it into a JSF UIViewRoot: http://tinyurl.com/4xqofb The view ID can be just part of the URL. For example, if you register *.jsf for the faces servlet and use JSPs it looks for a page with *.jsp and not *.jsf. Therefore, the view handler is able to do anything it wants as long as it returns a UIViewRoot instance. As for UIForm, if you look at the JavaDoc (http://tinyurl.com/594r3x), there is no requirements on how the action of the form should be rendered. I am not sure of the specification and I don't have time now to search through the PDF for you, but I believe there is no issue with changing the action. In fact you can do this in the view handler as well. See the getActionURL function: http://tinyurl.com/4y3pfx This means that instead of using editCar.jsf in the URL, then you could have anything you want. Then in your custom view handler (wrapper), you can translate your action URL to a JSF view ID. But do not say that JSF requires you to use redirect for bookmarking, there are other ways. They may just not be as simple and quick. 2) JSF can easily pass on parameters on a redirect. JSF uses the standard redirect mechanism of HTTP (custom code is used for AJAX). If you don't feel like writing the code yourself, then use JBoss Seam. Its filter allows you to append QS values onto redirects and even allows you to put EL in the URL that will be parsed before sending the URL down to the browser. The documentation for this is here: http://tinyurl.com/4qfr26 The thing to realize is the JSF is just a framework, it is not an engine. The Servlet container is the engine and therefore if you can do it with servlets, you can do it with JSF. JSF after all is just a servlet. 3) -- 4) Please look at the on-load functionality. It is usually considered bad OOD for object constructors to have logic. This is why Java technologies heavily use the factory pattern. You should perform logic based on method calls. If you use setSomeProperty, you have to be able to handle exceptions in a property setter. This may mean throwing a custom exception and using a registered JSF error handler to process the error. This really only works if you need only one parameter to look up something. If you are trying to execute GET requests that perform logic like "searchCars?color=blue&year=1998&minGasMilage=30" then you need to do this logic on GET not in an action. There are too many different solutions for me to type them here, including filters, phase listeners, view handlers, navigation handlers, etc. What can tell you is that an easy way is via on-load technologies that I already made reference to. They allow you to run a JSF action on a GET request. This will allow you to not only run an action on GET but also redirect if needed (for example if the QS was not valid for your car search) Since I am now on a computer, not a iPod, I can give you the URL: http://wiki.apache.org/myfaces/Execute_action_on_page_load Please review this and read the JSF spec and view handler JavaDoc for the APIs and see what you can do before responding. If you feel this is over your head, I would suggest using JBoss Seam as it gives almost everything you are looking for. -Andrew On Sun, May 4, 2008 at 8:20 AM, Guy Bashan <[EMAIL PROTECTED]> wrote: > First I have to say, I never use JSF navigation mechanism for these reasons: > - forward is never an option because the url is not in sync. > - you are left with redirect which makes it impossible to pass parameters in > a reasonable way. > When I say reasonable way, I mean request parameters. > > So when I navigate to a page I use parameters. > For example: http://localhost//car_details?carId=5 > When command is activated on the page (requesting the server), JSF refreshes > the view > And taking off the parameters of the original request. > > In regular JSP form post, the url parameters are preserved. > > Now, the pretty url as far as I understand, comes to solve this problem in > jsf. > So beside of being "pretty", there are no request parameters that can > "disappear" after a refresh. There is only a url path. Therefore if page is > refreshed, parameters are still there. Which is a nice and acceptable > solution. > But, then we come to the problem of the original post: > I do initialization in the constructor. But the pretty url will inject the > parameters directly to the bean, causing > The constructor to be activated first... So how can I initialize my page > objects in proper way? > > > > > -----Original Message----- > From: Andrew Robinson [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 04, 2008 4:48 PM > To: MyFaces Discussion > Subject: Re: Pretty urls > > Why do you say that parameters do not stay put? JSF uses the normal > servlet API to handle parameters, the code is excactly the same as JSP > which also just uses the servlet container code > > On 5/4/08, Guy Bashan <[EMAIL PROTECTED]> wrote: > > Hi, > > > > > > > > I read about JSF pretty url solution, for solving JSF post problem, when > url > > parameters are getting lost after submitting the page. > > > > As far as I understand, the parameters in the url are injected directly to > > the bean. > > > > The thing that I cannot understand, in what cases this solution is usable? > > In most of the pages, parameters used to load data to the object. > > > > For example, for editing car details I would use: > car_details.jspx?carId=5. > > > > The data of the form is being loaded in the constructor. > > > > So I will do something like this in the bean constructor: > > > > Id = getParamFromRequest("carId"); > > > > If (Id != null) // Edit existing car > > > > { > > > > car = loadCar(Id); > > > > } > > > > Else // Enter new car details > > > > { > > > > Car = new Car(); > > > > } > > > > > > > > Now, how can I use prett url? By injecting the parameter directly to the > > bean, the constructor will be activated first, then the setter. > > > > One may say, initialize the Car object in the setter method of the bean. > > > > Is it a trivial solution? (It looks a bit not neat initializing object in > a > > setter method). > > > > > > > > Why JSF has never supplied a decent solution to this problem? This is a > > critical issue in web development (not loosing parameters after a post > > operation). > > > > Why are parameters does not stay after post? In regular JSP post > operation, > > the parameters are preserved. > > > > > > > > Thanks, > > > > Guy. > > > > > >
