[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3934) Option for components to be bound to specific natural conversations.

[Dan Hinojosa (JIRA)]

Option for components to be bound to specific natural conversations.
--------------------------------------------------------------------

                 Key: JBSEAM-3934
                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3934
             Project: Seam
          Issue Type: Feature Request
          Components: Core
         Environment: JBoss Seam
            Reporter: Dan Hinojosa


For the Seam connoisseurs,  we find ourselves creating components of the same object, created from different circumstances with unfortunately very different and ugly names.  I propose the ability reuse components while using natural conversation IDs as namespaces.  

The following is a use case that is an all too common problem.  When we want a user account to be created we instantiate a new user component (1).  On the other hand when we want the user that's logged in to update their information we want  the user object already associated associated with their credentials, possibly done with a factory (2).   What we also would like to is to not to create strange variables like loggedInUser, newUser, user, unapprovedUser, just to make things work.  So what I propose is the ability to attach a component based on a natural conversation id being used.  Given the following scenario:

<!--(1) -->
 <component name="user" scope="CONVERSATION" 
               class="com.manning.mymanning.data.User">
 </component> 

<!--(2), Note the conversationName attribute-->
<factory name="user" value="#{userBean.loggedInUser}"
             scope="CONVERSATION" conversationName="updateUser"/>


Such a mapping would do the following.  If a user object is required and if we are not in a natural conversationName called 'updateUser', then (1) will define how the user object gets created, in this case a straight-forward instantiation.  If we are in a natural conversationName called 'updateUser', then (2) will define how the user object gets created, in this case it will be instantiated from a factory which makes use of Seam Security and the EntityManager to retrieve the correct user account. 

If you wish to use annotations:

@Name("user")
@Scope(ScopeType.CONVERSATION)
public class User implements Serializable {...}

@Name("user")
@Scope(ScopeType.CONVERSATION)
@ConversationName("updateUser") 
public class LoggedInUserBean {
        .... 
       @Unwrap
       public User getLoggedInUser() {
            Query query = entityManager.createQuery("SELECT user from User user WHERE user.name = #{identity.username}");
            return query.getSingleResult();
       }
}
 

The advantages for doing this: It would be better reuse of components, and better reuse of JSF pages without have to include a mess of  <ui:param/> to track, better organization, save time from us developers for coming up with various long names for objects, and best of all it gives a contextual identity where the object is used....  "Oh this object is used when updating a user".







-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira