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

Bug 372257

Summary:	Revise branding-to-entrypoint binding
Product:	[RT] RAP	Reporter:	Ralf Sternberg <rsternberg>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	holger.staudacher
Version:	1.5
Target Milestone:	1.5 M6
Hardware:	PC
OS:	Linux
Whiteboard:

Description Ralf Sternberg

2012-02-22 12:40:21 EST

As of bug 365633, entry points are now registered by path. With this change, the following methods in the class AbstractBranding are not needed anymore and should be deprecated.

* getServletName()
* getDefaultEntryPoint()
* getEntryPoints()

But we also have to provide an alternative way of binding a branding configuration to an entry point. For the ApplicationConfig, a suggestion has been to add an (optional) third parameter "branding" to the addEntryPoint() methods like in this example:

  config.addEntryPoint( "/myapp", MyEntryPoint.class, myBranding );

An interesting observation is that some of the branding properties are likely to be shared among all entry points of an application (e.g. the theme), while others will always be specific to a single entry point (such as the title shown in the browser). This detail would require a separate branding for every entry point.

As explained in bug 372255, a more flexible way of providing branding values such as a map of key-value pairs may be needed anyway. Maybe the shared values could even be stored directly in the application store and entry points could override certain values?

Finally, we'll also have to think about a change to the branding extension point.

Comment 1 Ralf Sternberg

2012-03-11 11:54:06 EDT

I'd like to go the suggested path of accepting a third parameter in the addEntryPoint() methods.  Instead of calling it "branding" I'd prefer something more generic like "properties" or "parameters", because not all of the possible parameters are related to a brand.

Since the framework should be flexible enough to support alternative clients, I think of a java.util.Map<String, Object> as parameter type. Example:

  Map map = new HashMap<String, Object>();
  map.put( DefaultClient.THEME_ID, "my.custom.theme" );
  map.put( AndroidClient.USE_COOL_EFFECTS, Boolean.TRUE );
  ...

  config.addEntryPoint( "/myapp", MyEntryPoint.class, map );

We could also specify a map-like type of our own, but I'm not sure if this would add any value.
Thoughts?

Comment 2 Ralf Sternberg

2012-03-16 07:29:38 EDT

The ApplicationConfiguration#addEntryPoint() methods now accept a third parameter called properties to configure those "branding" aspects for every entrypoint. The properties are a String-to-String Map. Property keys are defined in the new class WebClient. Alternative clients can define their own properties.

ApplicationConfiguration#addBranding() has been removed.

IExitConfirmation is not part of the WebClient's properties, I've opened bug 374478 for an API to add exit confirmations programmatically.

Comment 3 Ralf Sternberg

2012-03-16 08:19:03 EDT

I've decided to also remove the two-parameter addEntryPoint methods. I think it feels simpler to add a null as last parameter than having to select from four different addEntryPoint() methods. Moreover, there will hardly be any productive application that doesn't at least set the browser title.