...
First of all it's important to mention that CODI starts (grouped) conversations automatically as soon as you access conversation scoped beans. Furthermore, the invocation of Conversation#close
leads to an immediate termination of the conversation.
Code Block |
---|
| java |
---|
| java |
---|
title | A CODI conversation scoped bean | java |
---|
|
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationGroup;
@ConversationScoped
public class DemoBean1 implements Serializable
{
//...
}
|
...
(In case of CDI std. conversations there is just one big conversation which contains all conversation scoped beans.)
The grouped conversations provided by CODI are completely different. By default every conversation scoped bean exists in an "isolated" conversation. That means there are several parallel conversations within the same window.
Example:
Code Block |
---|
| java |
---|
| java |
---|
title | Separated CODI conversationsjava |
---|
|
@ConversationScoped
public class DemoBean2 implements Serializable
{
//...
}
@ConversationScoped
public class DemoBean3 implements Serializable
{
//...
}
|
...
If you have an use-case (e.g. a wizard) which uses multiple beans which are linked together very tightly, you can create a type-safe conversation group.
Code Block |
---|
| java |
---|
| java |
---|
title | Grouped conversation scoped beansjava |
---|
|
interface Wizard1 {}
@ConversationScoped
@ConversationGroup(Wizard1.class)
public class DemoBean4 implements Serializable
{
//...
}
@ConversationScoped
@ConversationGroup(Wizard1.class)
public class DemoBean5 implements Serializable
{
//...
}
|
You can use @ConversationGroup
to tell CODI that there is a logical group of beans. Technically @ConversationGroup
is just a CDI qualifier. Internally CODI uses this information to identify a conversation. In the previous example both beans exist in the same conversation (group). If you terminate the conversation group, both beans will be destroyed. If you don't use @ConversationGroup
explicitly, CODI uses the class of the bean as conversation group.
Code Block |
---|
| java |
---|
| java |
---|
title | Injecting a conversation scoped bean with an explicit groupjava |
---|
|
//...
public class CustomBean1
{
@Inject
@ConversationGroup(Group1.class)
private CustomBean2 demoBean;
@Inject
@ConversationGroup(Group2.class)
private CustomBean2 demoBean;
}
|
Since @ConversationGroup
is a std. CDI qualifier you have to use it at the injection point. You have to do that esp. because it's possible to create beans of the same type which exist in different groups (e.g. via producer methods).
Example:
Code Block |
---|
| java |
---|
| java |
---|
title | Producer methods which produce conversation scoped beans with different groups | java |
---|
|
interface Group1 {}
interface Group2 {}
public class CustomBean2
{
@Produces
@ConversationScoped
@ConversationGroup(Group1.class)
public CustomBean2 createInstanceForGroup1()
{
return new CustomBean2();
}
@Produces
@ConversationScoped
@ConversationGroup(Group2.class)
public CustomBean2 createInstanceForGroup2()
{
return new CustomBean2();
}
}
|
...
You can inject the conversation via @Inject
and use it to terminate the conversation immediately (see *) or you inject the current WindowContext
which can be used to terminate a given conversation group.
Code Block |
---|
| java |
---|
| java |
---|
title | Injecting and using the current conversation | java |
---|
|
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped;
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.Conversation;
@ConversationScoped
public class DemoBean6 implements Serializable
{
@Inject
private Conversation conversation; //injects the conversation of DemoBean6 (!= conversation of DemoBean7)
//...
public void finish()
{
this.conversation.close();
}
}
@ConversationScoped
public class DemoBean7 implements Serializable
{
@Inject
private Conversation conversation; //injects the conversation of DemoBean7 (!= conversation of DemoBean6)
//...
public void finish()
{
this.conversation.close();
}
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Injecting and using the explicitly grouped conversation | java |
---|
|
interface Wizard2 {}
@ConversationScoped
@ConversationGroup(Wizard2.class)
public class DemoBean8 implements Serializable
{
@Inject
private Conversation conversation; //injects the conversation of Wizard2 (contains DemoBean8 and DemoBean9)
//...
public void finish()
{
this.conversation.close();
}
}
@ConversationScoped
@ConversationGroup(Wizard2.class)
public class DemoBean9 implements Serializable
{
@Inject
private Conversation conversation; //injects the conversation of Wizard2 (contains DemoBean8 and DemoBean9)
//...
public void finish()
{
this.conversation.close();
}
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Terminating a grouped conversation outside of the conversationjava |
---|
|
//...
public class DemoBean10 implements Serializable
{
@Inject
private WindowContext windowContext; //injects the whole window context (of the current window)
//...
public void finish()
{
this.windowContext.closeConversationGroup(Wizard2.class); //closes the conversation of group Wizard2.class
}
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Alternative approach for terminating a conversation groupjava |
---|
|
//...
public class DemoBean10 implements Serializable
{
//...
@CloseConversationGroup(group = Wizard2.class)
public void finish()
{
//...
}
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Alternative approach for terminating a conversation group in case of an exception | java |
---|
|
//...
public class DemoBean10 implements Serializable
{
//...
@CloseConversationGroup(group = Wizard2.class, on = MyRuntimeException.class)
public void finish()
{
//...
}
}
|
These two alternative approaches can be used for simple use-cases.
Code Block |
---|
| java |
---|
| java |
---|
title | Terminate all conversations | java |
---|
|
//...
public class DemoBean11 implements Serializable
{
@Inject
private WindowContext windowContext;
//...
public void finish()
{
this.windowContext.closeConversations(); //closes all existing conversations within the current window (context)
}
}
|
...
Instead of destroying the whole conversation the conversation stays active and only the scoped instances are destroyed. (The conversation will be marked as accessed.) As soon as an instance of a bean is requested, the instance will be created based on the original bean descriptor. This approach allows a better performance, if the conversation is needed immediately (e.g. if you know in your action method that the next page will/might use the same conversation again).
Code Block |
---|
| java |
---|
| java |
---|
title | Restarting a conversationjava |
---|
|
@ConversationScoped
public class DemoBean12 implements Serializable
{
@Inject
private Conversation conversation;
//...
public void finish()
{
this.conversation.restart();
}
}
|
...
A sub-group is just a class or an interface used to identify a bunch of beans within a group. To terminate such a sub-group, it's just needed to pass the class/interface to the corresponding API for terminating a conversation. The sub-group gets detected autom. and instead of terminating a whole conversation-group, the beans of the sub-group get un-scoped.
Code Block |
---|
| java |
---|
| java |
---|
title | Explicitly listing beans of a sub-groupjava |
---|
|
public class MyGroup{}
@ConversationScoped
@ConversationGroup(MyGroup.class)
public class BeanA {}
@ConversationScoped
@ConversationGroup(MyGroup.class)
public class BeanB {}
@ConversationScoped
@ConversationGroup(MyGroup.class)
public class BeanC {}
@ConversationSubGroup(subGroup = {BeanA.class, BeanB.class})
public class MySubGroup extends MyGroup {}
or
@ConversationSubGroup(of = MyGroup.class, subGroup = {BeanA.class, BeanB.class})
public class MySubGroup {}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Terminating a sub-group | java |
---|
|
this.windowContext.closeConversation(MySubGroup.class)
|
As you see the class/interface of the sub-group has to extend/implement the group or you specify it via the @ConversationSubGroup#of
. With @ConversationSubGroup#subGroup
you can list all beans which belong to the sub-group. If you have a lot of such beans or you would like to form (sub-)use-case oriented groups, you can use implicit groups:
Code Block |
---|
| java |
---|
| java |
---|
title | Implicit sub-groupjava |
---|
|
public interface Wizard {}
@ConversationSubGroup(of = MyGroup.class, subGroup = Wizard.class)
public class ImplicitSubGroup
{
}
@Named("myWizard")
@ConversationScoped
@ConversationGroup(MyGroup.class)
public class WizardController implements Serializable, Wizard
{
//...
}
this.windowContext.closeConversationGroup(ImplicitSubGroup.class);
|
...
The usage of this scope is very similar to normal conversations. Only the cleanup strategy is different and the concept itself doesn't need/support the usage of @ConversationGroup
.
Code Block |
---|
| java |
---|
| java |
---|
title | Window scoped beanjava |
---|
|
@WindowScoped
public class PreferencesBean implements Serializable
{
//...
}
|
...
Since WindowContext#closeConversations
doesn't affect window scoped beans we need a special API for terminating all window scoped beans.
If you don't use qualifiers for your window scoped beans, you can just inject the conversation into a window scoped bean and invoke the methods discussed above. If you don't have this constellation, you can use the WindowContext
to terminate the window scoped beans or the whole window context. If you terminate the whole window, you also destroy all conversation and view-access scoped beans automatically.
Code Block |
---|
| java |
---|
| java |
---|
title | Terminate the whole content of the windowjava |
---|
|
//...
public class CustomWindowControllerBean1
{
@Inject
private WindowContext windowContext;
//...
public void closeWindow()
{
this.windowContext.close();
}
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Terminate all window scoped beans | java |
---|
|
//...
public class CustomWindowControllerBean2
{
@Inject
private WindowContext windowContext;
//...
public void finish()
{
this.windowContext.closeConversationGroup(WindowScoped.class);
}
}
|
...
In case of conversations you have to un-scope beans manually (or they we be terminated automatically after a timeout). However, sometimes you need beans with a lifetime which is as long as needed and as short as possible - which are terminated automatically (as soon as possible). In such an use-case you can use this scope. The simple rule is, as long as the bean is referenced by a page - the bean will be available for the next page (if it's used again the bean will be forwarded again). It is important that it's based on the view-id of a page (it isn't based on the request) so e.g. Ajax requests don't trigger a cleanup if the request doesn't access all view-access scoped beans of the page. That's also the reason for the name @*View*AccessScoped.
Code Block |
---|
| java |
---|
| java |
---|
title | Access scoped beanjava |
---|
|
@ViewAccessScoped
public class WizardBean implements Serializable
{
//...
}
|
...
Our Rest Scope is a Conversation which intended for GET pages. On the first access to such a bean on a view which gets invoked via GET, all the f:viewParam will be parsed and stored internally. This RestScoped conversation automatically expires once the bean gets accessed via GET on another view or with a different set of f:viewParam.
Code Block |
---|
| java |
---|
| java |
---|
title | RestScoped beanjava |
---|
|
@RestScoped
public class CarBean implements Serializable
{
//...
}
|
...
With JSF2 you can use GET-Requests with h:link
. It's recommended to use it instead of a plain HTML link.
Code Block |
---|
| xml |
---|
| xml |
---|
title | JSF2 component for GET-Requestsxml |
---|
|
<h:link value="My Page" outcome="myPage"/>
|
However, if you have a good reason for it and you really have to use a plain HTML link instead, you have to use something like:
Code Block |
---|
| xml |
---|
| xml |
---|
title | HTML link as an alternative to the JSF2 component for GET-Requests | xml |
---|
|
<a href="#{facesContext.externalContext.request.contextPath}/myPage.xhtml?windowId=#{currentWindow.id}">My Page< /a >
|
...
Example for a validator:
Code Block |
---|
| java |
---|
| java |
---|
title | @Inject within a JSF validator | java |
---|
|
@Advanced
@FacesValidator("...") //use it just in case of JSF 2.0
public class DependencyInjectionAwareValidator implements Validator
{
@Inject
private CustomValidationService customValidationService;
public void validate(FacesContext facesContext, UIComponent uiComponent, Object value) throws ValidatorException
{
Violation violation = this.customValidationService.validate(value);
//...
}
}
|
Example for a converter:
Code Block |
---|
| java |
---|
| java |
---|
title | @Inject within a JSF converter | java |
---|
|
@Advanced
@FacesConverter("...") //use it just in case of JSF 2.0
public class DependencyInjectionAwareConverter implements Converter
{
@Inject
private OrderService orderService;
public Object getAsObject(FacesContext facesContext, UIComponent uiComponent, String value)
throws ConverterException
{
if (value != null && value.length() > 0)
{
return this.orderService.loadByOrderNumber(value);
}
return null;
}
//...
}
|
...
As an alternative to a full phase-listener CODI allows to use observers as phase-listener methods.
Example:
Code Block |
---|
| java |
---|
| java |
---|
title | Global observer method for phase-eventsjava |
---|
|
protected void observePreRenderView(@Observes @BeforePhase(RENDER_RESPONSE) PhaseEvent phaseEvent)
{
//...
}
|
If you would like to restrict the invocation to a specific view, it's possible to use the optional @View
annotation.
Code Block |
---|
| java |
---|
| java |
---|
title | Observer method for phase-events for a specific view | java |
---|
|
@View(DemoPage.class)
public void observePostInvokeApplication(@Observes @AfterPhase(JsfPhaseId.INVOKE_APPLICATION) PhaseEvent event)
{
//...
}
|
...
CODI provides an annotation for phase-listeners:
Code Block |
---|
| java |
---|
| java |
---|
title | PhaseListener configured via annotation | java |
---|
|
@JsfPhaseListener
public class DebugPhaseListener implements PhaseListener
{
private static final Log LOG = LogFactory.getLog(DebugPhaseListener.class);
private static final long serialVersionUID = -3128296286005877801L;
public void beforePhase(PhaseEvent phaseEvent)
{
if(LOG.isDebugEnabled())
{
LOG.debug("before: " + phaseEvent.getPhaseId());
}
}
public void afterPhase(PhaseEvent phaseEvent)
{
if(LOG.isDebugEnabled())
{
LOG.debug("after: " + phaseEvent.getPhaseId());
}
}
public PhaseId getPhaseId()
{
return PhaseId.ANY_PHASE;
}
}
|
If you have to specify the order of phase-listeners you can us the optional @InvocationOrder
annotation.
In combination with @Advanced
it's possible to use dependency injection.
Example:
Code Block |
---|
| java |
---|
| java |
---|
title | @Inject within a JSF phase-listener | java |
---|
|
@Advanced
@JsfPhaseListener
@InvocationOrder(1) //optional
public class DebugPhaseListener implements PhaseListener
{
@Inject
private DebugService debugService;
public void beforePhase(PhaseEvent phaseEvent)
{
this.debugService.log(phaseEvent);
}
public void afterPhase(PhaseEvent phaseEvent)
{
this.debugService.log(phaseEvent);
}
public PhaseId getPhaseId()
{
return PhaseId.ANY_PHASE;
}
}
|
...
Sometimes it's essential to perform logic directly after the FacesContext
started and/or directly before the FacesContext
gets destroyed. In such a case CODI provides the annotations @BeforeFacesRequest
and @AfterFacesRequest
.
Example:
Code Block |
---|
| java |
---|
| java |
---|
title | Observer method with @BeforeFacesRequestjava |
---|
|
protected void initFacesRequest(@Observes @BeforeFacesRequest FacesContext facesContext)
{
//...
}
|
...
CODI offers a bunch of producers for JSF artifacts.
Example:
Code Block |
---|
| java |
---|
| java |
---|
title | Injection of the current FacesContext | java |
---|
|
@Inject
private FacesContext facesContext;
|
...
Helper for detecting the current phase of the JSF request lifecycle.
Example:
Code Block |
---|
| java |
---|
| java |
---|
title | Detecting the current phasejava |
---|
|
public class MyBean
{
@Inject
private JsfLifecyclePhaseInformation phaseInformation;
public void execute()
{
if (this.phaseInformation.isProcessValidationsPhase() || this.phaseInformation.isUpdateModelValuesPhase())
{
//...
}
}
}
|
...
The following example shows a simple view-config.
Code Block |
---|
| java |
---|
| java |
---|
title | View config for /home.xhtmljava |
---|
|
@Page
public final class Home implements ViewConfig
{
}
|
...
If you would like to group pages (you will learn some reasons for that later on), you can nest the classes.
Code Block |
---|
| java |
---|
| java |
---|
title | Grouping pagesjava |
---|
|
public interface Wizard extends ViewConfig
{
@Page
public final class Page1 implements Wizard
{
}
@Page
public final class Page2 implements Wizard
{
}
}
|
...
View configs allow to reflect your folder structure in the meta-classes.
Code Blockcode |
---|
| java |
---|
| java |
---|
title | Grouping pages and folder structuresjava |
---|
|
public interface Wizard extends ViewConfig
{
@Page
public final class Step1 implements Wizard
{
}
@Page
public final class Step2 implements Wizard
{
}
}
|
...
Note |
---|
|
While the nested classes lead to the final path of the file, the inheritance allows to configure a bunch of pages. |
Code Block |
---|
| java |
---|
| java |
---|
title | Grouping pages and folder structuresjava |
---|
|
@Page(navigation = REDIRECT)
public interface Wizard extends ViewConfig
{
@Page
public final class Step1 implements Wizard
{
}
@Page
public final class Step2 implements Wizard
{
}
}
|
...
It's possible to use custom annotations in view-config classes. Just annotate the custom annotation with @ViewMetaData
.
Code Block |
---|
| java |
---|
| java |
---|
title | Implementation of a custom view meta-data annotationjava |
---|
|
@Target({TYPE})
@Retention(RUNTIME)
@Documented
@ViewMetaData
public @interface ViewMode
{
//...
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Usage of a custom view meta-data annotation | java |
---|
|
@Page
@ViewMode
public final class Home implements ViewConfig
{
}
|
Optionally you can specify if a nested class (e.g. UseCase1.Step1
) overrides the meta-data. That means there will be just one instance per such a custom annotation per page. Per default all annotations are collected independent of the already found types and independent of the instance count of an annotation type.
Code Block |
---|
| java |
---|
| java |
---|
title | Implementation of a custom view meta-data annotation which allows to override meta-data | java |
---|
|
@Target({TYPE})
@Retention(RUNTIME)
@Documented
@ViewMetaData(override = true)
public @interface PageIcon
{
//...
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Override view meta-data annotation | java |
---|
|
@PageIcon(...)
public interface UseCase1 extends ViewConfig
{
@Page
//inherits the page-icon of the use-case
public final class Step1 implements Wizard
{
}
@Page
@PageIcon(...) //overrides the page-icon of the use-case
public final class Step2 implements Wizard
{
}
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Resolve view meta-data annotationsjava |
---|
|
@Inject
private ViewConfigResolver viewConfigResolver;
this.viewConfigResolver.getViewConfigDescriptor(UseCase1.Step2.class).getMetaData();
//or something like:
this.viewConfigResolver.getViewConfigDescriptor(this.facesContext.getViewRoot().getViewId()).getMetaData();
|
...
Type-safe view configs also allow to easily specify the valid page range.
Code Block |
---|
| java |
---|
| java |
---|
title | Specified page rangejava |
---|
|
public interface PublicView extends ViewConfig {}
@Page
public class ReportPage implements PublicView {}
//...
@Secured(LoginAccessDecisionVoter.class)
public interface Internal extends ViewConfig
{
@Page
public class ReportPage implements Internal {}
}
//...
public Class<? extends Internal> showInternalReport()
{
//...
return Internal.ReportPage.class;
}
//...
public Class<? extends PublicView> showPublicReport()
{
//...
return ReportPage.class;
}
|
...
In the previous section you have learned some details about the view-config mechanism provided by CODI. You can use these meta-classes for the navigation.
Example:
Code Block |
---|
| java |
---|
| java |
---|
title | Action method with type-safe navigationjava |
---|
|
public Class<? extends ViewConfig> navigateToHomeScreen()
{
return Home.class;
}
|
...
Since JSF 2.0 it's possible to use GET requests for navigating between pages. With MyFaces CODI you can use type-safe navigation also in combination with GET-Requests.
Code Block |
---|
| xml |
---|
| xml |
---|
title | JSF-Navigation via GET requests | xml |
---|
|
<!-- Std. approach with JSF 2.0: -->
<h:button value="..." outcome="/pages/myPage.xhtml">
<f:param name="param1" value="v1"/>
</h:button>
<!-- CODI allows to use: -->
<h:button value="..." outcome="#{myController.myPage}">
<f:param name="param1" value="v1"/>
</h:button>
<!-- or if needed (not recommended, because it isn't type-safe): -->
<h:button value="..." outcome="class myPackage.Pages.MyPage">
<f:param name="param1" value="v1"/>
</h:button>
|
Code Block |
---|
| xml |
---|
| xml |
---|
title | The corresponding code in MyController | xml |
---|
|
public Class<? extends ViewConfig> getMyPage()
{
return Pages.MyPage.class;
}
|
...
In case of type-safe navigation it's possible to observe navigations which have a view-config for the source-view as well as the target-view.
Code Block |
---|
| java |
---|
| java |
---|
title | Observe type-safe navigation event | java |
---|
|
protected void onViewConfigNavigation(@Observes PreViewConfigNavigateEvent navigateEvent)
{
//...
}
|
Furthermore, it's possible to change the navigation target.
Code Block |
---|
| java |
---|
| java |
---|
title | Observe type-safe navigation eventjava |
---|
|
protected void onViewConfigNavigation(@Observes PreViewConfigNavigateEvent navigateEvent)
{
if(Wizard.Page1.class.equals(navigateEvent.getFromView()) &&
!Wizard.Page2.class.equals(navigateEvent.getToView()))
{
navigateEvent.navigateTo(DemoPages.HelloMyFacesCodi2.class);
}
}
|
...
Sometimes it's needed to add parameters. If you are using e.g. the implicit navigation feature of JSF 2.0+ you would just add them to the string you are using for the navigation. In case of type-safe view-configs it isn't possible to add such parameters directly. To add such parameters, it's required to use the @PageParameter
annotation. It's possible to annotate action-methods or view-config classes which represent a page with this annotation. So it's possible to enforce parameters for all JSF based navigations to a view or to add parameters just in case of special actions. Furthermore, it's possible to add multiple parameters with @PageParameter.List
. The usage for action methods is the same as the usage for view-configs. The following example shows a simple parameter.
Code Block |
---|
|
@Page
@PageParameter(key="customParam", value="#{customBean.value1}")
public class Index implements ViewConfig {}
|
Type-safe Security
Code Block |
---|
| java |
---|
| java |
---|
title | Action method with type-safe navigation | java |
---|
|
@Page
@Secured(OrderVoter.class)
public final class OrderWizard implements ViewConfig
{
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Example for an AccessDecisionVoterjava |
---|
|
@ApplicationScoped
public class OrderVoter extends AbstractAccessDecisionVoter
{
@Inject
private UserService userService;
@Inject
private User currentUser;
public void checkPermission(InvocationContext invocationContext, Set<SecurityViolation> violations)
{
if(!this.userService.isActiveUser(this.currentUser))
{
violations.add(newSecurityViolation("{inactive_user_violation}"));
}
}
}
|
The message-key of the previous example will be passed to the MessageContext
with the Jsf
qualifier. You can also use a hardcoded inline message. If you would like to use a different MessageContext
you can just inject it (see the following example).
Code Block |
---|
| java |
---|
| java |
---|
title | Example for an AccessDecisionVoter with a custom MessageContext | java |
---|
|
@ApplicationScoped
public class OrderVoter extends AbstractAccessDecisionVoter
{
@Inject
private UserService userService;
@Inject
private User currentUser;
@Inject
@Custom
private MessageContext messageContext;
public void checkPermission(InvocationContext invocationContext, Set<SecurityViolation> violations)
{
if(!this.userService.isActiveUser(this.currentUser))
{
String reason = this.messageContext.message().text("{inactive_user_violation}").toText();
violations.add(newSecurityViolation(reason));
}
}
}
|
...
The following example shows how to create a default error page. It's just allowed to provide one default error page per application.
Instead of implementing ViewConfig
it's required to implement the DefaultErrorView
interface.
Code Block |
---|
| java |
---|
| java |
---|
title | Default error pagejava |
---|
|
@Page
public final class Login extends DefaultErrorView
{
}
|
...
CODI allows to specify the page-bean as optional meta-data via the view-config mechanism.
You can use this approach to load the page-bean before the rendering process starts. So the post-construct method (= methods annotated with @PostConstruct
) will be invoked if it is needed. Furthermore, it's possible to use @BeforePhase(...)
and @AfterPhase(...)
without observer syntax of CDI.
Code Block |
---|
| java |
---|
| java |
---|
title | View-config with Page-Bean | java |
---|
|
@Page
@PageBean(LoginPage.class)
public final class Login implements ViewConfig
{
}
|
Code Block |
---|
| java |
---|
| java |
---|
title | Page-Beanjava |
---|
|
//...
public final class LoginPage implements Serializable
{
@PostConstruct
protected void initBean()
{
//...
}
@AfterPhase(INVOKE_APPLICATION)
protected void postPageAction()
{
//...
}
@BeforePhase(RENDER_RESPONSE)
protected void preRenderView()
{
//...
}
}
|
... you can use @BeforePhase
and @AfterPhase
in the same way like the Phase-Listener Methods described above (just without the need of the PhaseEvent
).
Code Block |
---|
| java |
---|
| java |
---|
title | Page-Bean with view-controller annotations | java |
---|
|
//...
public final class LoginPage implements Serializable
{
@PostConstruct
protected void initBean()
{
//...
}
@InitView
protected void initView()
{
//...
}
@PrePageAction
protected void prePageAction()
{
//...
}
@PreRenderView
protected void preRenderView()
{
//...
}
}
|
...
Sometimes it's required to use multiple page controllers for a page (e.g. in case of two very different parts in the page which should be handled by different view-controllers). Such a use-case isn't very common, however, via @PageBean.List
it's possible to attach multiple pages-beans to a view-config.
Code Block |
---|
| java |
---|
| java |
---|
title | View-config with multiple Page-Beans | java |
---|
|
@Page
@PageBean.List({
@PageBean(Bean1.class),
@PageBean(Bean2.class)
})
public final class UseCase1 implements ViewConfig
{
}
|
...
the @PageBean
example above would look like:
Code Block |
---|
| java |
---|
| java |
---|
title | View controller example without @PageBeanjava |
---|
|
@Page
public final class UseCase1 implements ViewConfig
{
}
@Model
@View(UseCase1.class)
public class Bean1 implements ViewConfig
{
@PreRenderView
protected void preRenderView()
{
//...
}
}
@Model
@View(UseCase1.class)
public class Bean2 implements ViewConfig
{
@PreRenderView
protected void preRenderView()
{
//...
}
}
|
...
If you have a dedicated root-folder for all your pages (and sub-folders) you can reflect it in your package structure. The following example shows a class marked with @InlineViewConfigRoot
in the package *.pages. So the root folder has to have the name 'pages'. Every sub-package will be mapped to a sub-folder. In case of Inline-View-Configs the page-bean has to implement the ViewConfig
in-/directly and has to be annotated with @Page
. You can use the same features of the normal View-Config including type-safe navigation, lifecycle callback annotations,...
Code Block |
---|
| java |
---|
| java |
---|
title | Inline-View-Config example 1java |
---|
|
package my.pkg.pages;
@InlineViewConfigRoot
public final class RootMarker
{
}
package my.pkg.pages.registration;
//...
@Named
@RequestScoped
@Page
public class RegistrationStep1 implements ViewConfig
{
public Class<? extends ViewConfig> confirm()
{
//...
return RegistrationStep2Page.class;
}
}
//will be interpreted as /pages/registration/registrationStep1.xhtml
|
...
Furthermore, it's possible to specify a so called pageBeanPostfix
for allowing to use a name convention for your pages beans which won't be reflected by the xhtml file name.
Code Block |
---|
| java |
---|
| java |
---|
title | Inline-View-Config example 2 | java |
---|
|
package my.pkg.pages;
@InlineViewConfigRoot(basePath = "/*", pageBeanPostfix = "Controller")
public final class RootMarker
{
}
package my.pkg.pages.registration;
//...
@Named
@RequestScoped
@Page
public class RegistrationStep3Controller implements ViewConfig
{
//...
}
//will be interpreted as /registration/registrationStep3.xhtml
|
If you have a fine grained package structure which isn't reflected in the folder-structure of your pages (or a different name has to be used), it's possible to specify a basePath
. Without a *
at the end, all sub-packages are ignored.
Code Block |
---|
| java |
---|
| java |
---|
title | Inline-View-Config example 3 | java |
---|
|
package my.pkg.pages;
@InlineViewConfigRoot(basePath = "/pages/", pageBeanPostfix = "Page")
public final class RootMarker
{
}
package my.pkg.pages.registration;
//...
@Named
@RequestScoped
@Page
public class RegistrationStep2Page implements ViewConfig
{
//...
}
//will be interpreted as /pages/registrationStep2.xhtml
|
Compared to the previous example the next example shows a custom basePath
and all sub-packages will be mapped to sub-folders.
Code Block |
---|
| java |
---|
| java |
---|
title | Inline-View-Config example 4java |
---|
|
package my.pkg.pages;
@InlineViewConfigRoot(basePath = "/views/*")
public final class RootMarker
{
}
package my.pkg.pages.registration;
//...
@Named
@RequestScoped
@Page
public class RegistrationStep4 implements ViewConfig
{
//...
}
//will be interpreted as /views/registration/registrationStep4.xhtml
|