[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-496) need for PartialLookupViewDescriptor ?

[Lieven D. (JIRA) <no...@sp...>]

     [ http://jira.springframework.org/browse/RCP-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo updated RCP-496:
-----------------------------

    Fix Version/s: 1.x

> need for PartialLookupViewDescriptor ?
> --------------------------------------
>
>                 Key: RCP-496
>                 URL: http://jira.springframework.org/browse/RCP-496
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Application Framework
>    Affects Versions: 1.0.0
>         Environment: WinXp, JDK1.5_11
>            Reporter: Quinten Verheyen
>            Priority: Minor
>             Fix For: 1.x
>
>
> I was asked to create a JRIA issue for this on the Spring forum.
> I noticed the current view descriptors do not always suffice.
> Currently you either have a choice between a) a new view instance with the same collaborator instances or b) a new view instance with all of it's collaborars being reinstantiated to.
> The first option is by using DefaultViewDescriptor, passing through a "viewClass" and a "viewProperties".
> However, I discovered this default approach can be problematic since multiple ApplicationWindow's reference different view instances (of the same view) that refer to the same collaborator instances underneath. This is ok when all of the collaborators are singleton services, but when you have a (statefull) prototype collaborator you can experience strange behaviour. I actually wanted two different instances for that specific collaborator (1 for each window), but that meant I should not provide it in "viewProperties" of a view descriptor. Also, marking any beans used underneath as prototype beans doesn't work since the view descriptor is a singleton, so your beans are only instantiated once, prototype or not.
> The alternative option was to use LookupViewDescriptor, passing through a prototype bean, but that's not possible if you want some things to be statefull of course.
> So the only thing I could think of was to write a custom ViewDescriptor that accepts a "reloadableViewProperties" and changes the mentioned properties in the already instantiated BeanWrapper underneath (that loaded the viewProperties first). The advantage is of course that the bean type (prototype or singleton) will be taken into account this time (since it is bean factory aware).
>         protected View createView() {
>         // ...
>         BeanWrapper wrapper = new BeanWrapperImpl(view);
>         if (viewProperties != null) {
>             wrapper.setPropertyValues(viewProperties);
>         }
>         
>         if (reloadableViewProperties != null) {
>         	MutablePropertyValues pvs = new MutablePropertyValues(reloadableViewProperties);
>         	List propertyValues = pvs.getPropertyValueList();
>         	for (Iterator it = propertyValues.iterator(); it.hasNext();) {
>         		PropertyValue pv = (PropertyValue) it.next();
>         		Object bean = getBeanFactory().getBean(pv.getName());
>         		wrapper.setPropertyValue(pv.getName(), bean);
>         	}
>         }
> (btw, sadly I had to duplicate the code from DefaultViewDescriptor it isn't designed with extensibility in mind ?)
> So the approach solved my problem, but I cannot imagine I'm the first one encountering this "multiple window" impact on view descriptors. So I'm wondering if there are better solutions ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira