Overview
Other MyFaces Extensions
- ExtVal
- Ext-Script
- [Orchestra]
- [Portlet Bridge]
Community
Development
Sponsorship
Your browser does not support iframes
...
CODI provides default values via CDI beans. Therefore, it's possible to provide an alternative bean (via the std. @Specializes
or @Alternative
mechanism and the corresponding config specified provided by CDI). An alternative implementation is allowed to extend the default implementation - so it's possible just to override the values you have to customize. Or you just implement the corresponding interfaces and so you have to provide all values. Furthermore, there are add-ons e.g. for using the web.xml for the configuration (see External Resources).
Tipnote | ||
---|---|---|
| ||
Detailed information is available as JavaDoc at the corresponding interfaces. | ||
| ||
In case of those versions of Weld you have to use the alternative-implementation module |
Note | ||
---|---|---|
| ||
In case of Weld v1.1.4+ you can use @Specializes again and you don't need alternative-implementation module |
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
@Specializes
@ApplicationScoped
public class CustomConversationConfig extends ConversationConfig
{
@Override
public int getConversationTimeoutInMinutes()
{
return 45;
}
}
|
...
A ConversationFactory
is responsible for creating new Conversation
instances (btw. EditableConversation
) based on a given ConversationKey
and ConversationConfig
.
The default implementation is a bean - so it's possible to use the @Alternative
mechanism of CDI for replacing it.
A WindowContextFactory
is responsible for creating new WindowContext
instances (btw. EditableWindowContext
) based on a given id and JsfModuleConfig
.
There is no default implementation. So it's just required to implement a CDI bean which implements the interface.
A WindowContextManagerFactory
is responsible for creating new WindowContextManager
instances (btw. EditableWindowContextManager
based on a given JsfModuleConfig
.
There is no default implementation. So it's just required to implement a CDI bean which implements the interface.
A WindowContextQuotaHandler
is responsible for checking the max. count of WindowContext
instances and handling a possible violation (e.g. cleaning up the eldest WindowContext
).
The default implementation is a bean - so it's possible to use the @Alternative
mechanism of CDI for replacing it.
A WindowHandler
is responsible for creating and restoring the id for/of the current window. If a component library already supports window id's it's possible to provide an adapter which uses the window-id provided by the component library. Furthermore, it's responsible for encoding URLs and for sending redirects based on the current window-id.
The default implementation is a bean - so it's possible to use the @Alternative
mechanism of CDI for replacing it.
A WindowHandler
that is aware of the JSF lifecycle.
Component libs like Trinidad use very special renderkits. This factory allows support-modules to customize the default behavior of CODI.
A ViewConfigExtractor
creates all view-config meta-data for a given ViewConfig
class and returns the result as EditableViewConfigDescriptor
. It also uses LifecycleAwarePageBeanDescriptor
which is an extended PageBeanDescriptor
. This descriptor exposes all supported view-controller methods as well as RequestLifecycleCallbackEntry
for a given JSF PhaseId which provides the before- and after-callbacks.
With a custom implementation it's possible to customize e.g. the naming convention of the pages. If the custom implementation is annotated with @Advanced
it's possible to wrap the default implementation for delegating to it. The only requirement is a field called defaultViewConfigExtractor
. Furthermore, because this artifact is used during the bootstrapping process of CDI it's required to configure it for the environment - see Environment-Config Options