--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
For plugins with more advanced UI interactions, is there, or will there be, a designated plugin-area in the UI (as is the case with GWT UI) or is the implementer of the plugin left to hook in to the UI where he/she see fit?
Hi Sven,Thanks for taking time looking into this! Really appreciate provided feedback.First things first, the best documentation that exists for PolyGerrit plugins is located here. It's far from being complete, unfortunately - work is in progress.
I see your point of convenience using UiAction for a trivial task of adding a button to the change menu. But clearly, this isn't and probably shouldn't be the only way for modifying UI,
since there are number of downsides. For example this requires formalizing in the REST API all the UI aspects. Specifically, in the GWT UI all change actions were rendered in same way (lots of buttons), while in PolyGerrit there are primary and secondary, not to mention the `More` menu.
Surely, this could be added as properties to the change actions, but this clearly would complicate things for PolyGerrit maintainers if making a UI change would trigger cascading changes to REST API (and that would require updating documentation, acceptance tests, let alone plugin considerations).
That's why one of the goals for PolyGerrit plugin API is to promote writing and using JS-based plugin API instead of Java-based one.Practically speaking, UiActions hopefully can be easily migrated to plugin.changeActions() API. This would mean that UI manipulations would need to be moved into .js/.html files.Let me know if that's anything that makes sense or if there's any scenario where this can cause problems, and I'll be happy to address all your concerns.For plugins with more advanced UI interactions, is there, or will there be, a designated plugin-area in the UI (as is the case with GWT UI) or is the implementer of the plugin left to hook in to the UI where he/she see fit?(this is a short recap of PG plugin dev guide)Ideally, all UI modifications would be expressed as a high-level API, such as plugin.changeActions() mentioned above. This would make it easier to for plugin authors to use. Also this would simplify maintenance and migrations for future versions of PolyGerrit.However, often times it's tricky to design one API that fits all, and for such cases low-level DOM API can be used. PolyGerrit plugin API provides DOM insertion/decoration points, accessible via `plugin.hook('hook-name-here')` API.This concept is similar to self.panel() but is intended to be as close to DOM as possible, in order to be as general as possible.
Here's an example how high-level plugin API method `addReplyTextChangedCallback()` uses low-level API to capture reply dialog text change:Adding such extension points are also trivial (example change), so the proposed procedure for adding new plugin APIs hopefully could look like this:
- tracking bug is filed describing the requirements
- extension point is added with params
- plugin author experiments using plugin.hook() method and stabilizes requirements for high-level API
- high-level API is implemented, covered with tests, documented, etc
- and plugin author replaces plugin.hook() with the high level API
I see your point of convenience using UiAction for a trivial task of adding a button to the change menu. But clearly, this isn't and probably shouldn't be the only way for modifying UI,Agreed, it shouldn't be the only way, but to be fair that was not what i suggested. Furthermore I concede that the "special case" aspect of UiActions doesn't speak to it's advantage. That being said, the special case of button/REST API point should be the most common one (that's why the UiAction was extracted as a special case in the GWT UI). My most personal reason for advocating a way to make it easy to implement an action (a button in the UI connected to a REST API point) is exactly that, it's the most common use case and it would be sweet if you could implement it without having to write some hundred lines of front-end boilerplate code.
<dom-module id="my-plugin">
<script>
Gerrit.install(plugin => {
plugin.on('showchange', () => {
const changeActions = plugin.changeActions();
const key = changeActions.add('change', 'kaboom');
changeActions.addTapListener(key, () => {
plugin.restApi().get('/config/server/version').then(console.log);
});
});
});
</script>
</dom-module>
const opts = {overflow: false, primary: true};
plugin.changeActions().addUIAction('kaboom', () => {
plugin.restApi().get('/config/server/version').then(console.log);
}, opts);Surely, this could be added as properties to the change actions, but this clearly would complicate things for PolyGerrit maintainers if making a UI change would trigger cascading changes to REST API (and that would require updating documentation, acceptance tests, let alone plugin considerations).I can't say much about the life of a PolyGerrit maintainer since I'm not one myself (though I'm willing to contribute to the best of my abilities) but from my point of view it needn't complicate things if all the REST API says is "Here's a primary action named "Press me", when pressed call this REST endpoint otherwise do with it what you please", which, from my rummaging through the part of the PolyGerrit code that handles such things, is more or less what happens today.
The main difference is that the "primary", "secondary", "more menu" state is hard coded in the UI which IMO is strange, the importance (or prioritization if you will) should be something that is determined in the backend and all the frontend should care about is how it want's to handle that prioritization "The primary actions goes here and they should be displayed as such, and the secondary actions goes here and they should be displayed as such". I could go as far as to let the frontend be aware of different, separate, actions so that it can prioritize within e.g. the "primary" group "Is there an action named "submit"? In that case it should be the leftmost "primary" action" and when all named actions are sorted just fill in the rest to the right of those. There needn't be much concern regarding what the end result would be (if there are 20 actions in the list implemented by various plugins), it is the responsibility of the individual Gerrit admins to assess how they want to handle the eventual UI mess that would be the result of adding "too many" "primary" actions through plugins.
So if there is a UI change, in most cases it wouldn't have to care about the backend, unless there's a need to add e.g. a "tertiary" action but, as I have stated my opinion earlier, that state should be reflected in the backend and the UI should just handle that third state (or fourth if you count the "more" menu), not define it.
I believe that a couple of areas where PG plugins can add elements and a couple of high level API points that covers the most common
use-cases such as plugin.changeActions(), plugin.revisionActions(), goes a long way.
If you want to do accomplish something above and beyond you should be prepared to either use the DOM API or implement and argue for a plugin API point that supports that use case.
- tracking bug is filed describing the requirements
- extension point is added with params
- plugin author experiments using plugin.hook() method and stabilizes requirements for high-level API
- high-level API is implemented, covered with tests, documented, etc
- and plugin author replaces plugin.hook() with the high level API
I would like to add "add an example plugin using the API in plugins/example".
I think hundred lines of front-end code is an overestimation. Maybe a better documentation would make this a non-issue?
Here's a complete minimal sample for adding a change action in the client code:<dom-module id="my-plugin">
<script>
Gerrit.install(plugin => {
plugin.on('showchange', () => {
const changeActions = plugin.changeActions();
const key = changeActions.add('change', 'kaboom');
changeActions.addTapListener(key, () => {
plugin.restApi().get('/config/server/version').then(console.log);
});
});
});
</script>
</dom-module>
changeActions() the oldest API existing in PolyGerrit, and clearly it can be improved. And it wasn't documented since most of its users are front-end developers who essentially implemented it or reviewed the implementation.Since adding a UI action is a fairly common thing, this clearly could be wrapped into a high-level API so the final script code would simply be the following:const opts = {overflow: false, primary: true};
plugin.changeActions().addUIAction('kaboom', () => {
plugin.restApi().get('/config/server/version').then(console.log);
}, opts);This isn't hard to do, so it essentially boils down to the philosophy of the API.
On the other hand, it doesn't seem that adding overflow and primary properties to extensions.webui.UiAction is complex, too.If that's the only thing that's needed, I see no harm in that.My main concern is for this to become a slippery slope - if there's a way for modifying UI from server side through REST API responses - and that's how UiAction works under the hood - there might be motivation to add more support for files in com.google.gerrit.extensions.webui package later. Which I don't believe is the best long-term strategy, and that's why I'm trying to resolve this question on philosophical level first.
Surely, this could be added as properties to the change actions, but this clearly would complicate things for PolyGerrit maintainers if making a UI change would trigger cascading changes to REST API (and that would require updating documentation, acceptance tests, let alone plugin considerations).I can't say much about the life of a PolyGerrit maintainer since I'm not one myself (though I'm willing to contribute to the best of my abilities) but from my point of view it needn't complicate things if all the REST API says is "Here's a primary action named "Press me", when pressed call this REST endpoint otherwise do with it what you please", which, from my rummaging through the part of the PolyGerrit code that handles such things, is more or less what happens today.Yes, but even in GWT UI there is a special handling of that data. Backed provides REST API response with change and revision actions, including ones added by plugins, and some of those actions end up as buttons:For example, looks like there's no way to omit Abandon, for what it's worth.The main difference is that the "primary", "secondary", "more menu" state is hard coded in the UI which IMO is strange, the importance (or prioritization if you will) should be something that is determined in the backend and all the frontend should care about is how it want's to handle that prioritization "The primary actions goes here and they should be displayed as such, and the secondary actions goes here and they should be displayed as such". I could go as far as to let the frontend be aware of different, separate, actions so that it can prioritize within e.g. the "primary" group "Is there an action named "submit"? In that case it should be the leftmost "primary" action" and when all named actions are sorted just fill in the rest to the right of those. There needn't be much concern regarding what the end result would be (if there are 20 actions in the list implemented by various plugins), it is the responsibility of the individual Gerrit admins to assess how they want to handle the eventual UI mess that would be the result of adding "too many" "primary" actions through plugins.So you're saying that it's the Gerrit admins who carry the burden of UI to be presentable to user in the end. I think that's fair, but even in this case it would be easier for admins to file feature requests against PolyGerrit rather than chasing plugin developers.
Overall, I agree with what you're saying. That's essentially something that PolyGerrit generally tries to achieve as well, based on data from various sources. The decisions that were made in this field are best of our knowledge and we're constantly improving them based on user feedback, various UX studies, design iterations, etc. Some of that is hardcoded, for example reply button size and position. Some of that is available for configuration, some isn't, for various reasons.So if there is a UI change, in most cases it wouldn't have to care about the backend, unless there's a need to add e.g. a "tertiary" action but, as I have stated my opinion earlier, that state should be reflected in the backend and the UI should just handle that third state (or fourth if you count the "more" menu), not define it.I see your point, but I afraid I can't fully agree with it on a general basis. And as I said above - if that only relates to UiAction and overflow menu - I think this isn't a problem to do.However, I can easily imagine situation when plugin provides an action that should not be added to More menu, but PolyGerrit does that anyway because number of buttons is too large, or they has too much text in them.Another scenario might be that the screen size is too narrow, for example it's a mobile device. In any case, this decision has nothing to do with backend - I don't think it would be beneficial for UiAction to have branching logic based on client's platform, aspect ratio, etc.
Just as a mental exercise, please try to imagine REST API for Gerrit's non-existent Android application. I'm certain, such API would have even less authority over application appearance.
I believe that a couple of areas where PG plugins can add elements and a couple of high level API points that covers the most commonuse-cases such as plugin.changeActions(), plugin.revisionActions(), goes a long way.If you want to do accomplish something above and beyond you should be prepared to either use the DOM API or implement and argue for a plugin API point that supports that use case.Yes! I think we agree here. If you have any specific high-level API ideas, please file an issue using this template:If the API is reasonable - like changeActions() - I don't think anyone will argue about it.
- tracking bug is filed describing the requirements
- extension point is added with params
- plugin author experiments using plugin.hook() method and stabilizes requirements for high-level API
- high-level API is implemented, covered with tests, documented, etc
- and plugin author replaces plugin.hook() with the high level API
I would like to add "add an example plugin using the API in plugins/example".Great point! We're not yet at the point when stackoverflow.com is of any help, so providing examples is clearly a big plus.
A default example of how to do that would be extremely helpful, and since surely it was considered how such a thing would be accomplished it would be enormously appreciated if someone versed in PolyGerrit could add such an example to plugins/examples with calling plugin REST API points and reloading the Change Screen without additional REST API calls if the reply from the REST API is a brand new ChangeInfo etc.
changeActions() the oldest API existing in PolyGerrit, and clearly it can be improved. And it wasn't documented since most of its users are front-end developers who essentially implemented it or reviewed the implementation.Since adding a UI action is a fairly common thing, this clearly could be wrapped into a high-level API so the final script code would simply be the following:const opts = {overflow: false, primary: true};
plugin.changeActions().addUIAction('kaboom', () => {
plugin.restApi().get('/config/server/version').then(console.log);
}, opts);This isn't hard to do, so it essentially boils down to the philosophy of the API.On the other hand, it doesn't seem that adding overflow and primary properties to extensions.webui.UiAction is complex, too.If that's the only thing that's needed, I see no harm in that.My main concern is for this to become a slippery slope - if there's a way for modifying UI from server side through REST API responses - and that's how UiAction works under the hood - there might be motivation to add more support for files in com.google.gerrit.extensions.webui package later. Which I don't believe is the best long-term strategy, and that's why I'm trying to resolve this question on philosophical level first.I share your concerns regarding the slippery slope. Special cases tend to add up, and it would probably be better to have one approach to rule them all.Surely, this could be added as properties to the change actions, but this clearly would complicate things for PolyGerrit maintainers if making a UI change would trigger cascading changes to REST API (and that would require updating documentation, acceptance tests, let alone plugin considerations).I can't say much about the life of a PolyGerrit maintainer since I'm not one myself (though I'm willing to contribute to the best of my abilities) but from my point of view it needn't complicate things if all the REST API says is "Here's a primary action named "Press me", when pressed call this REST endpoint otherwise do with it what you please", which, from my rummaging through the part of the PolyGerrit code that handles such things, is more or less what happens today.Yes, but even in GWT UI there is a special handling of that data. Backed provides REST API response with change and revision actions, including ones added by plugins, and some of those actions end up as buttons:For example, looks like there's no way to omit Abandon, for what it's worth.The main difference is that the "primary", "secondary", "more menu" state is hard coded in the UI which IMO is strange, the importance (or prioritization if you will) should be something that is determined in the backend and all the frontend should care about is how it want's to handle that prioritization "The primary actions goes here and they should be displayed as such, and the secondary actions goes here and they should be displayed as such". I could go as far as to let the frontend be aware of different, separate, actions so that it can prioritize within e.g. the "primary" group "Is there an action named "submit"? In that case it should be the leftmost "primary" action" and when all named actions are sorted just fill in the rest to the right of those. There needn't be much concern regarding what the end result would be (if there are 20 actions in the list implemented by various plugins), it is the responsibility of the individual Gerrit admins to assess how they want to handle the eventual UI mess that would be the result of adding "too many" "primary" actions through plugins.So you're saying that it's the Gerrit admins who carry the burden of UI to be presentable to user in the end. I think that's fair, but even in this case it would be easier for admins to file feature requests against PolyGerrit rather than chasing plugin developers.Overall, I agree with what you're saying. That's essentially something that PolyGerrit generally tries to achieve as well, based on data from various sources. The decisions that were made in this field are best of our knowledge and we're constantly improving them based on user feedback, various UX studies, design iterations, etc. Some of that is hardcoded, for example reply button size and position. Some of that is available for configuration, some isn't, for various reasons.So if there is a UI change, in most cases it wouldn't have to care about the backend, unless there's a need to add e.g. a "tertiary" action but, as I have stated my opinion earlier, that state should be reflected in the backend and the UI should just handle that third state (or fourth if you count the "more" menu), not define it.I see your point, but I afraid I can't fully agree with it on a general basis. And as I said above - if that only relates to UiAction and overflow menu - I think this isn't a problem to do.However, I can easily imagine situation when plugin provides an action that should not be added to More menu, but PolyGerrit does that anyway because number of buttons is too large, or they has too much text in them.Another scenario might be that the screen size is too narrow, for example it's a mobile device. In any case, this decision has nothing to do with backend - I don't think it would be beneficial for UiAction to have branching logic based on client's platform, aspect ratio, etc.Yes, but what I'm saying is that you could give the Action a priority in the back-end. Let's say a brand new production critical action is implemented as a UiAction in a plugin and it "needs" not to be hidden in the "more" menu. All the same it's a best effort, if someone is using a screen where there's no room for the button then reality wins. If this is unacceptable then you have a special case where you have to step out of the UiAction comfort zone and solve it elsewhere.
Just as a mental exercise, please try to imagine REST API for Gerrit's non-existent Android application. I'm certain, such API would have even less authority over application appearance.As I tried to relay above, I do not argue that the back-end should have _any_ application appearance authority at all apart from description, it should just give the UI a chance to order the Actions on the priority that the back-end gives them.
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
@Viktar?Luca.
To unsubscribe, email repo-disc...@googlegroups.com
Can you please provide an example for a button that does more than just console.log?
@Viktar?Luca.
--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
Gerrit.install(plugin => {plugin.hook('change-metadata-item').onAttached(el => {const b = el.appendChild(document.createElement('input'));b.type = 'button';b.value = 'Foo bar';b.onclick = () => alert('foo');});});
Hi,I'd really appreciate if anyone can post an example of adding a change action with a popup on PG.
On Friday, January 18, 2019 at 8:14:14 AM UTC+1, Orgad Shaneh wrote:Hi,I'd really appreciate if anyone can post an example of adding a change action with a popup on PG.I agree, it would be extremely valuable to have some examples of the different PG extension points in "plugins/examples".The only example I've seen so far is that some plugin(s) have implemented the menu-item(!?) extension points but none in "plugins/examples".