<div class="gmail_quote">On Fri, May 8, 2009 at 5:45 AM, <span dir="ltr"><<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#FFFFFF"><div>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 :-)</div></div>
</blockquote><div><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>-Dan<br></div></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br><br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>
from my email. If you contact me, but don't hear back for more than a week,<br>it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters. Please don't hesitate to resend a message if<br>
you feel that it did not reach my attention.<br>