[seam-dev] How to store data in contexts
Gavin King
gavin.king at gmail.com
Fri May 8 14:46:28 EDT 2009
I don't agree with Ken Paulson.
On Fri, May 8, 2009 at 1:29 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
> On Fri, May 8, 2009 at 5:45 AM, <pmuir at redhat.com> 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 at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
More information about the seam-dev
mailing list