Kevin Galligan

Hate to bump, but I still can't get this to work. I had been stuffing the value into the session to get around the issue for the short term, but I'd really like to get this back into the request. Any thoughts? I put it into the request, but it just doesn't hold onto it. By the time the page logic is being executed, the object is gone.

Any help would be great because I'm lost. This should work, and it looks simple, but it just doesn't.

Thanks in advance.

Tried the scriptlet on the form page. The value is in the request attribute collection.

So, its available, and I can get it with that call to the faces application object, yet its not showing up in the form. Any thoughts?

I'm using myfaces 1.1.1 and standard components.

I have a managed bean in the request scope that I'm using in a form screen. I tend to favor the request scope as it reduces all the trouble with the back button, reload, etc.

When clicking "edit" on an existing object, I get the data from the database, and stuff it into the request map. The navigation case goes to the edit screen. I don't have "redirect" set, and the url in the browser stays the same, so I assume it isn't redirecting. Yet, the data doesn't get into the form.

If I put the object in the session map, it shows up in the form.

I also tried checking the managed bean right after I set it in the request map by calling...

app.createValueBinding("#{"+ key +"}").getValue(facesContext);

Running this in the debugger (with the correct key) returns the object I set.

So, somewhere in there its dropping my object. Does it consider this a new request, even though it hasn't left the server? I guess I should try a scriptlet in the jsp page next, just to see if the object is available by the time it gets there.

While I'm on the subject, one of the biggest issues I've always had with jsf is the session and server storage of the view. Seems like we've given up on back button support, but I'm not sure users have. Any thoughts on that?

I feel like the only one out there, but I use the bea workshop, formerly M7 Nitro tool. Personally, I find it to be the best JSF editor available. This is because it does a decent job at visual editing, but isn't painful on your source, and you can edit source directly if you feel the need.

However, even the direct editing is helped significantly by their tag library template panels. That's not the actual name for them. They pop up when you select lets say an html table. It'll provide the ability to select the target object you want, etc. Also has EL code completion and error checking.

I've also used Exadel, and tried Myeclipse, WTP-only, intellij idea 3-5, and briefly netbeans, JBuilder, and the crazy ibm tool. I installed sun studio, and closed it pretty soon after.

I'm more of a coder than a visual editor type of guy, but the bea tool is pretty good at both. I'm highly concerned about what bea will do to it now that they own it. You should try the free jsp editor if you get a chance. Code completion on JSTL EL expressions is pretty sweet.

Eclipse is a tough start. I tried it a few times over the years and gave up on it. Now I personally think its the best thing out there. You just need to go through the initial pain.

So, anybody have a link to a good example for this kind of thing? One dropdown selection populating another?

I imagine this is a pretty basic deal. I've been doing light jsf on and off for quite some time, but not any real projects. Finally I'm starting one. I beat myself up on day one. Here's the deal.

Filling in an address. Two fields. A country dropdown, which should drive the population of a state dropdown. In a perfect world this could be an ajax style affair, and before there was "ajax" I've done this kind of thing in struts and pojsp (Plain Old Jsp. First use I've ever seen of that, and probably because it isn't really pronouncable). However, for today, I'm willing to keep it basic and do the page refresh.

So, is there a good page one can point me to on how this should be done? I left it off with the following:

Country dropdown with a value change listener applied. This listener populates the list of SelectItem values for the state dropdown on the backing bean. The country dropdown has an 'onchange="submit()"' on it and 'immediate' set to true.

It took a while to get all of that sorted out. And, crazy enough, it worked. That was pretty sweet. Of course, it all fell apart when I clicked the regular submit button and had a validation error. Because my backing bean is in request scope, the List populated by the listener no longer has values.

So, on the train in today, I thought of what would work better.

Bind the country dropdown to a field in the backing bean. The method that gets the state List will just look at that UI component's value to figure out which country to use. The value change listener on the dropdown will just send the request directly into render response. This should also work on a normal submit.

Any thoughts?

Some more followup to my post. I've also converted everything in my source base to maven, which with eclipse, makes for a nice package. The other thing I really, really like about eclipse is the stuff that's available out there. For example, if you want to create/edit an xml schema, just open the thing that the WTP project has a great editor for it. Then you want to create an xml file from your schema? No problem. It'll even validate it for you. Have a strange custom file format? Well, if you have a little time, write yourself a plugin. Surprisingly not that difficult, as I've learned recently.

I know, IDEA has plugins too. However, as much as I used to love them, there's no way you could convince me that those guys could keep up with what's going on in the eclipse world.

I used to hate eclipse, and I've tried it over and over on several occasions. When I finally sat down and really learned it, I understood what everybody was going on about. I think it suffers from the accesible nature of the plugins because of quality control, but as long as you're careful with what you install its good. Also, the 1.0 release of WTP was bad. Grab one of the maintenance releases.

I'm currently going through the decision process. I've evaluated netbeans, jbuilder (dead product), eclipse with wtp, myeclipe, exadel, Bea's (formerly M7's) Nitro tool, and intellij Idea. I've settled on the tool that nobody in this thread seems to even consider, that being the Bea tool with eclipse.

I've used Idea for years. I think they peaked with the 3.0 version. I still consider that to be one of the best ide's ever, in a tie with visi studio 6 c++ editor (you know it was good, come on). I just never liked Idea 4 or 5. At this point I think they'd do better to build plug-ins on top of eclipse. Idea lacks in the jsp department. I only say that in comparison to what the bea tool does with code completion and templates.

What the bea tool does that nobody else does in a competent manner is jsp el completion for the standard taglibs. It also does a very good job with struts and jsf editing. The struts and jsf add-ons are expensive, but if you're working with regular jsp's, the plug-in is free. Does anybody have a suggestion that would beat that tool's jsp editing?

I didn't follow the link. However, I'd like to try and clear up some things.

The state being save isn't your appliction's code state. Its the state that faces retains. You need to read the chapter on this in whichever book you have (buy a book, if you have not. JSF in Action or the O'reilly book I'd recommend). Basically, jsf builds its own interface components, and these bind to values and functions on your objects. When it saves state, its saving its own objects' state. Your objects' state is up to you. If you use session scope, your objects stick around, but you need to be careful with sessions.

As for benefit of client vs. server, there's no clear winner. If there were, there would probably be only one option.

Session: keeps state on server, which reduces network traffic and processing when rebuilding state. Can't use back button, and when developing you can run into some strange issues.

Client: Can use the back button. A little more consistant for development. Increases network traffic to write state to client, and processing when submitted.

Personally, I use client state. This is due entirely to the back button issue. In version 1.2, there is supposed to be some better back button support. I haven't read much on this, but I think it only keeps your app consistant. It doesn't actually make the back button 'work' with server state. For internal applications I might wind up using server, as I can dictate how the application is used. For external applications, I'd probably go with client. Its hard to tell customers that they can't use a back button or refresh. Imagine Dell telling you can only use your new computer's mouse on Tuesday's. Its not that bad, but its not the best conversation.

We got into a performance discussion when talking about this not too long ago. I think that if you're building an app for huge numbers of concurrent users, or a big public site, and your screens are going to be critical path, JSF might not be the best thing for you. For the other 99.99% of applications out there, some performance hit might be eclipsed by the development time savings.

However, the jury is still out as to if you'll be more productive with JSF. I'm still figuring that out...

Without looking at the code...

How is your faces servlet mapped in your web.xml file? *.jsf? You'll need to explicitly go to...

http://localhost:8080/jsf-test/index.jsf

(I'm assuming that 'index' is the default page. Also, forward slashes)

I don't think you'd want a password box to be sending itself to a client. Since you don't want to show the value anyway, let it be blank. Test the value on the server. If the admin types in a new password, set it on the user. If the value is blank, leave the current password as is.

If you want to allow blank passwords, you'll need something different. I'd suggest an explicit "Password Reset" page.

Actually, I'd suggest that regardless.

Code please.

I think the client-side state does add significant heft to the page and certainly needs to be considered when building an app. I think it depends on what you're planning to build.

No offense to JSF, but if I were building a web app that was going out to a lot of clients and was supposed to be a high perforance type of thing, JSF would not be the way to go. I'd pick something that was both more mature and was closer to the actual protocol. Struts would be up there in my list of options, but depending on what the app was doing, even that would be debatable.

I think the strength of JSF is its RAD ability, so it'll shine in things like intranet apps and small audience situations. Where performance can be sacrificed for quicker development (and hopefully reduced bug load).

Now, as to the small pipe situation. I took some "readings" on the size of the serialized tree, and it looks to be about 2k for my not-so-huge form. Bigger forms will probably have bigger size. However, if you look at the code generated by JSF just for the form, its not exactly lightweight to begin with. If you've got a slow connection, I think JSF is going to be sluggish regardless. Adding the client state doesn't help, but its going to be crappy anyway.

Version 1.2 is supposed to do something with the back button, but I don't think it'll "fix" it as some have contended. I think its just going to do a better job detecting that the saved UI state came from a different screen.

Of course, I could be wrong.

In summary again, I wouldn't build a critical or high volume app with JSF. However, removing those types from the list, that leaves about 99% of the applications built as possible JSF targets*. That's a big market.

*Yes, that stat is out of my 'a'.

The url for the page you're on is '/pages/arrivedPersonnelList.jsp'? If so, returning 'success' from your action method should push you to '/pages/departurePersonnelList.jsp'. This is the correct sequence? It should work, so restart your server, doublecheck everything, etc.

Ok. I think this is again where you need to hit the books. You need to return a string from your function. That string needs to match up with a navigation rule 'outcome', which will then forward you to another page.

Lets say your list page is 'departureList.jsp' and you want to return to your home page, 'home.jsp'. In your action method, return "success" if everything works out ok. Add the following to your faces-config.xml.

<navigation-rule>
<from-view-id>/departureList.jsp</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/home.jsp</to-view-id>
</navigation-case>
</navigation-rule>

If you return a string but you don't have a navigation rule associated, it'll just show the page again.