Hi,
On Tue, Dec 15, 2015 at 4:47 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> I like the idea of supplanting the faces-config.xml with a @FacesConfig
> annotation. It's also much like what Spring Boot does.
>
Okay, interesting.
I only wonder what kind of class this annotation should best be put on.
>
Yeah, in the example (and my experimental code) it's just any random class.
This could be an otherwise empty class even.
Going another step further the class could (optionally) implement methods
that returns config programmatically.
@FacesConfig
public class MyConfig {
public String getStateSavingMethod() {
return ... ? "server" : "client";
}
}
But that really is an optional proposal. The main proposal is just having
the annotation.
Kind regards,
Arjan Tijms
> Cheers, B
>
> On 14:41, Tue, Dec 15, 2015 arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
>> Hi,
>>
>> One of two ways to automatically enable JSF in a project is having either
>> a class on the class path annotated with one of the JSF native annotations,
>> or having a /WEB-INF/faces-config.xml file present.
>>
>> With the world moving to CDI, the JSF native annotations (specifically
>> @MangedBean) are not so much used anymore. This way to enable JSF is not so
>> practical anymore.
>>
>> A faces-config.xml file is still a simple way, if it wasn't for the fact
>> that officially (if I'm not mistaken) it can't be just an empty file like
>> CDI's bean.xml. Looking up the right schema for trivial applications is a
>> bit of a hassle.
>>
>> I was thinking that instead of using existing JSF annotations that as a
>> side-effect enable JSF, it might be worth looking into a JSF annotation
>> that is specifically intended to enable JSF.
>>
>> E.g.
>>
>> @ActivateJSF
>> public class JustAClass {
>>
>> }
>>
>> The name "ActivateJSF" is just an example and could be any other name.
>> Some other candidates @JSF, @JSFConfig, @JSFActivation, @ActivateFaces,
>> @FacesConfig, @FacesParams, etc
>>
>> In the simplest version this will just activate JSF like @ManagedBean
>> does, but without the side effect of also creating a (potentially unused)
>> managed bean.
>>
>> One step further may be to add some configuration options, potentially
>> the annotation variant of the various web.xml settings.
>>
>> E.g.
>>
>> @ActivateJSF(
>> stateSavingMethod = "server"
>> )
>>
>> Or a new option, to indicate the JSF version:
>>
>> @ActivateJSF(
>> version = "2.3" // enables all JSF 2.3 features
>> )
>>
>> @ActivateJSF(
>> version = "2.2" // behaves as much as possible as 2.2 did
>> )
>>
>> Yet another step further, if the class on which @ActivateJSF appears is a
>> CDI bean, alternatives can be used to switch configuration.
>>
>> I experimented with this locally in the Mojarra source code, and in some
>> experiments it worked quite nicely.
>>
>> Thoughts?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>