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

Dan Allen dan.j.allen at gmail.com
Fri May 8 03:06:49 EDT 2009


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090508/b12ca118/attachment.html 


More information about the seam-dev mailing list