Hi 2010/5/19 Jan-Kees van Andel <[email protected]>
> Sounds plausible, we already do the same thing with the ExternalContexts > class. > > It's blazing fast, but the question is: Are we allowed to and do we want to > cache the instance? > > In theory yes, because it does not change the behavior expected by the spec. > If the spec doesn't dictate otherwise, I'm in favor of caching it. > > Another idea is to cache it in the ServletContext. It's not as fast as a > static final field, but still pretty fast and can be inspected and modified > through appserver tooling. > > The problem is from UIInput.setValue() or UIInput.setSubmittedValue() we don't have access to ServletContext (the only way is through FacesContext.getCurrentInstance().getExternalContext(), and we want to avoid the call to FacesContext.getCurrentInstance() ). Talking with Gerhard, the conclusion was a static var could do the job. Is just unrealistic assume someone has a production environment with some applications with project stage "production" and others "development" (note shared variables are "shared" by all applications hosted in a web server). In the worst case, the applications will continue working. regards, Leonardo > Regards, > Jan-Kees > > > 2010/5/19 Gerhard Petracek <[email protected]> > >> we don't have to cache the faces-context. >> we can use e.g. an interface with a static final field. >> >> usage (example): >> if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE)) >> { >> //... >> } >> >> -> there is just one evaluation. >> >> regards, >> gerhard >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> 2010/5/19 Leonardo Uribe <[email protected]> >> >> Hi >>> >>> The problem in this case is the only place we can store this information >>> is the component instance itself. So, at least there is one lookup per >>> component. >>> >>> If we try to cache facesContext, unfortunately there is not safe way to >>> clean this reference (portlet case), so there is a risk of use old instances >>> of this object in this case. >>> >>> regards, >>> >>> Leonardo Uribe >>> >>> 2010/5/19 Gerhard Petracek <[email protected]> >>> >>> hi, >>>> >>>> as long as we don't want to change the project stage dynamically, we can >>>> just store e.g. a marker as static information. >>>> >>>> regards, >>>> gerhard >>>> >>>> >>>> http://www.irian.at >>>> >>>> Your JSF powerhouse - >>>> JSF Consulting, Development and >>>> Courses in English and German >>>> >>>> Professional Support for Apache MyFaces >>>> >>>> >>>> >>>> 2010/5/19 Jakob Korherr <[email protected]> >>>> >>>> Hi Martin, >>>>> >>>>> Indeed, we have to call FacesContext.getCurrentInstance() everytime. >>>>> >>>>> So I guess it will be better to remove the code from UIInput! >>>>> >>>>> Regards, >>>>> Jakob >>>>> >>>>> 2010/5/19 Martin Marinschek <[email protected]> >>>>> >>>>> Hi Jakob, >>>>>> >>>>>> > The problem with this is that the code on UIInput checks the >>>>>> ProjectStage >>>>>> > everytime setSubmittedValue() or setValue() are called, which is >>>>>> very often >>>>>> > and could make MyFaces a bit slower, I guess. If we remove this code >>>>>> on >>>>>> > UIInput, the debug output will stay mostly the same except for the >>>>>> call >>>>>> > stack, because this will be gone. >>>>>> > >>>>>> > The question now is if we should leave it the way it currently is >>>>>> (with the >>>>>> > code on UIInput and the possibility to display the call stack) or if >>>>>> we >>>>>> > should remove the code from UIInput (which means no slowdown on >>>>>> > setSubmittedValue() and setValue() but loosing the call stack). What >>>>>> do you >>>>>> > guys think? Any opinions/objections? >>>>>> >>>>>> for me it is a question how fast this getProjectStage() derivation is. >>>>>> If that means to call FacesContext.getCurrentInstance() all the time, >>>>>> the impact is considerable (thread-local resolution). In this case it >>>>>> might be better to not have this information... >>>>>> >>>>>> Martin >>>>>> >>>>>> > Regards, >>>>>> > Jakob >>>>>> > >>>>>> > -- >>>>>> > Jakob Korherr >>>>>> > >>>>>> > blog: http://www.jakobk.com >>>>>> > twitter: http://twitter.com/jakobkorherr >>>>>> > work: http://www.irian.at >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> http://www.irian.at >>>>>> >>>>>> Your JSF powerhouse - >>>>>> JSF Consulting, Development and >>>>>> Courses in English and German >>>>>> >>>>>> Professional Support for Apache MyFaces >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jakob Korherr >>>>> >>>>> blog: http://www.jakobk.com >>>>> twitter: http://twitter.com/jakobkorherr >>>>> work: http://www.irian.at >>>>> >>>> >>>> >>> >> >
