[weld-dev] @Inject FacesContext

[Marcell Manfrin Barbacena]

Hi,

I absolutely agree with what you said. However we should not mistake a
language (python, ruby) with a packed interpreter (mri, ironruby,
cpython, etc.). The last is much more then a pure language interpreter
having lots of available libraries out of box.
What I said before, spec should be minimalist, I do not say that weld,
openwebbeans shouldn't put efforts to make our life's easier.

[]s

===
"Nobody knows who i really am
 I never felt this empty before
 And if I never need someone to come along
 Who's gonna comfort me and keep me strong?"
--
Marcell Manfrin Barbacena
barbacena at gmail.com
mbarbacena at tre-pb.gov.br
Skype: callto://marcell84bruk
+55 (83) 8808-8555 (Mobile)
+55 (83) 3224-5945 (Home)



On Tue, Nov 10, 2009 at 8:46 PM, Steven Boscarine
<steven.boscarine at childrens.harvard.edu> wrote:
> This reminds me of Ubuntu's Paper Cuts
> (https://lists.ubuntu.com/archives/ubuntu-devel/2009-June/028354.html)
> Little things really add up after awhile and drive away users to Spring,
> Groovy, or even off Java.   I know of many python and ruby shops in
> Boston that are run by frustrated former Java programmers.
>
> In my opinion, it's really worth your time to consider ways to make CDI
> as friendly to users as you possibly can.
>
> Those elements of polish really help new users and make using your
> product a much nicer experience and will drive Weld adoption, Gavin King
> book sales, etc :)
>
> I really think your users will thank you.
>
>
>
> Gavin King wrote:
>>   class FacesContextProducer {
>>      @Produces @RequestScoped FacesContext getFacesContext() {
>>          return FacesContext.getCurrentInstance();
>>       }
>>   }
>>
>>
>> On Tue, Nov 10, 2009 at 5:25 PM, Steven Boscarine
>> <steven.boscarine at childrens.harvard.edu> wrote:
>>
>>> Hello All,
>>> If it matters any, I agree with Dan 100% and think many users will
>>> appreciate the change.
>>> It is a convenient timesaver and makes it easy to mock the FacesContext for
>>> unit tests.
>>> I presently get around it by abstracting code that does useful work away
>>> from the FacesContext and into a separate class that is decoupled from JSF
>>> or any web frameworks.  The downside is this approach is that I often end up
>>> with modules with a few too many classes to do a simple job.
>>>
>>> Although this is probably far-fetched, aren't there threading concerns with
>>> mocking FacesContext.setCurrentInstance() ?  Doesn't that mean two tests
>>> running in parallel cannot have different FacesContext objects (without
>>> locking)?
>>> We are very concerned with scalability in the heathcare field and do
>>> multi-threaded TestNG integration tests regularly.
>>> Thanks,
>>> Steven Boscarine
>>> Pr Software Engineer
>>> Children's Hospital Boston
>>>
>>>
>>> Dan Allen wrote:
>>>
>>>> I couldn't imagine writing a JSF application without accessing
>>>> FacesContext. It's not even a matter of a perfect world vs the real world.
>>>> The FacesContext was designed to be accessed. Add faces messages. Push a
>>>> file. Check the value of a UIComponent for cross field validation. I'm sure
>>>> I could think of many other cases.
>>>>
>>>> Having to access using FacesContext.getCurrentInstance() is so ugly.
>>>>
>>>> -Dan
>>>>
>>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>