[seam-dev] How to "clear" something from a context
Gavin King
gavin.king at gmail.com
Fri May 8 03:18:38 EDT 2009
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
More information about the seam-dev
mailing list