On 7/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Craig, > > It sounds like your saying the spec aims at discouraging certain bad > practices of the past. During the spec's "childhood" were there ever any > arguments about it encouraging new bad practices. I ask this because I have > found myself wanting to abuse FacesContext.getCurrentInstance() as a source > of global variable use. Sometimes, it doesn't feel like Java. > > Dennis Byrne >
The expert group mailing list had many periods where there were so many messages, with well reasoned but sometimes vociferous positions, it makes the MyFaces lists look absolutely quiet and boring :-). On the particular issue of FacesContext.getCurrentInstance(), a very high percentage of all the stuff you do inside JSF requires access to the FacesContext instance for the current request. At the API design level, that means you either need to pass such an instance in to every method call that you think will need it -- and *hope* that you didn't screw up and leave one out -- or provide a static method that can get to the current instance, which lets you simplify the calling sequences. As you can see, we ended up with a compromise about half way in between ... where it was clear that you were going to have access anyway (such as the decode or encodeXxx methods of a component or renderer), passing the context explictly ... which has a performance advantage, because getCurrentInstance() is typically implemented as a ThreadLocal, where the cost to access it is substantially larger than a simple instance variable retrieval. On the other hand, the "global variable" escape hatch that let us maintain simplicity in many other APIs ... for example, the calling sequence to an action method. Yes, we could have required that a FacesContext be passed in, but in many cases the action method doesn't actually need it. To say nothing of the fact that this would *require* backing beans to depend on JSF APIs to be compiled, which makes them a bit more complicated to use and write unit tests for. Pretty much nothing in API design is purely good or purely evil ... it's always about finding the compromises that maximize the overall good and minimize the overall evil. Craig PS: By the way, don't blame JSF for global variables ... blame Java for providing ThreadLocal to make it possible even without JSF :-).
