Possibilities for Annotations in JSF

Discussions

News: Possibilities for Annotations in JSF

Bookmark and Share Get thread feed

  1. Possibilities for Annotations in JSF (15 messages)

    Based on some of the comments on annotations made by Ed Burns (JSF Spec lead) in the recent Daniel Hinojosa wants replaceable managed beans in JSF post on TSS, Duncan Mills discusses some of the possibilities that a broader adoption of annotations might bring to JSF.

    Some of them include: lifecycle methods, postback indicators (i.e., being able to tell if this is the original request, or a postback), routing capabilities ("return this view if the principal is in a given role"), security, and configuration outside of XML.
    Even a short consideration of annotation possibilities within JSF raises more issues than I care to think about. However, there is no doubt that some areas such as security, where the linkage problem is not an issue, could be a very effective use of the annotation technique. I would certainly like to see the Expert Group address some of these possibilities in the future, hand in hand with the perhaps more important issues such as process scoping and sub-flows.

    Are annotations the right way to go? Are there more opportunities for using annotations that you can see?
    Reply to this

    Threaded Messages (15)

  2. Possibilities for Annotations in JSF[ Go to top ]

    You have to draw a very fine line though as to what JSF actually is... which is a UI component framework. A majority of the annotations he suggested pertain to Model/Controller behavior, outside of the UI component framework. So while there's opportunity to introduce UIComponent annotations-- POJO components within the JSF spec, the annotations that Duncan covers would be better used within a separate framework that is aware of persistence/business behavior concerns and lifecycle management outside of just the UI and is able to annotate concerns that aren't necessarily JSF specific, but leverage it's event-driven design and listener capabilities.
    Reply to this Reply to original

  3. Grey Area[ Go to top ]

    Like it or not, JSF does play in the controller space and as such I feel that most of the suggestions are legitimate for discussion. But certainly the @Role annotation could be applied to any any bean in a container.
    Reply to this Reply to original

  4. It is so bad.[ Go to top ]

    Why do we use that? It's a very bad thing.
    Reply to this Reply to original

  5. It is so bad.[ Go to top ]

    Why do we use that? It's a very bad thing.

    Could you please explain *why* you think using annotations in the described manner is "very bad"? I am definitely on the skeptical end of the opinion spectrum on many aspects of annotations, but I find myself generally agreeing with Duncan's description of use cases where annotations make sense (as well as where they do not make sense).

    Craig McClanahan
    Reply to this Reply to original

  6. Possibilities for Annotations in JSF[ Go to top ]

    Of these, the lifecycle-ish ones look most viable to me. I don't think your managed beans is the right place to handle security. I think you are better handling it either:

    1) Above, at the page layer (in web.xml configuration)

    2) Below, at your services layer (e.g. in your EJB/Spring configuration).

    Of the lifecycle methods, though, I like a lot of the suggestions. The postback indicators especially have possibilities.

    As is generally the case with Annotations, I'd also like non-Annotation alternatives (XML or lifecycle interfaces).
    Reply to this Reply to original

  7. Possibilities for Annotations in JSF[ Go to top ]

    I would love to see annotations for
    Managed Beans
    Custom Validators, Converters and Components

    Also an option to generate the faces-config.xml entries for those annotations would be a nice feature.
    Something like:

    @Converter
    @AddToFacesConfig
    Reply to this Reply to original

  8. Implicit JSF annotations:[ Go to top ]

    @DOA
    @DoYouHaveThatLatest32WayToRunHelloWorld
    @DoYouReadyToMissAnotherImportantDeadline
    Reply to this Reply to original

  9. Implicit JSF annotations:[ Go to top ]

    @DOA
    @DoYouHaveThatLatest32WayToRunHelloWorld
    @DoYouReadyToMissAnotherImportantDeadline

    Wait for an announcement at the beginning of next week :-)
    Reply to this Reply to original

  10. Annotations and the IDE[ Go to top ]

    It seems to me annotations ease the development process, leading to a reduced need for an expensive IDE.
    Reply to this Reply to original

  11. Expensive IDE?[ Go to top ]

    What "expensive" IDE are people using these days??
    Reply to this Reply to original

  12. Possibilities for Annotations in JSF[ Go to top ]

    As a follow up to my first reply, check out a new product from JBoss called, "Seam". Instead of driving annotations from the view, it builds off of the EJB 3 spec to enhance JSF. Awesome stuff, and I mean *awesome*. You get all of the validation, injection (IoC), variable management, and transaction management as driven by your business model. It's annotations done the right.

    As an example, one of my big pet peeves with JSF is the inability to assert logic on actions, Seam has that covered. Just do something like @LoggedIn, or @OrderInProgress over your bean's action methods. The foundation and capabilities are there to guarantee that JSF is the winner for Java WebTier.

    Here's a tutorial:
    http://docs.jboss.com/seam/reference/en/html/tutorial.html

    Main Page:
    http://jboss.com/products/seam

    -- Jacob (JSF EG)
    Reply to this Reply to original

  13. Possibilities for Annotations in JSF[ Go to top ]

    I should have also mentioned that this is the brain child of Gavin King, it wasn't enough that he took EJB to the next level, now he had to get his hands into the web tier ;-)
    Reply to this Reply to original

  14. Brainchild[ Go to top ]

    With all my respect to Gavin it concerns me when backend people try to do UI.
    ORACLE Forms etc...
    Reply to this Reply to original

  15. Just wrong[ Go to top ]

    Oh please don't give me 10 more ways to do JSF. I find it boated enough as it is just now.

    JSP JSTL JFS etc.. containers are backwards compatible so you are able so see mixed implentations for a long time. Adding options to the mix just makes is more fussy. All of a sudden there is behavoir you did not forsee because someone has added an annotation somewhere you overlooked.

    I would much more prefer an industry effort to make XUL a dominant player. This is what you can do with XUL just now. http://faser.net/mab/

    So to google: Google make the XUL Browser IDE thing.
    AOL: cut ties with Microsoft and ship FF
    SUN: Free Java
    IBM, Oracle, HP, SAP, Eclipse foundation: create new web platform around XUL

    Or else, deal with MS XAML
    Reply to this Reply to original

  16. Just wrong[ Go to top ]

    Oh please don't give me 10 more ways to do JSF.

    One could make the same statement about the servlet container itself...

    Pertaining to XUL, JSF is setting its sights on XUL, there are already a couple major vendors working on XUL Renderers. I wrote about XUL and JSF a while back on Java.net too.
    Reply to this Reply to original