The easy way out is to use EL to bind actions to view config enums:

@ViewConfig

public interface ApplicationViewConfig {

    static enum Views {

        @ViewAction("#{bean.loadItem}")

        VIEW_ITEM

    }

}

However, that requires all sorts of named beans and it's just pretty off base from what CDI is all about.

A far better solution is to use binding annotations, just like qualifiers and interceptor bindings from CDI and security bindings from Seam Faces.

To make this as strongly typed as possible, we want to allow the developer to refer to the view config in the value attribute of the binding annotation. Thus, they first define the binding:

@ViewActionBindingType

@Retention(RUNTIME)

@Target(ElementType.METHOD)

public @interface ViewAction {

    Views[] value();

}

Then, they annotate the method they want to call.

@ViewAction(VIEW_ITEM)

public void loadItem() {

    ...

}

The best part is, that method can have injected arguments. The injected argument could be a bean populated by a PrettyFaces mapping, viewParam or a converted request parameter (provided by Seam Servlet):

@ViewAction(VIEW_ITEM)

public void loadItem(@Selected Item item) {

    ...

}

or

@ViewAction(VIEW_ITEM)

public void loadItem(@RequestParam("id") Long id) {

    ...

}

If you needed the action for view and edit, you just do:

@ViewAction({VIEW_ITEM, EDIT_ITEM})

public void loadItem(@RequestParam("id") Long id) {

    ...

}

We should also allow view actions to be nested:

The only part that sucks is that the user has to create the @ViewAction annotation so that it's linked to the view config enum (stupid Java). We could recommend adding this annotation as part of the view config class file (or even have tooling generate it).

Hello Dan,

I don't like the fact that view configuration and view actions are separated.

With your proposition, I must look at :

@ViewConfig

public interface ApplicationViewConfig {

    static enum Views {

        @ViewPattern("/item/*")

        VIEW_ITEM

    }

}

and afterwards search in all *.java files VIEW_ITEM occurence (ouch ! horrible !) :

@ViewAction({VIEW_ITEM, EDIT_ITEM})

public void loadItem(@RequestParam("id") Long id) {

    ...

}

While in the untyped approach, I just have all in the same place :

@ViewConfig

public interface ApplicationViewConfig {

    static enum Views {

        @ViewPattern("/item/*")

        @ViewAction("#{bean.loadItem}") 

        VIEW_ITEM

    }

}

However, that requires all sorts of named beans and it's just pretty off base from what CDI is all about.

I don't see your point : ViewAction are for Jsf views. A Jsf view can only call named bean via JSF El.
So IMO, it's not odd to have this restriction for ViewActions.

Anyway, my main point is really to be able to centralize view navigation, view actions, view restrictions, etc... (the simplest to use and to understand = the best)

Dupont,

With Seam 3 tooling, this is going to work out really nicely, just like jumping from where an event is fired to where it is observed, or jumping between injection point and bean. This is a case where tooling really pays off. Plus, we can have an Eclipse view that shows all the actions for a view. Max's team should be able to turn around this feature pretty quickly, as soon as we have it implemented in Seam Faces.

I don't see your point : ViewAction are for Jsf views. A Jsf view can only call named bean via JSF El.
So IMO, it's not odd to have this restriction for ViewActions.

That's not true. The view controller in Seam Faces (the component that interprets the view configuration) can invoke anything reachable from CDI, including type-safe lookups. We've just been limited in the past. We are breaking those barriers.

Anyway, my main point is really to be able to centralize view navigation, view actions, view restrictions, etc... (the simplest to use and to understand = the best)

I want that too. And I assure you that by using this binding concept, we achieve that.

I want that too. And I assure you that by using this binding concept, we achieve that.

You may need to trust the vision on this one if it's not immediately obvious.

Btw, I am willing to meet half way and also implement @UrlAction that you place directly on the view enum. The binding annotation is the preferred way, but the @UrlAction is the "busy man's" approach.

Correction, let's call the built-in annotation that accepts an EL method expression @ViewAction.

The binder annotation will be called @ViewActionBindingType. Then, the user can use whatever name they want, including a @ViewAction in their own package, or whatever other name they want.

You may need to trust the vision on this one if it's not immediately obvious.

All right, I'm putting my faith in you

Btw, I am willing to meet half way and also implement @UrlAction that you place directly on the view enum.

Geez cool ! Thanks Dan !

Note about tooling : not sure to have JBoss Tooling in my environment - were using IBM RAD - and RAD is always a step behind JBoss Tools when talking about eclipse version.