Community
Participate
Working Groups
The similarity of the interface names ApplicationConfiguration and ApplicationConfigurator turned out to be very confusing, especially since both interfaces are public, both reside in the same package, and both are directly related. When registering an ApplicationConfigurator implementation, the service interface can be easily mixed up. Moreover, these interfaces follow a very similar pattern than the workbench advisors, but we use the term "configurator" for the opposite purpose of the workbench's "configurers", which adds to the confusion: * In the workbench, an "advisor" has to be implemented by configuring the target using a "configurer". * In RAP, an "configurator" has to be implemented by configuring the target using a "configuration". We should think about possible improvements again before the freeze.
We've agreed on renamings: 1. Rename the existing class "Application" to "ApplicationProcess". This class represents a *running instance* of an application. The term "process" seems to be a suitable metaphor for an application at runtime. 2. Rename the existing interface "ApplicationConfigurator" to "Application". This is the central interface that has to be implemented in order to register an application with the framework. Calling it "Application" reflects this pivotal role. It also relates to the platform's "IApplication" interface which is a callback interface with similar purpose and structure.
I've tried to rename "Application" to "ApplicationProcess" as suggested but looking through the changes I was not happy with the result. The instances of this class really represent "application instances" and are referred to as such. Thinking about them as processes appears unnatural somehow. A process is a lower-level concept, it hosts an application instance but it isn't the instance itself. While trying some alternatives like "ApplicationRunner", I became convinced that the only correct name is "ApplicationInstance". That's what it really is. I tried to avoid the name "instance" as it interferes with the OO concept, but after some research, it seems that it's common to call instances of an application "application instances". There is no other word for it. So if we need to represent an application instance, we should call it ApplicationInstance. I'm going to make this change now as there is not much time left. In case of a veto, we can still change it until M7.
(In reply to comment #2) I agree, ApplicationInstance is not the best name. Perhaps: ApplicationMediator
(In reply to comment #3) This class does in fact implement the mediator design pattern and in my opinion is really a good fit here.
(In reply to comment #4) > This class does in fact implement the mediator design pattern Sorry, I don't see the mediator pattern relates to application instances. A mediator is used to synchronize two objects that do not directly know each other. An application instance is a *running* application. Like, for example, a text editor is an application you download and install. When you open it, an *application instance* is created that displays a document. Then you open another instance of the same application. There is a difference between the application and the application instance.
Was there a reason for not prefixing the interface ApplicationConfigurator with an "I" such as IEntryPoint? I don't like these prefixes, but since we've started to prefix our interfaces with an "I", should we make an exception here? On the other hand, if we rename ApplicationConfigurator to IApplication, we have the clash with the Equinox IApplication. Who said naming was the _second_ hardest problem in this business? ;-)
(In reply to comment #5) > Sorry, I don't see the mediator pattern relates to application instances. A > mediator is used to synchronize two objects that do not directly know each > other. > An application instance is a *running* application. Like, for example, a > text editor is an application you download and install. When you open it, an > *application instance* is created that displays a document. Then you open > another instance of the same application. There is a difference between the > application and the application instance. My scope for the definition of 'application' is a little wider. I see the the ApplicationInstance class as a point of access to a larger more complex concept that is the 'application', which has lots of moving parts. An instance to me is a 1-to-1 correspondence between an archetype and a running artifact. I see the mediator pattern here because the ApplicationInstance class is not an instance of the application as a whole. It is an object that acts as a mediator or representative of a particular running application.
Sorry, please use this comment instead of my previous: My scope for the definition of 'application instance' is a little wider. I see the the ApplicationInstance class as a point of access to a larger more complex concept that is the 'application instance', which has lots of moving parts. An instance to me is a 1-to-1 correspondence between an archetype and a running artifact. I see the mediator pattern here because the ApplicationInstance class is not an 'instance' of the application as a whole. It is an object that acts as a mediator or representative of a particular running application (instance).
Just a note: Update the FAQ entry (How do I develop an RWT standalone application with RAP >= 1.5) if needed after the bug is fixed.
After struggling with this issue again and again, trying different approaches, and having many discussions on it, I came to these conclusions: * A bundle can not register an Application as a service because providing a service for an interface called Application would mean to create an instance of an application (services are objects). This feels wrong because the application instance is created by the framework. * What the bundle really provides is the configuration for an Application, i.e. a blueprint that contains all the parts of an application such as entrypoints, URL mappings, themes, service handlers etc. This class (which has been named ApplicationConfigurator before) is now called ApplicationConfiguration. This name seems to describe its purpose best. * An ApplicationConfiguration is used to configure an application before it is started. Since we have a callback approach, the configuration must actively configure the application. To do so, it has one method configure( Application ). The framework provides a reference to the created application (i.e. an object that represents the application) as a parameter to this method. This is the only place where the developer can access the application directly. Example: public class SimpleConfiguration implements ApplicationConfiguration { public void configure( Application application ) { application.addEntryPoint( "/simple", SimpleEntryPoint.class, null ); } } * An application can not be started directly, but by using an ApplicationRunner: ApplicationRunner runner = new ApplicationRunner( configuration, servletContext ); runner.start();
(In reply to comment #9) > Just a note: Update the FAQ entry (How do I develop an RWT standalone > application with RAP >= 1.5) if needed after the bug is fixed. FAQ has also been updated. Thanks for the reminder.
