Community
Participate
Working Groups
currently the NewRepositoryWizard handles the holding and application of a specific branding to a repository. This works fine however if any other wizard uses a repository settings page to create a repository the branding will not be properly applied. Additionally since the page doesn't know about the branding it must be retrieved from the wizard after construction to ensure that the correct branding images and labels are displayed in the page. The AbstractRepositorySettings page should be enhanced to optionally take a branding on construction this way the branding can be immediately injected and will always be applied to the repository correctly in any context.
This creates additional SPI for connector implementors to implement just to pass the brand to the page. I think in most cases the brand is only going to be used to set the page title and wizban image, which it seems ought to be done by the framework. Would it make more sense (and be possible) to add a method to RepositoryConnectorBranding for getting the wizban image and have the framework take care of passing the brand to the page and setting the title and wizban based on the brand? What do you think Jaxsun?
I can see this all being done nicely when a repository with a branding ID exists however how would the framework take care of situations where applications implement additional wizards which wish to use the repository settings page to create new
(...continuation of prematurely submitted comment...) .. how would the framework take care of situations where applications implement additional wizards which wish to to use the repository settings page to create new task repositories. Right now this is done using the connector UI, so either more information needs to be able to be passed into there, which expands the SPI as was done in the submitted review, or there would need to be a centralization of the handling of these settings pages so they can be created and configured automatically without expanding the SPI. If such a centralization were to take place then existing applications would need to switch to using this over the connector ui. Would this lead to the deprecation of ConnectorUi.getSettingsPage() ?
I was imagining that there would be a setBrand method on the page, which clients would need to call after getting the page from the connector UI. Do you think that's workable? It has the disadvantage of clients needing to call this method at the right time, but I think it's better to complicate the API than the SPI, because there are a lot more SPI implementors and they shouldn't need as much knowledge of the framework as API clients.
That sounds reasonable. I will create a new review which does this and updates the existing wizards.
New Gerrit change created: https://git.eclipse.org/r/53370
Gerrit change https://git.eclipse.org/r/53370 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=f0671df11387e9369ad681999f538c848d9f9dbb
Thanks Jaxsun.