Community
Participate
Working Groups
User-Agent: Opera/9.80 (Windows NT 6.0; U; pl) Presto/2.2.15 Version/10.10 Build Identifier: Long story is described on forum: http://www.eclipse.org/forums/index.php?t=msg&th=158606&start=0&S=6fcd13192a08a6cdee56b93c3fe7b9c4 To summarize: Templates View uses AbstractTemplatesPage which defines two methods: getTemplateStore() and getSelectedTemplates(). They are protected and private respectively which make this view hard to extend. It would be nice to have access from third party plugins to template store which drives particular templates page and to currently selected items in the view. Proposed solution is to add new public method which would act as an alias to protected method getTemplateStore() and to change visibility of getSelectedTemplates to public. This should not break existing code in any way. Reproducible: Always
Created attachment 153322 [details] proposed patch to make templates view more extensible
I assume you don't provide your own page. How do you access the page in your action(s)?
Correct, I use code like this to access page in my handler: TemplatesView templatesView = (TemplatesView) HandlerUtil.getActivePart(event); IPage currentPage = templatesView.getCurrentPage(); Then a check is made if page is subclass of AbstractTemplatesPage.
In that case we could surface the methods on the view itself. That way we could also avoid to have the same functionality but with different method names (getTemplateStoreForPage() and getTemplateStore()). Could you prepare a new patch and also add your credentials to the copyright notice of each file in the following form: name <e-mail> - bugzilla summary - bugzilla URL e.g. Dani Megert <dani@eclipse.org> - this is a bug - https://bugs.eclipse.org...
Created attachment 153329 [details] another approach - added access directly from TemplatesView
(In reply to comment #5) > Created an attachment (id=153329) [details] > another approach - added access directly from TemplatesView here it goes. The drawback of this approach is that we make TemplatesView aware of Template Store concept from now on. Not sure if this is intended.
Thanks for the patch Piotr. Here some comments to it: - the current patch only works for AbstractTemplatesPage but a correct fix should also support clients implementing ITemplatesPage. To do that we need to add ITemplatesPageExtension that has the two new methods. The view would then work against ITemplatePageExtension. Take a look at e.g. ITextEditorExtension on how we write the Javadoc for it. - I would return 'null' from getSelectedTemplates() to differ the state of having no page vs. having nothing selected - * @return template store of <code>null</code> ==> or <code>null</code>, if none - remove superfluous code from getTemplateStore(): if (currentPage == null) { return null; } - inline superfluous local variable atp in getTemplateStore() - end first Javadoc sentence with '.'
Created attachment 153506 [details] proposed solution using ITemplatesPageExtension I've created another patch which adds ITemplatesPageExtension. There is one problem with it: method getTemplateStore() is declared as protected in AbstractTemplatePage, so I could not use this method in interface because widening visibility could break existing implementations of this abstract class. I've changed name to getTemplateStoreForPage().
>could break existing implementations of this abstract >class. I've changed name to getTemplateStoreForPage(). Only source breakage, which I prefer over adding a second name for the same thing. I have added an entry to the porting guide. Committed to HEAD with some modifications (please have a look in HEAD). Available in builds > N20091202-2000.
> Only source breakage Discussion about this is in bug 297024.
