-
1. Re: Feature request - @InOut
mariuszs Feb 21, 2007 12:57 PM (in response to andrew.rw.robinson)Maybe
@Bi
is better ;) -
2. Re: Feature request - @InOut
patrick_ibg Feb 21, 2007 3:34 PM (in response to andrew.rw.robinson)LOL. Seems useful but, @InOut just sounds vulgar.
"A Clockwork Orange" popped into my mind... -
3. Re: Feature request - @InOut
monkeyden Feb 21, 2007 4:40 PM (in response to andrew.rw.robinson)good stuff
-
4. Re: Feature request - @InOut
atzbert Feb 21, 2007 4:42 PM (in response to andrew.rw.robinson)"mariuszs" wrote:
Maybe@Bi
is better ;)
+1 :) -
5. Re: Feature request - @InOut
patrick_ibg Feb 21, 2007 7:20 PM (in response to andrew.rw.robinson)How about one of the following:
@Contextual
@Scoped
@ContextVariable
@ScopedVariable
@SeamVariable
Or replace *Variable with *Value or *Object or *Bean -
6. Re: Feature request - @InOut
monkeyden Feb 21, 2007 7:27 PM (in response to andrew.rw.robinson)Where do I sign up for the hot @Bi action?
(@Bidirectional or @Bijected if you prefer)
+1 -
7. Re: Feature request - @InOut
andrew.rw.robinson Feb 22, 2007 10:42 AM (in response to andrew.rw.robinson)http://jira.jboss.org/jira/browse/JBSEAM-903
I put in @Bidirectional. @Bi doesn't sound any less perverted than @InOut :-). -
8. Re: Feature request - @InOut
norman.richards Feb 22, 2007 8:56 PM (in response to andrew.rw.robinson)In the general case, wouldn't be better to simply create a component definition in components.xml? You shouldn't normally need such verbose in/out declarations.
-
9. Re: Feature request - @InOut
andrew.rw.robinson Feb 23, 2007 11:32 AM (in response to andrew.rw.robinson)"shouldn't normally need such verbose in/out declarations"
-1
It is often very helpful with rendering specific member variables with conversation or session scoped beans. For example, a SELECT box may use a selectItems that takes a List return value from a backing bean. If this were to be created in the get method, the list would be created multiple times per-request since the EL is evaluated more than once during the JSF phases. So, the technique can be used:@In(scope=ScopeType.EVENT, value="some-unique-string", required=false) @Out(scope=ScopeType.EVENT, value="some-unique-string", required=false) private List<SelectItem> myOptions; public List<SelectItem> getMyOptions() { if (myOptions == null) { /* build the list */ } return myOptions; }
In this example, myOptions is created only once per request and the developer doesn't have to code the: 1) get faces context 2) get the external context 3) get the request map 4) get the value from the map 5) if null create it and 6) store it in the map and finally 7) return it.
This is also very useful for binding where you want the UIComponent to be created once per-request and not tied to the conversation.
Perhaps in these instances the "@Scope" being applied to fields would be more useful. In that case the seam framework could null out any variable with a shorter lifespan than the bean. Examples could be:@Scope(ScopeType.CONVERSATION) public class MyBean { // Null this value after request @Scope(ScopeType.EVENT) private String myVar;
@Scope(ScopeType.SESSION) public class MyBean { // Null this value after a conversation is ended instead of waiting for the session to end @Scope(ScopeType.CONVERSATION) private String myVar;
-
10. Re: Feature request - @InOut
norman.richards Feb 23, 2007 2:22 PM (in response to andrew.rw.robinson)I think that looks like a mess. Is there a reason to not use @Factory or one of the other techniques seam provides for managing state?
-
11. Re: Feature request - @InOut
andrew.rw.robinson Feb 23, 2007 5:48 PM (in response to andrew.rw.robinson)I find things defined in XML files to be very hard to maintain and try to stay away from them and use annotations instead. Also putting variables not tied to beans into the request scope also makes it hard to maintain -- as it is hard to determine what bean put them there. I like to "bean qualify" all my EL expressions so it is simple to find the bean and the property that is being used. Also in a large application, it would be a bit of a challenge to ensure unique EL names if many bean properties suddenly became available in the root EL context.
For small applications like those examples seam provides, it is fine, but when you may have hundreds of backing beans and views, it gets a lot harder.
So the reason is so that I can keep the properties of a bean inside that bean and manage the life-cycle of those properties from within that bean (basically encapsulation). -
12. Re: Feature request - @InOut
patrick_ibg Feb 23, 2007 8:12 PM (in response to andrew.rw.robinson)Maybe I'm being dense, but... if I read your post right, it sounds like you want your entity POJOs to be referenced through a JSF managed bean... so why not just make a stateful managed bean that has getters/setters for the entities?
Something like:@Stateful @Scope ( ... ) @Name ("myManagedBean") class MyManagedBean { private String text ; private User user ; public String getText () { return this.text ; } public void setText (String text) { this.text = text ; } public User getUser () { ... } public void setUser (User user) { ... } }
Then the EL would look something like this:
User name: #{myManagedBean.user.name}
Text: #{myManagedBean.string}
etcetera...