myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "Extensions/CDI/DevDoc/Conversations" by GerhardPetracek
Date Mon, 12 Jul 2010 11:47:32 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The "Extensions/CDI/DevDoc/Conversations" page has been changed by GerhardPetracek.
http://wiki.apache.org/myfaces/Extensions/CDI/DevDoc/Conversations

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

New page:
= Conversations (Draft) =

== Basic Idea ==

Std. CDI conversations are very limited. So CODI will provide conversations which are similar
to the conversations of Orchestra.<<BR>>
Basically each window has its own context (see WindowContext - it's similar to the ConversationContext
of Orchestra).<<BR>>
Within this context it's possible to define multiple conversations (grouped by a typesafe
conversation-group instead of a string based name).

TODO: should we keep the group concept or should we use special qualifiers (e.g. marked via
a special annotation).

The following part explains the available annotations.
(All scopes are stored in the session - so the max. lifetime is restricted by the session
of the user.)

=== @ConversationScoped ===

Beans which are marked with this annotations will be scoped as a grouped conversation.
That means the bean exists as one of n (parallel) conversations in the WindowContext. The
group is identified via the class of the bean and the qualifiers of the bean.

Example 1:
{{{
@ConversationScoped
public class ConversationDemoBean1 implements Serializable
{
}
}}}

If the bean isn't used any more it will be un-scoped automatically after a configurable timeout
(default: 30 min).

Furthermore it's possible to create conversation groups. That means 1-n beans will exist in
the same conversation.
As soon as the conversation gets destroyed all beans will be un-scoped.

Example 2
{{{
@ConversationScoped(Group1.class)
public class ConversationDemoBean1 implements Serializable
{
}

@ConversationScoped(Group1.class)
public class ConversationDemoBean2 implements Serializable
{
}
}}}

Both beans of example 2 will be scoped in a conversation with the group-key: Group1.class

Due to a missing CDI API this mechanism is only available for class-level bean definitions.
That means mechanisms like producer methods aren't supported.
In such cases we have to use qualifiers instead of groups.

The most important use-case for groups are e.g. wizards, master/detail views,... (e.g. it's
possible to use one page-bean for each wizard step. All page-beans used for the wizard are
scoped in the same conversation group. At the end of the wizard we can destroy the conversation
group of the wizard and every bean gets un-scoped. Furthermore, conversation groups allow
an easier API for the WindowContext.

=== @WindowScoped ===

The window scope is just a special conversation without timeout. All beans exist as long as
the WindowContext is active (or the session of the user).

We will see an API for destroying the WindowContext as a whole or just all window scoped beans.
However, usually you don't need to use it.

We can use the window scope e.g. for the current user. So it's possible to support e.g. multiple
tabs with different logins.

Example:
{{{
@WindowScoped
public class WindowDemoBean implements Serializable
{
}
}}}

To reduce the amount of different annotations you can also use: @ConversationScoped(WindowGroup.class)

=== @ViewAccessScoped ===

This scope is similar to the access scope of Orchestra. That means: a bean will be available
in the next request if it is used in the current request.

We have to support AJAX so the name as well as the rule is a bit different:
All beans which are used in a view will be available in the current view (e.g. multiple AJAX
requests) as well as in the next view. (Redirects are supported as well.)

Example Use-Case:

{{{
views:           [ View 1 ]   [ View 1 ]   [ View 2     ]   [ View 3     ]

used beans:      [ Bean 1 ]   [ Bean 1 ]   [ Bean 2     ]   [ Bean 3     ]

available beans: [ Bean 1 ]   [ Bean 1 ]   [ Bean 1 & 2 ]   [ Bean 2 & 3 ]
}}}

Example:
{{{
@ViewAccessScoped
public class ViewAccessDemoBean implements Serializable
{
}
}}}

To reduce the amount of different annotations you can also use: @ConversationScoped(ViewAccessGroup.class)

== 1 Bean and N Scopes ==

Via producer methods it's possible to create multiple beans with different scopes.
Due to a missing API in CDI we can't support conversation groups in this scenario. So we have
to use qualifiers instead.

Example:
{{{
public class MixedConversationDemoBean implements Serializable
{
    private String value;

    protected MixedConversationDemoBean()
    {
    }

    private MixedConversationDemoBean(String value)
    {
        this.value = value;
    }

    @Produces
    @Qualifier1
    @WindowScoped
    public MixedConversationDemoBean createWindowScopedBean()
    {
        return new MixedConversationDemoBean("Q1@WindowScoped ");
    }

    @Produces
    @Qualifier2
    @ViewAccessScoped
    public MixedConversationDemoBean createViewAccessScopedBean()
    {
        return new MixedConversationDemoBean("Q2@ViewAccessScoped ");
    }

    public String getValue()
    {
        return value;
    }
}
}}}

== Events ==

== APIs ==

=== Core-Module ===

=== JSF-Module ===

== SPIs ==

=== Core-Module ===

=== JSF-Module ===

Mime
View raw message