dev@javaserverfaces.java.net

RE: JSF 2 - Annotations

From: Mario Ivankovits (Apache) <"Mario>
Date: Mon, 24 Nov 2008 09:13:59 +0100

Hi!

Yep, I've never done this before, but should be possible.
But with all the configuration possibilities like EL-Resolver overrieds and custom scope configuration, creating an AnnotationProcessor effectively means to bootup the JSF environment at compile time to being able to make these checks.

Ciao,
Mario

From: Ken.Paulsen_at_Sun.COM [mailto:Ken.Paulsen_at_Sun.COM]
Sent: Monday, November 24, 2008 7:22 AM
To: dev_at_javaserverfaces.dev.java.net
Subject: Re: JSF 2 - Annotations


FYI, If the annotations are processed at compile time, it could cause the compilation to fail in this case too.

Ken

Mario Ivankovits (Apache) wrote:

Hi!





-----Original Message-----

From: Ken.Paulsen_at_Sun.COM<mailto:Ken.Paulsen_at_Sun.COM> [mailto:Ken.Paulsen_at_Sun.COM]

Sent: Sunday, November 23, 2008 12:55 AM

To: dev_at_javaserverfaces.dev.java.net<mailto:dev_at_javaserverfaces.dev.java.net>

Subject: Re: JSF 2 - Annotations





Another possibility would be this:



    @ManagedBean("#{sessionScope.userInfo}")

    public class UserSessionInformationBean {

       ...

    }



This would make the decl and the PDL look the same... not much

additional work to process either.





The way it is now is fine I think, that makes things fail on compile instead on runtime, which, for me, is always better.



Ciao,

Mario







Ken



Ryan Lubke wrote:



Mario Ivankovits (Apache) wrote:



As far as I know you can not have extended classes after the scope=

stuff, you need to use exactly the class as configured by the

annotation interface.



Means, if you'd like to introduce a new scope you need another way



of



dealing with that.

Something like scope=Scope.CUSTOM and then any additional custom

annotation.



Using @SessionScoped, @RequestScoped and later on a custom scope

@ConversationScoped (probably all inherited from a Scope annatation)

makes things the same for all use-cases.

It is more extensible that way.



I am not sure if custom scopes are planned for JSF 2, though, but I

think at least they are doable then ... in another spec.



But, for sure, just wild guesses if this was the motivation behind

that.



Indeed, if we did use enums, custom scopes would be a lot more



difficult.



Ciao,

Mario









-----Original Message-----

From: mwessendorf_at_gmail.com<mailto:mwessendorf_at_gmail.com> [mailto:mwessendorf_at_gmail.com] On



Behalf Of



Matthias Wessendorf

Sent: Saturday, November 22, 2008 1:11 PM

To: dev_at_javaserverfaces.dev.java.net<mailto:dev_at_javaserverfaces.dev.java.net>

Subject: JSF 2 - Annotations



Hi,



I wonder about things like this:

@ManagedBean(name = "userInfo")

@SessionScoped

public class UserSessionInformationBean

{

  ...

}



Why not using the Shale way of things ?



==> @Bean(name="mybean", scope=Scope.SESSION)

(where scope is an enum)



Thanks!

Matthias



--

Matthias Wessendorf



blog: http://matthiaswessendorf.wordpress.com/

sessions: http://www.slideshare.net/mwessendorf

twitter: http://twitter.com/mwessendorf



-------------------------------------------------------------------



--



To unsubscribe, e-mail: dev-



unsubscribe_at_javaserverfaces.dev.java.net<mailto:unsubscribe_at_javaserverfaces.dev.java.net>



For additional commands, e-mail: dev-



help_at_javaserverfaces.dev.java.net<mailto:help_at_javaserverfaces.dev.java.net>









---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net<mailto:dev-unsubscribe_at_javaserverfaces.dev.java.net>

For additional commands, e-mail: dev-



help_at_javaserverfaces.dev.java.net<mailto:help_at_javaserverfaces.dev.java.net>



---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net<mailto:dev-unsubscribe_at_javaserverfaces.dev.java.net>

For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net<mailto:dev-help_at_javaserverfaces.dev.java.net>






--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net