[seam-dev] How to "clear" something from a context

[pmuir at redhat.com]

Two points here

- you are assuming that there is the same performance overhead in  
seam2. Not true, assuming you don't apply an interceptor explicitly  
(security @Restrict, @Transactional, there is minimal overhead  
(maximum is the lookup of the object in a context, or for dependent,  
none)
- using a producer field is even lighter
- this does raise the point that we don't have a truly stateless scope  
where the result is produced every time (imagine injecting a produced  
user into a session scoped bean. Gavin, any hints?)

--
Pete Muir
http://in.relation.to/Bloggers/Pete

On 8 May 2009, at 08:19, Gavin King <gavin.king at gmail.com> wrote:

> Have you met producer fields yet?
>
> On Fri, May 8, 2009 at 2:06 AM, Dan Allen <dan.j.allen at gmail.com>  
> wrote:
>> I'll start by saying true, on some level that does work. And it's
>> reasonable.
>>
>> However, it challenges one of the core principles in Seam. You can  
>> argue
>> whether that matters, but let's just follow this point. Seam  
>> focused on
>> avoiding where possible the use of getter methods to access data.  
>> Instead,
>> data was "pushed out" into top-level context variables where they  
>> could be
>> accessed without an intermediary. The reason this was done is to  
>> avoid
>> repeated invocation of getter methods. It's specially a solution that
>> targets JSF since JSF bombards getter methods during the life cycle
>> processing. Presuming that each method call is intercepted, there  
>> is a
>> moderate to severe performance hit as a result.
>>
>> Looking at your case, you have reduced the number of calls to once  
>> per
>> request. That's alleviates the performance problem and allows the  
>> user to be
>> an independent variable for at least the scope of the request.  
>> However, it
>> behaves very badly with a JSF postback. Why? When the request  
>> begins, JSF
>> produces the user, which prior to login is some transient/blank  
>> User object.
>> During the postback, the user logs in, effectively updating the  
>> User object
>> to a managed entity. But what remains in the request scope is the
>> transient/blank User object. What you need is for the producer to  
>> reproduce
>> at that point.
>>
>> One way around the dilemma I just cited is to redirect before  
>> render, so as
>> to break your association with the current request scope and have  
>> the user
>> produced again on the next request. However, it seems pretty ugly  
>> to me to
>> have to redirect just to clear the result of a request-scoped  
>> producer
>> method you need to reset.
>>
>> Would it be possible to have the producer method observe and event  
>> that
>> would force it to produce again? That would solve most of the  
>> cases....and
>> certainly it would solve this case.
>>
>> If that isn't possible, you have to change the scope of @Produces  
>> @LoggedIn
>> getCurrentUser() to @Dependent, which is nothing more than an alias  
>> for the
>> getter method...the point I started with.
>>
>> -Dan
>>
>> On Thu, May 7, 2009 at 7:18 AM, Pete Muir <pmuir at redhat.com> wrote:
>>>
>>> This is something that was quite commonly needed in Seam, in part  
>>> due to
>>> the use of outjection. As 299 doesn't support outjection, you need  
>>> to use
>>> the manager pattern:
>>>
>>> @SessionScoped
>>> public class Login {
>>>
>>>   public User user;
>>>
>>>   public Login(@New User user) {
>>>      // Initialize with an empty, new, user - the "not logged in"  
>>> user
>>>      this.user = user;
>>>   }
>>>
>>>   public void login(User user) {
>>>      // Log in a real user
>>>      this.user = user;
>>>   }
>>>
>>>   @Produces @LoggedIn @RequestScoped
>>>   public User getCurrentUser() {
>>>      return user;
>>>   }
>>>
>>> }
>>>
>>> This is much cleaner :-)
>>>
>>>
>>> --
>>> Pete Muir
>>> http://www.seamframework.org
>>> http://in.relation.to/Bloggers/Pete
>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>> http://in.relation.to/Bloggers/Dan
>>
>> NOTE: While I make a strong effort to keep up with my email on a  
>> daily
>> basis, personal or other work matters can sometimes keep me away
>> from my email. If you contact me, but don't hear back for more than  
>> a week,
>> it is very likely that I am excessively backlogged or the message was
>> caught in the spam filters.  Please don't hesitate to resend a  
>> message if
>> you feel that it did not reach my attention.
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>
>
>
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org