Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

custom converter usage

 
Piter Smith
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18027
47
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Piter Smith
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic