[weld-dev] @Inject FacesContext
Steven Boscarine
steven.boscarine at childrens.harvard.edu
Tue Nov 10 17:46:54 EST 2009
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
>>>
>>>
>>
>
>
>
>
More information about the weld-dev
mailing list