This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes JSF and the fly likes custom converter usage Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "custom converter usage" Watch "custom converter usage" New topic
Author

custom converter usage

Piter Smith
Ranch Hand

Joined: Feb 25, 2009
Posts: 31
What's the basic approach to navigate from one .xhtml to another passing params with a custom converter? From the error at the bottom, the "id" which is clicked does show, but, for some reason, isn't converted. What can I do to troubleshoot that to find why?

The stack trace isn't informative to me in this case, all I know is that the object isn't getting converted, but I don't know why. Incidentally, http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/providers/nntp/NNTPMessage.html extends javax.mail.Message.



In navigating from messages.xhtml:





to

message.xhtml:





with the following MessageConverter:



Glassfish gives:

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Converters don't "pass" anything. For that matter, Views shouldn't "call" things, because Views are data objects (templates), not executable code a la JSPs. But that's mostly just being pedantic.

In its default configuration, JSF works with HTML. HTML is a text-only format. So when you have a non-text object (such as a Java class) that you wish to render in an HTML data stream, you have to have a Converter to convert the object from binary form to a suitable text form (what makes it "suitable" is up to you). Conversely, when data comes in via an HTTP GET or POST submit, that, too is in text form and you need a converter to convert the text into a binary from. Since a lot of times there's a round trip involved, the converter interface definition defines both operations.

I don't think that you really want to dump a Java Message object in all its sordid internal details out to a web page and suck it back in again. You might, but I generally wouldn't. First, because unless you hide it, the user won't know what to make of the display. Secondly, because it's large enough to add extra network overhead. And finally, because anytime you push things out to a client, some ill-intentioned person can hack it before sending it back again.

JSF is mostly about handling objects on the server. Only the stuff that actually interests the client need to be (or should be!) sent out to the client. As a side effect of that, you don't use the View definition to manage how the server functions internally. That would be a violation of the MVC paradigm and induce unnecessary coupling between View and Model. In most cases, the preferred way to get server-side data objects passed around from one Model object (backing bean) to another, you would use the Inversion of Control paradigm to inject objects. You configure that using the server-side faces-config.xml or its equivalent annotations.


Customer surveys are for companies who didn't pay proper attention to begin with.
Piter Smith
Ranch Hand

Joined: Feb 25, 2009
Posts: 31
Tim Holloway wrote:Converters don't "pass" anything. For that matter, Views shouldn't "call" things, because Views are data objects (templates), not executable code a la JSPs. But that's mostly just being pedantic.

In its default configuration, JSF works with HTML. HTML is a text-only format. So when you have a non-text object (such as a Java class) that you wish to render in an HTML data stream, you have to have a Converter to convert the object from binary form to a suitable text form (what makes it "suitable" is up to you). Conversely, when data comes in via an HTTP GET or POST submit, that, too is in text form and you need a converter to convert the text into a binary from. Since a lot of times there's a round trip involved, the converter interface definition defines both operations.

I don't think that you really want to dump a Java Message object in all its sordid internal details out to a web page and suck it back in again. You might, but I generally wouldn't. First, because unless you hide it, the user won't know what to make of the display. Secondly, because it's large enough to add extra network overhead. And finally, because anytime you push things out to a client, some ill-intentioned person can hack it before sending it back again.

JSF is mostly about handling objects on the server. Only the stuff that actually interests the client need to be (or should be!) sent out to the client. As a side effect of that, you don't use the View definition to manage how the server functions internally. That would be a violation of the MVC paradigm and induce unnecessary coupling between View and Model. In most cases, the preferred way to get server-side data objects passed around from one Model object (backing bean) to another, you would use the Inversion of Control paradigm to inject objects. You configure that using the server-side faces-config.xml or its equivalent annotations.


Right, I'm with you there. The idea is to just pass an int id around as a key representing that particular message.

Is there something in particular wrong with that Converter? Or, am I using it wrong?
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: custom converter usage
 
Similar Threads
Component ID frm1_window viewid has already been found in the view
JSF form problems
JEE example with EJB, JSF is not working
JSF ActionEvent processAction duplication
commandLink with <rich:dataTable>, problem in pagination