You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by Apache Wiki <wi...@apache.org> on 2008/02/12 11:05:58 UTC

[Myfaces Wiki] Update of "ReleasePlanForCore1.1" by SimonKitching

Dear Wiki user,

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

The following page has been changed by SimonKitching:
http://wiki.apache.org/myfaces/ReleasePlanForCore1%2e1

New page:
Here is a list of things that it would be nice to get done before the next (1.1) release of Orchestra Core.

= examples =

== Add new very simple example without persistence ==
Done

== Fix broken examples ==
Quite a few examples just don't run. 

== Improve Example Documentation ==

Examples are for beginners to learn from. But the current examples have no information
on what they are trying to demonstrate. Each example really needs to tell the user:
 * what orchestra features are used
 * what those orchestra features achieve
 * how they can tell from the example app that those features are working

= Modify "access" scope duration =

Currently, access scope (formerly called flash scope) lasts until a complete postback/render
cycle occurs without that bean being accessed.

But that means that in a master/detail setup, a postback to the detail page that forwards to the master
followed by a postback to the master that navigates to the detail keeps the detail bean alive. Ecch.

Instead, access scope should expire if a *render* cycle has no access to it. This then means that a
postback to the detail which forwards to the master will expire the detail backing bean because the
master page does not refer to it. It also means that the bean is cleaned up earlier which is nice.

Note that when <redirect/> is used in a nav rule then this point is moot as a forward never occurs.

This issue was first reported by Matthias in his "facesgoodies" project.

= Review reverts to Spring ScopeManager stuff =

A while ago I (simon) made some cleanups in the scope-manager code, particularly to do with scoped-proxy
beans where code "drills down" from the proxy to the real bean. This broke some code in the core15 module
to do with the ViewControllerScope, so Mario reverted it. However I think the cleanup was worthwhile, and
want to look at whether the original changes can be put back, and the issue fixed in the ViewControllerScope
instead.

= Drilling down from proxy to real bean =

An orchestra user wanted to retrieve the "real" bean that an orchestra-generated proxy is proxying, in
order to serialize it and pass it to an external system (the proxy is not serializable). He eventually
found a partial solution, but it would be nice to look into whether a proper solution is possible.

= View Scope =

It was suggested on the mail-list that a "view" scope might be useful, ie a bean that lasts as long as
the viewid does not change. This is rather like the existing "access" scope, but a bit more limited. It
sounds quite useful and could possibly be more efficient than "access" scope.

Optional; could go into a later release.

= Portals =

A user has been trying to use Orchestra in a Portal application with no success. Getting Orchestra working
for portals would be nice.

= Clustering and Serialization =

Currently there are a number of Orchestra classes that just disable serialization completely. These need
to be reviewed to see whether we can properly support this, so that clustering and hot-restart work as well
as environments where user sessions can get passivated under load.