-
1. Re: Multiple entities on page, and @Name conflict
andygibson Nov 20, 2007 10:21 AM (in response to whafrog)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 -
2. Re: Multiple entities on page, and @Name conflict
whafrog Nov 20, 2007 10:48 AM (in response to 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? -
3. Re: Multiple entities on page, and @Name conflict
whafrog Nov 20, 2007 12:43 PM (in response to 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? -
4. Re: Multiple entities on page, and @Name conflict
pmuir Nov 20, 2007 7:16 PM (in response to whafrog)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.
-
5. Re: Multiple entities on page, and @Name conflict
andygibson Nov 21, 2007 11:28 PM (in response to whafrog)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?