How to store data in contexts
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
How to store data in contexts
by Pete Muir-2
::
Rate this Message:
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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Gavin King-3
::
Rate this Message:
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. On Thu, May 7, 2009 at 6:10 AM, Pete Muir <pmuir@...> wrote: > 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@... > https://lists.jboss.org/mailman/listinfo/seam-dev > -- Gavin King gavin.king@... http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Dan Allen (mojavelinux)
::
Rate this Message:
On Thu, May 7, 2009 at 9:06 AM, Gavin King <gavin.king@...> wrote: request scope: FacesContext.getCurrentInstance().getExternalContext().getRequestMap()Right. 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() 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. _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Gavin King-3
::
Rate this Message:
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@...> wrote: > On Thu, May 7, 2009 at 9:06 AM, Gavin King <gavin.king@...> 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@... http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Dan Allen (mojavelinux)
::
Rate this Message:
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@...> wrote: I really don't think this is a good idea. We should be encouraging -- 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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Pete Muir-2
::
Rate this Message:
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 :-)
_______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Dan Allen (mojavelinux)
::
Rate this Message:
On Fri, May 8, 2009 at 5:45 AM, <pmuir@...> wrote:
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. _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Gavin King-3
::
Rate this Message:
I don't agree with Ken Paulson.
On Fri, May 8, 2009 at 1:29 PM, Dan Allen <dan.j.allen@...> wrote: > On Fri, May 8, 2009 at 5:45 AM, <pmuir@...> 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. > -- Gavin King gavin.king@... http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Matt Drees
::
Rate this Message:
On Fri, May 8, 2009 at 2:29 PM, Dan Allen <dan.j.allen@...> wrote:
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
_______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Nicklas Karlsson
::
Rate this Message:
Seam could have a "hacks" module that would add the binding type and
producer method ;-) On Tue, May 12, 2009 at 11:10 AM, Matt Drees <matt.drees@...> wrote: > > > On Fri, May 8, 2009 at 2:29 PM, Dan Allen <dan.j.allen@...> 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@... >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > > > _______________________________________________ > seam-dev mailing list > seam-dev@... > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- --- Nik _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Dan Allen (mojavelinux)
::
Rate this Message:
On Tue, May 12, 2009 at 5:26 AM, Nicklas Karlsson <nickarls@...> wrote: Seam could have a "hacks" module that would add the binding type and 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
-- 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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Pete Muir-2
::
Rate this Message:
On 15 May 2009, at 17:26, Dan Allen wrote: > On Tue, May 12, 2009 at 5:26 AM, Nicklas Karlsson > <nickarls@...> 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, stop using crazy FUD ;-) 1) JCDI provides a good way to use contextual data, through beans. The API is neat, unified and declarative 2) JCDI provides a way to manage the lifecycle of your data in the contexts directly should you prefer through Contextual. This isn't recommended 3) JCDI doesn't stop you accessing the contexts directly by accessing the request, session etc. One of the modules Seam should supply is manager objects for the HttpSession, ServletContext and HttpRequest. Anyway, Matt's suggestion of exposing the attribute maps from these as a Map is reasonably neat, and I guess we could do that - some abstraction is definitely not a good idea though. Maybe make something in sandbox to start with, and see how popular it is? > > > -Dan > > > > On Tue, May 12, 2009 at 11:10 AM, Matt Drees <matt.drees@...> > wrote: > > > > > > On Fri, May 8, 2009 at 2:29 PM, Dan Allen <dan.j.allen@...> > 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@... > >> https://lists.jboss.org/mailman/listinfo/seam-dev > >> > > > > > > _______________________________________________ > > seam-dev mailing list > > seam-dev@... > > 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@... > https://lists.jboss.org/mailman/listinfo/seam-dev -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: How to store data in contexts
by Dan Allen (mojavelinux)
::
Rate this Message:
On Tue, May 19, 2009 at 12:53 PM, Pete Muir <pmuir@...> wrote:
I don't get how that is different from what I am suggesting. So I of course agree.
Excellent my thought. Let's just sandbox it, see where it goes. -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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
| Free embeddable forum powered by Nabble | Forum Help |
