Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342419

Summary:	Remove accessor classes for application scoped classes
Product:	[RT] RAP	Reporter:	Rüdiger Herrmann <ruediger.herrmann>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3
Version:	unspecified
Target Milestone:	1.4 M7
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	341763

Description Rüdiger Herrmann

2011-04-11 06:16:51 EDT

With the introduction of the RWTContext, for each 'static' class that lies in application scope, an accessor class was introduced. E.g. the LifeCycleFactory was renamed to LifeCycleFactoryInstance and LifeCycleFactory serves now as an accessor class where each method just obtains an instance of LifeCycleFactoryInstance and delegates the actual work.

The purpose of this work is to reduce the number of classes by 'inlining' the accessor methods and then removing the accessor classes. After that the ...Instance classes can be renamed back to their original names. E.g. LifeCycleFactoryInstance would become LifeCycleFactory.

Comment 1 Rüdiger Herrmann

2011-04-11 11:13:45 EDT

I decided to do this work in chunks. Part 1 includes BrandingManager, EntryPointManager and LifeCycleFactory

Comment 2 Rüdiger Herrmann

2011-04-11 13:14:18 EDT

Part 2: ServiceManager, StartupPage, StartupPageConfigurer
Changes are in CVS HEAD

Comment 3 Rüdiger Herrmann

2011-04-11 17:12:07 EDT

Part 3: SettingStoreManager, ConfigurationReader, ApplicationStore, PhaseListenerRegistry
Changes are in CVS HEAD

Comment 4 Rüdiger Herrmann

2011-04-12 04:23:26 EDT

Part 4: ThemeAdapterUtil (now named ThemeAdapterManager), ThemeManagerInstance
ThemeManagerInstance was renamed to ThemeManagerHolder. Also I left the ThemeManager#getInstance() and resetInstance() for now. The way to the actual ThemeManager is via another indirection (ThemeManagerHolder) and RWTFactory.getThemeManager().getInstance().doSomething(...) is too verbose and there are too many places where the ThemeManager is called.

Comment 5 Rüdiger Herrmann

2011-04-12 05:30:17 EDT

Part 5: TextSizeStorageRegistry
Changes are in CVS HEAD

Comment 6 Rüdiger Herrmann

2011-04-12 07:12:25 EDT

Part 6: ImageFactory, FontDataFactory, ImageDataFactory, InternalImageFactory
Changes are in CVS HEAD

Comment 7 Rüdiger Herrmann

2011-04-12 10:38:41 EDT

Part 7: DisplaysHolder, JSLibraryConcatenator, JSLibraryConcatenator, AdapterFactoryRegistry
Changes are in CVS HEAD

Comment 8 Rüdiger Herrmann

2011-04-12 11:47:34 EDT

Part 8 (almost done): ResourceRegistry, ResourceFactory

Comment 9 Rüdiger Herrmann

2011-04-12 13:57:15 EDT

Part 9: ResourceManager (renamed to ResourceManagerProvider)

Comment 10 Rüdiger Herrmann

2011-04-13 04:12:43 EDT

The rest: ResourceManagerImpl
The ResourceManagerImpl was removed from the ApplicationContext to avoid calling ResourceManagerImpl#getInstance() multiple times as it led to the ResourceManagerImpl instance being re-configured with each call.
ResourceManagerImpl#getInstance() was renamed to createInstance() and creates and configures a new instance of ResourceManagerImpl. All clients of the resource manager now call the ResourceManagerProvider to obtain an instance. The ResourceManagerProvider together with the DefaultResourceManagerFactory now handles creating and accessing the single ResourceManagerImpl instance per ApplicationContext.
Changes are in CVS HEAD