Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 342419 - Remove accessor classes for application scoped classes
Summary: Remove accessor classes for application scoped classes
Status: RESOLVED FIXED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 1.4 M7   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 341763
  Show dependency tree
 
Reported: 2011-04-11 06:16 EDT by Rüdiger Herrmann CLA
Modified: 2011-04-13 04:22 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rüdiger Herrmann CLA 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 CLA 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 CLA 2011-04-11 13:14:18 EDT
Part 2: ServiceManager, StartupPage, StartupPageConfigurer
Changes are in CVS HEAD
Comment 3 Rüdiger Herrmann CLA 2011-04-11 17:12:07 EDT
Part 3: SettingStoreManager, ConfigurationReader, ApplicationStore, PhaseListenerRegistry
Changes are in CVS HEAD
Comment 4 Rüdiger Herrmann CLA 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 CLA 2011-04-12 05:30:17 EDT
Part 5: TextSizeStorageRegistry
Changes are in CVS HEAD
Comment 6 Rüdiger Herrmann CLA 2011-04-12 07:12:25 EDT
Part 6: ImageFactory, FontDataFactory, ImageDataFactory, InternalImageFactory
Changes are in CVS HEAD
Comment 7 Rüdiger Herrmann CLA 2011-04-12 10:38:41 EDT
Part 7: DisplaysHolder, JSLibraryConcatenator, JSLibraryConcatenator, AdapterFactoryRegistry
Changes are in CVS HEAD
Comment 8 Rüdiger Herrmann CLA 2011-04-12 11:47:34 EDT
Part 8 (almost done): ResourceRegistry, ResourceFactory
Comment 9 Rüdiger Herrmann CLA 2011-04-12 13:57:15 EDT
Part 9: ResourceManager (renamed to ResourceManagerProvider)
Comment 10 Rüdiger Herrmann CLA 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