Multiple entities on page, and @Name conflict

[whafrog]

I think I've discovered the *source* of my issues in these threads, but if there's a solution out there I'd appreciate knowing:

Problem with @Id and non-null entities:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123799

Problem with accessing Map of entities:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123799

Basically, it appears if you want to have entities whose name on the page differs from the @Name annotation, you're out of luck. Even the @In(value="xxx") doesn't override this. I can get my page from the first link above to work if I use the same name as in the LenderBenefit @Name annotation. This pretty much precludes having multiple instances of the same entity type on a page.

However, I've been assured one CAN have multiple instances...so how is this done? How do I override the @Name annotation, or do I drop it altogether?

Many thanks in advance!

Jon

[andygibson]

Well, rather than use named entity instances, you could just use references to them in a stateful backing bean :

I.e.

class MyBackingBean

...
 private Entity entity1;
 private Entity entity2;

 public Entity getEntity1() {
 return entity1;
 }

 public Entity getEntity2() {
 return entity2;
 }

Which I believe is the preferred method to outjecting entity instances.

Cheers,

Andy

[whafrog]

Thanks. Just to be clear: do I remove the @Name annotation from "Entity" in your example? Because I have tried using getters in my action class, but then I get javax.el Exceptions.

Using your example, class MyBackingBean would have to be @Name d (say, "myBackingBean", and on the page I'd reference #{myBackingBean.entity1.someAccessor} (which gives me a javax.el.PropertyNotFoundException on "entity1"), or reference #{myBackingBean.getEntity1().someAccessor()}, in which case I get a javax.el.ELException "method not found".

Does anyone have code proving two instances of the same entity type can be used on the same page with the same action class?

[whafrog]

It works! (mad cackle)

Thanks to Andy Gibson, and also to IGx89 from second link I posted above.

I ended up revisiting IGx89s suggestion, and two things resolved the problem:

First, while I had a @Name annotation on the entity, I neglected to put one on the backing bean that contained the entity collections. (sheesh, I knew it had to be something stupid like that on my part)

Second, I had to use Session scope because the beans in Conversation scope are not available in the RESTORE VIEW phase (as per the Seam Problems FAQ).

I have to say though, it would be a lot more clear if one could simply override the context name, and define multiple instances of an entity on the action class, and have the action class variable name be respected. Seam 3.0?

[pmuir]

The next big evolution for Seam and its core component/context model will be to implement Web Beans. Gavin has posted a good series on his blog about what Web Beans will look like - so go take a look if you want to see the future of Seam.

[andygibson]

No Problem,

Personally, I'm don't usually use named entities. They seem a little pointless since they just get created and popped into the context variables without initialization. For example, the user entity that gets pushed into the authenticator bean in some examples. It is only useful once the authenticator has authenticated the login, loaded the user and outjected an instance of the user. I can't see much use for named entities over the factory methods except possibly in the user case where you might want a blank instance available to avoid any null exceptions, and you can't use a factory since the user may not have logged in yet.

In your case, you may want to look at the @Factory annotation instead. You can annotate access methods for the entities in your backing beans with any name you like, it will outject the entities as a named context variable. If you do this, you won't need to reference the entities as MyBacking.getEntity1

i.e.

class MyBackingBean

 private Entity entity1;
 private Entity entity2;

 @Factory('entity1')
 public getEntity1() {
 return entity1;
 }

 @Factory('entity2')
 public getEntity2() {
 return entity2;
 }

}

Now, in your jsf page, you can reference #{entity1} and #{entity2}

It all depends on how you initialize your entities, whether you pass entities around or rely on parameters (the method I prefer).

You have to bear in mind that factory methods get called whenever you reference #{entity1} (or 2), so if you have any weird pre-initialization that happens to load the entities, you have to make sure that has run before you access the factory. For this reason, I prefer to use parameters since it is less coupled.

Lastly, having the bean in conversation scope shouldn't be a problem, what's the problem with it?