0

balusc offers the definitive answer on how to use JSF converters and why conversion is necessary here but my question is why bother? An extra class dedicated to conversion seems like bloat to me. Why not simply have the backing bean's setSelectedXXX() methods accept a String rather than an object and do the conversion there rather than in Converter.getAsObject()? In fact it seems clearer to me to name the backing bean's setSelectedXXX() methods like setSelectedXXXByName() or setSelectedXXXById().

My concrete problem is that my backing bean contains the list of selectItems that I need to iterate over to find the needed one by name or ID, not the Converter class. Of course the converter can call backingBean.getXXX() to get this list, but having the logic outside the backing bean seems splintered to me. Is there a good reason for it that I am missing?

Jasper de Vries
  • 19,370
  • 6
  • 64
  • 102
snakedog
  • 357
  • 1
  • 2
  • 13

1 Answers1

3

Why Bother With Converters?

Because a good software developers bother about Law of Demeter.

In fact it seems clearer to me to name the backing bean's setSelectedXXX() methods like setSelectedXXXByName() or setSelectedXXXById().

In fact, such methods are not terribly reusable in another backing bean where you happen to need to perform exactly the same conversion. Such methods are thus prone to being copypasted which in turn violates DRY and KISS.

Just use BaseEntityConverter or omnifaces.SelectItemsConverter to have a single converter you never need to bother about.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Complete and concise answer, thanks. I had to read the LoD link several times to understand it but it makes total sense, in line with my understanding of encapsulation. I can see the reusability of a separate Converter class, but in an app that has only one backing bean would you consider these principles to still apply? As a sort of separate question, I have never had more than one backing bean in my JSF apps because the coupling between them would be extensive and complex. I don't understand how you would do that but my backing beans are huge which begs for them to be divided. – snakedog Feb 01 '18 at 15:33
  • How do you solve the problem of coupling between the Converter and the backing bean? The backing bean contains the list of items that the Converter needs to find the selected item. I have done it for now using Spring @Autowired but this seems like an ugly circular dependency. – snakedog Feb 01 '18 at 15:39
  • Picture is indeed less clear in toy applications but more clear in real world applications. Solutions to coupling are already pointed out in last paragraph of the answer. – BalusC Feb 01 '18 at 16:27
  • Well I am doing something very wrong then. I am loading up a list of objects in my backing bean. In order to getAsObject(String) in the Converter I need to iterate over that List to find the matching object, but the Converter has no access to the List. – snakedog Feb 01 '18 at 16:48