Dan and Shane raised the issue of how to store data directly in a context. 299 includes that facility: @Current Manager manager;   public void go(final String something) {      // Store the String something in the session context      Contextual<String> somethingContextual = new Contextual<String>() {         public String create(CreationalContext<String> arg0) {            System.out.println("Storing " + something + " in a context");            return something;         }         public void destroy(String arg0) {            System.out.println("Removing " + something + " from a context");         }      };      manager.getContext(ApplicationScoped.class).get(somethingContextual, new CreationalContext<String>() {         public void push(String arg0) {            // No-op, we don't need to deal with partially circularities here         }      });   } But often, if you are controlling the data object, it's better to use a bean to manage the data. -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Thu, May 7, 2009 at 9:06 AM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > > Right. > > Contextual is there so that frameworks can put stuff in contexts for > "special" cases. > > It's not really meant to be used by application code or "normal" > framework code. Stick the stuff in a bean, or use a producer method. So the question was also brought up whether we should provide the unified API to the standard attribute maps in the Servlet and JSF APIs. Ideally, of course, you are using beans and producer methods to populate these contexts. But one of the major usability improvements provided by Seam was the fact that you had one way to access all contexts. Given that we have all been involved in writing applications for companies, you should know as well as I do that it's extremely common to have to use these attribute maps for one thing or another. It's life. Clint said in the meeting you can always just get a handle to that map the regular way. Let me remind you how this is done in JSF: application scope: FacesContext.getCurrentInstance().getExternalContext().getApplicationMap() request scope: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() session scope: FacesContext.getCurrentInstance().getExternalContext().getSessionMap() view scope: FacesContext.getCurrentInstance().getViewRoot().getViewMap() flash scope: very bizarre mix of request map and some internal state All I'm saying is that I think Seam should provide producers that expose these maps so that they are injectable (as the type AttributeMap). I'm not saying we use these maps to manipulate or access beans. This is for integration with legacy systems, storing data ad-hoc in a non-JSR-299 way, or whatever else the case may be. The question is going to come up and I think people will just look for solutions elsewhere (sourceforge.net) to patch Seam to provide something like this. It's not perfect. It's life. -Dan -- 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.

Yeah, I get that we want people to do it the new way. I just hate to undo some of the convenience features we provided in the past for when you have no choice but to do it the old way. I'm skeptical I will win this debate though. -Dan On Fri, May 8, 2009 at 3:19 AM, Gavin King <gavin.king(a)gmail.com&gt; wrote: I really don't think this is a good idea. We should be encouraging people to use the New Way. On Fri, May 8, 2009 at 2:18 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > On Thu, May 7, 2009 at 9:06 AM, Gavin King <gavin.king(a)gmail.com&gt; wrote: >> >> Right. >> >> Contextual is there so that frameworks can put stuff in contexts for >> "special" cases. >> >> It's not really meant to be used by application code or "normal" >> framework code. Stick the stuff in a bean, or use a producer method. > > So the question was also brought up whether we should provide the unified > API to the standard attribute maps in the Servlet and JSF APIs. Ideally, of > course, you are using beans and producer methods to populate these contexts. > But one of the major usability improvements provided by Seam was the fact > that you had one way to access all contexts. Given that we have all been > involved in writing applications for companies, you should know as well as I > do that it's extremely common to have to use these attribute maps for one > thing or another. It's life. Clint said in the meeting you can always just > get a handle to that map the regular way. Let me remind you how this is done > in JSF: > > application scope: > FacesContext. getCurrentInstance().getExternalContext().getApplicationMap() > request scope: > FacesContext.getCurrentInstance().getExternalContext().getRequestMap() > session scope: > FacesContext.getCurrentInstance().getExternalContext().getSessionMap() > view scope: FacesContext.getCurrentInstance().getViewRoot().getViewMap() > flash scope: very bizarre mix of request map and some internal state > > All I'm saying is that I think Seam should provide producers that expose > these maps so that they are injectable (as the type AttributeMap). I'm not > saying we use these maps to manipulate or access beans. This is for > integration with legacy systems, storing data ad-hoc in a non- JSR-299 way, > or whatever else the case may be. The question is going to come up and I > think people will just look for solutions elsewhere (sourceforge.net) to > patch Seam to provide something like this. It's not perfect. It's life. > > -Dan > > -- > 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. > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org -- 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.

On Fri, May 8, 2009 at 5:45 AM, <pmuir(a)redhat.com&gt; wrote: > > Well you haven't produced a good use case for needing this abstraction > (legacy interaction aside, ad that willbe privided through the seam2 layer). > That would be a good start :-) There is at least one important use case, though I think the solution is going to be obvious when I say it. Ken Paulsen stated a best practice on the JSF mailing list that I recommend as well, "that all EL should be given the opportunity to be specified explicitly". Meaning you would use #{requestScope.results} instead of just #{results}. In my research for the article on JSF performance I found this to have a measurable impact on performance. But clearly, that is something that should be provided by an EL resolver. (Naturally, most scopes are already supported, so we just need to add the ones that the JSF EL resolver doesn't know about, namely conversationScope). So in the end, not a use case. The second use case would be to pick off flags that libraries set into scopes. So the values are already there, you just need to read them. Those libraries aren't based on 299 (let's say) and they are sticking stuff into these attribute maps that you need to read. On the flip side, you may need to set attributes that those other libraries rely on. Let's say I am integrating with a system developed a year or two ago (unfair to call it legacy). I have to set some values in the session scope attribute map or else it won't function...such as the current customer id, whether they have accepted a disclaimer, the current user's login name, or whatever. That library is going to go looking in the session map directly, so I can't just make a producer. The question becomes, how often does this second use case come up? I'll call it read and write "flags" that libraries rely on. People that are dealing with a lot of existing systems are going to have a lot of those cases. Those that get to start anew won't have any. That's my use case, take it or leave it. -Dan -- 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.

On Fri, May 8, 2009 at 2:29 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > > > The second use case would be to pick off flags that libraries set into > scopes. So the values are already there, you just need to read them. Several of our apps use a third-party filter [1] to authenticate the user, which stores credentials in the http session.  I'd appreciate being able to write: class UsernameProvider {   @HttpSession Map<String, Object> session;   @Produces @Username String retrieveCasReceipt()   {      return (String) session.get(CASFilter.CAS_FILTER_USER);   } } So, +1 for Dan's suggestion.  If support for such attribute maps aren't in Seam, I'm sure I'm not the only one who will be putting them in my Util project. -Matt [1]  http://www.jasig.org/cas/client-integration/java-client > > > -Dan > > -- > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Tue, May 12, 2009 at 5:26 AM, Nicklas Karlsson <nickarls(a)gmail.com&gt; wrote: Seam could have a "hacks" module that would add the binding type and producer method ;-) Maybe 10 beers in you can convince me, but I don't see using the HTTP contexts as hacks. To me, they have been around for 10+ years and software uses them. That is a reality. You walk into any technical manager's office and try to tell them you can't use contexts anymore and they will gladly show you the door and hire some programmer willing to use them. There is software in an ivory tower and there is real life. We are stupid not to offer some way to access these contexts. Can we advocate not to .... sure, fine, but I still think it is stupid to pretend they don't exist.

-Dan On Tue, May 12, 2009 at 11:10 AM, Matt Drees <matt.drees(a)gmail.com&gt; wrote: > > > On Fri, May 8, 2009 at 2:29 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: >> >> >> The second use case would be to pick off flags that libraries set into >> scopes. So the values are already there, you just need to read them. > > Several of our apps use a third-party filter [1] to authenticate the user, > which stores credentials in the http session. I'd appreciate being able to > write: > > class UsernameProvider > { > > @HttpSession Map<String, Object> session; > > @Produces @Username String retrieveCasReceipt() > { > return (String) session.get(CASFilter.CAS_FILTER_USER); > } > > } > > > So, +1 for Dan's suggestion. If support for such attribute maps aren't in > Seam, I'm sure I'm not the only one who will be putting them in my Util > project. > > -Matt > > [1] http://www.jasig.org/cas/client-integration/java-client > > > >> >> >> -Dan >> >> -- >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- --- Nik -- 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev