Win a copy of Head First Agile this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

CRUD approach  RSS feed

 
ed connell
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've got what I assumed is a simple situation, but doesn't quite work as I intended, so just shows how much of a novice I still am with JSF. But, I'm trying, that's what brings me here.

So, in trying to keep with request scoped beans, and away from session scoped. The simple page idea is the user navigates to the page from another page. The action method enroute loads the backing bean initially.

Backing Bean 1 is loaded with the initial value.
Initial value is shown in column 1 as output text.
Backing Bean 2 is to receive a user entered value from input text in column 2.

Now, since BB1 and BB2 are basically identical, they're the same object, just different names.

On form submit, want to compare col1 and col2 values. If different am going to update the external source with the new value.

In comes issues I kind of expected. First, col1 was preloaded by the external action. If the page needs redisplayed, that value needs to be carried into the redisplay. So, I add a <h:inputHidden> with the value of the BB1 to carry the original value forward for a redisplay. Is that commonplace? That method actually seems to work okay, but goes wrong if I add a validation to col2. If col2 fails validation, the col1 value is not carried forward into the output text of col1. It's not applied, but it does carry forward as a hiddenField oddly enough.

This just seems a fairly general problem to me, and wondering why I'm struggling to find a fairly general solution. I don't feel like creating a single backing bean with col1 and col2 dup'd as "original field", "submitted field".

Yes, why two columns. Just because.

I probably can get it to work without any validations, and just doing validations on the application phase.

Anyone know what I'm talking about here?
 
Tim Holloway
Bartender
Posts: 18720
72
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSF has an unfortunate habit of forcing things into a session context that we'd rather not keep in a session. Working around it often is more trouble (and complexity) than it's worth.

The root of the evil is the JSF postback process. In other frameworks, you create a page, present it, capture values, and move on. In JSF, the postback process means that you can present and capture many times, instead, so you need to keep that supporting data available. Either you push it back and forth between server and client (which is insecure and eats network bandwidth) or you put the object in session scope, which eats memory. This is especially true when you're doing table displays and other DataModel-based activities. One trick I have used is that when a table view goes off to edit a detail item, I put the detail editing support stuff in a request-scope bean and inject the original (session-scope) table backing bean into it. I also do this with special forms, such as "search dialogs".

There are other tricks you can use as well, such as using session-scope objects and deleting them by brute force, but I don't like that. Though if JSF ever presented a reasonably clean API, I might reconsider. Right now you have to dig through not only JSF, but the underlying servlet infrastructure to do it.

You can also (in some cases) adopt an EJB-like approach. Instead of keeping secondary (non-backing) objects in session scope, just keep handles to them in the session and fetch the referenced objects when/if needed. It's a little more processor overhead, but it keeps the session storage footprint smaller.
 
ed connell
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Tim - great insight as always.

Seeing you use phrases like "work arounds" and words like "tricks" gives me comfort I'm not completely missing everything.

I came across another interesting situation the past couple days where I have a common page that can be navigated to from two different origins. Thought it might be nice to add a cancel button on that destination page and well, you can probably see how that goes bad. Started to scheme about possibly trying to devise a slick solution which could hook the initial navigation to a page, maybe even keep a whole series of pages, push the input params on a session maintained stack then be able to also hook a cancel button action, pop the stack and replace the param map in the restore view possibly or something, and maybe get JSF to magically go back to the origin page. Lol. Don't think that's gonna work out too well, since the param map is immutable, but was fun to think about. Haven't given up quite yet...

Thanks again for the reply.
 
Tim Holloway
Bartender
Posts: 18720
72
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSF 2 will add the ability to specify a target as an action return. However, having seen a similar technique in Struts and how it worked out, I'm not all that excited about that idea.

You can dynamically modify JSF infrastructure if you know what you're doing. There's also a "breadcrumb" tag or 2 floating about, I think. It might help.

The other alternative is that when the action method that invokes the shared functionality fired, it could jam in a "return-to" ID, Let's call them "returnPage1" and "returnPage2" and assume that we set a sharedBean property named "returnTo" with one of these IDs.

In that case, the shared cancel function could terminate with a "return returnTo;" statement, and your navigation map would define the action targets for the cancel function such that action value "returnPage1" navigates (back) to page1 and likewise for the action value "returnPage2".

Not as tidy or general-purpose as a return stack, but it's fairly straightforward.
 
ed connell
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have been considering the return 2 idea, pretty much as you've described, and since I thought of it, it must be pretty straightforward. Problem again with that seems to come back to restoring the info on the origin page, when one of the original pages was full of other stuff. Seems that takes me right back to the needing a session bean for all that original busy page info, or carrying around a whole lot of parameters, just as you described earlier. Fun fun.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!