[pmuir]

"mgrouch" wrote:
Yes. Requirement to use SMPC is a problem for me.
I load list of entities via Stateless Session EJB call (so no SMPC).
The entities are reverse engineered from DB at build time by hibernate tools (so no equals() method there).

Hmm. Yes, in this case s:convertEntity won't work, agreed.

Please, take a closer look at my code. Do you think solution provided by Seam for dropdowns is better than mine? So many people keep reporting issues with s:convertEntity...

Yes. I prefer the s:convertEntity approach. And yes, its certainly not perfect, it has , I think, two restrictions:

1) You must use an SMPC to load the list
2) You must be in a conversation

(you can get round both of these by implementing equals)

My main problem with approach you describe below is:

1) You must extend EntitySelector in code. This works very badly with the Seam Framework and components.xml
2) To keep your entities managed, you must cache all entities in your dropdown in the conversation scope (yes, I know you can put them in the event or page scope, but then they won't be managed).
3) No support for xml mapped entities (and you're not going to get this to work afaics)
4) correct implementation of toString() on all keys (think about composite keys here)

Most can be fixed, but (2) is the killer for me and I can't see how you get round it.

I think its fair to say that s:convertEntity is best used in a fully Seam managed environment (Seam managed transactions, Seam managed persistence context), and probably using the application framework.

However, what I'm planning to do (as discussed in another thread) is make it possible to swap out parts of the entityconverter, and I will certainly make it possible to swap out the logic which decides *what* to store to in the cache, and what scope the cache should be. This should mean you can implement what you have below inside the entity converter.

[mgrouch]

3) No support for xml mapped entities (and you're not going to get this to work afaics)

It is possible to get it work using Hibernate API. We need access to hibernate session object and entity.
getSession().getSessionFactory().getClassMetadata(getPersistentClass()).getIdentifier(entity, mode) should give Id in case if entities are not using annotations.

4) correct implementation of toString() on all keys (think about composite keys here)

Yes. But default implementation would work too (I haven't checked though). Default implementation of toString would produce too long string in HTML, but it might even work as is.

How do you handle composite keys with entityConverter? I think this can be done same way after all we do need to create a string out of composite key to use it in HTML.

1) You must extend EntitySelector in code. This works very badly with the Seam Framework and components.xml

Not sure why extending it would be a problem...

2) To keep your entities managed, you must cache all entities in your dropdown in the conversation scope (yes, I know you can put them in the event or page scope, but then they won't be managed).

Even if they are not managed you can always get access to managed entity
by calling finder by ID. It is a little inconvenience for some, but at least
solution for dropdowns will work for everyone (even those who do not use SMPC). Dropdown are usually read-only entities anyway...