Extending Gerrit Web UI

1,551 views
Skip to first unread message

Dariusz Luksza

unread,
Sep 26, 2012, 4:37:37 PM9/26/12
to repo-d...@googlegroups.com
For extending server side Gerrit there are plugins and extensions, but currently I don't see any mechanism for extending GWT based ui and RPC/JSON servises. For example there is no possibility to add
new page/option to the user preference page without modifying gerrit sources. Is there any idea how such extensions can be implemented?

--
Best regards

GSM: +48 695 192 160
Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza

Brad Larson

unread,
Sep 27, 2012, 2:48:36 PM9/27/12
to repo-d...@googlegroups.com


On Wednesday, September 26, 2012 3:39:05 PM UTC-5, Dariusz Łuksza wrote:
For extending server side Gerrit there are plugins and extensions, but currently I don't see any mechanism for extending GWT based ui and RPC/JSON servises. For example there is no possibility to add
new page/option to the user preference page without modifying gerrit sources. Is there any idea how such extensions can be implemented?

We currently have no solutions.  The GWT UI is compiled to javascript at compile time, so plugin support is not easy.  This is something I hope we can solve in the next few months.

For specific locations, such as adding a page to the user preferences page, I think it would make sense to have Gerrit's frontend ask the server for a list of titles/links to show in the collection of pages.  Then plugins could inject themselves there.  We could do something similar with the list of links at the top of Gerrit (My, Projects, Admin, Documentation).  Other developers have expressed concern that this approach would leave the UI too cluttered & unwieldy.

Brad

Dave Borowitz

unread,
Sep 27, 2012, 2:56:06 PM9/27/12
to Brad Larson, repo-discuss
On Thu, Sep 27, 2012 at 11:48 AM, Brad Larson <bkla...@gmail.com> wrote:


On Wednesday, September 26, 2012 3:39:05 PM UTC-5, Dariusz Łuksza wrote:
For extending server side Gerrit there are plugins and extensions, but currently I don't see any mechanism for extending GWT based ui and RPC/JSON servises. For example there is no possibility to add
new page/option to the user preference page without modifying gerrit sources. Is there any idea how such extensions can be implemented?

We currently have no solutions.  The GWT UI is compiled to javascript at compile time, so plugin support is not easy.  This is something I hope we can solve in the next few months.

+1, I have said as much to Shawn on multiple occasions :)
  
For specific locations, such as adding a page to the user preferences page, I think it would make sense to have Gerrit's frontend ask the server for a list of titles/links to show in the collection of pages.  Then plugins could inject themselves there.  We could do something similar with the list of links at the top of Gerrit (My, Projects, Admin, Documentation).  Other developers have expressed concern that this approach would leave the UI too cluttered & unwieldy.

Unfortunately there is a chicken-and-egg problem here: nobody wants to work on the UI (to make it less cluttered & unwieldy) until it's no longer GWT. This includes both current contributors and new contributors, who might have more design/HTML/CSS/JS background but have little interest in Java, let alone GWT. IMHO over the next several months one or more core developers is just going to have to bite the bullet and start converting Gerrit to use another templating system.

It is important that this can happen piecewise, because rewriting the entire UI in one fell swoop is just far too much work. But that also means it's significantly more overhead to get started, since we will have to write some tricky glue to tell GWT that divs X, Y, and Z are just prerendered blobs. Also, some of this work is probably also blocking on expanding the new JSON API. But I really think that once we get started the effort can gain serious momentum and increase our casual contributor base :)

Brad

Brad Larson

unread,
Sep 27, 2012, 3:14:26 PM9/27/12
to repo-d...@googlegroups.com, Brad Larson


On Thursday, September 27, 2012 1:56:31 PM UTC-5, Dave Borowitz wrote:
On Thu, Sep 27, 2012 at 11:48 AM, Brad Larson <bkla...@gmail.com> wrote:


On Wednesday, September 26, 2012 3:39:05 PM UTC-5, Dariusz Łuksza wrote:
For extending server side Gerrit there are plugins and extensions, but currently I don't see any mechanism for extending GWT based ui and RPC/JSON servises. For example there is no possibility to add
new page/option to the user preference page without modifying gerrit sources. Is there any idea how such extensions can be implemented?

We currently have no solutions.  The GWT UI is compiled to javascript at compile time, so plugin support is not easy.  This is something I hope we can solve in the next few months.

+1, I have said as much to Shawn on multiple occasions :)

By 'solve', I'm not sure I meant completely throw out GWT :)

I agree GWT means we exclude lots of HTML/CSS/JS developers, which is unfortunate.  Perhaps better/more use of UiBinder[1][2] would help with that?

We currently have a (metric) ton of java code which ends up on the client side... If we switched away from GWT, what would we switch to?  I'm not that familiar with all the options, but of the ones I have seen, GWT seems to be the least bad.

Dave Borowitz

unread,
Sep 27, 2012, 3:27:27 PM9/27/12
to Brad Larson, repo-discuss
On Thu, Sep 27, 2012 at 12:14 PM, Brad Larson <bkla...@gmail.com> wrote:


On Thursday, September 27, 2012 1:56:31 PM UTC-5, Dave Borowitz wrote:
On Thu, Sep 27, 2012 at 11:48 AM, Brad Larson <bkla...@gmail.com> wrote:


On Wednesday, September 26, 2012 3:39:05 PM UTC-5, Dariusz Łuksza wrote:
For extending server side Gerrit there are plugins and extensions, but currently I don't see any mechanism for extending GWT based ui and RPC/JSON servises. For example there is no possibility to add
new page/option to the user preference page without modifying gerrit sources. Is there any idea how such extensions can be implemented?

We currently have no solutions.  The GWT UI is compiled to javascript at compile time, so plugin support is not easy.  This is something I hope we can solve in the next few months.

+1, I have said as much to Shawn on multiple occasions :)

By 'solve', I'm not sure I meant completely throw out GWT :)

I agree GWT means we exclude lots of HTML/CSS/JS developers, which is unfortunate.  Perhaps better/more use of UiBinder[1][2] would help with that?

Yes, completely agree.
 
We currently have a (metric) ton of java code which ends up on the client side... If we switched away from GWT, what would we switch to?  I'm not that familiar with all the options, but of the ones I have seen, GWT seems to be the least bad.
 
Nor am I familiar with the state of the art in JS frameworks, certainly. But I think from the perspective of lowering the barrier to external contributors, getting that client-side code out of Java could be even better than just using UiBinder for templating. These hypothetical developers (not actually hypothetical, I'm thinking of one vocal one from a meeting with Wikimedia) aren't just interested in layout and styling, they're also interested in scripting behavior. I.e., they're not HTML/CSS developers, they're HTML/CSS/JS developers...and right now we have very little JS that doesn't come from the GWT compiler.

The real question in my mind is not how much client-side code do we have written in Java, it's how much client-side code do we have written in Java where it's important that the client and server share the exact same code. Porting one way may be a lot of work, but it's still easier than maintaining versions indefinitely in both languages with identical functionality.

Of course, at the end of the day I'm highly opinionated without having actually touched much of the GWT code, so take this all with a grain of salt.

Swindells, Thomas

unread,
Sep 28, 2012, 8:51:58 AM9/28/12
to Dave Borowitz, Brad Larson, repo-discuss

I’d have to disagree. I may be wrong but I imagine the vast majority of people who would consider contributing to Gerrit are likely to be java developers rather than java script developers.

One of the things that makes me much more likely to develop and contribute towards Gerrit is the fact that the end to end development of server and UI changes are in one language, I may need to learn GWT but this is likely to be much easier than learning javascript and whatever particular javascript framework is chosen.

 

I may be wrong and not know enough about the backend Gerrit code by I imagine that few significant UI changes can be made without also have to work on the server side java code.

 

Thomas





**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

Chad Horohoe

unread,
Sep 28, 2012, 9:05:49 AM9/28/12
to Swindells, Thomas, Dave Borowitz, Brad Larson, repo-discuss
Dave's anecdote is totally true...I've got a few coworkers at Wikimedia who
are turned off from contributing since everything's done in Java. Personally
I'm on the fence about a switch (Java doesn't bother me, and obviously more
than a few others agree), but I think the prudent choice is to decide what is
best for encouraging people to contribute.

As to "UI changes need backend changes" -- I would have to disagree. There
is a lot of UI work that can be done based on CSS/Javascript/HTML alone,
without needing any logic changes. Also, it makes it easier for people to hack
at mockups for change without having to dig nearly as deep into the Java.

-Chad

Jean-Baptiste Queru

unread,
Sep 28, 2012, 9:11:05 AM9/28/12
to repo-discuss
Let's make sure however that we don't end up losing existing
functionality (again) as part of a re-write.

JBQ
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

Dariusz Luksza

unread,
Oct 3, 2012, 5:01:57 AM10/3/12
to repo-d...@googlegroups.com
On 09/27/2012 08:48 PM, Brad Larson wrote:
>
>
> On Wednesday, September 26, 2012 3:39:05 PM UTC-5, Dariusz Łuksza wrote:
>
> For extending server side Gerrit there are plugins and extensions, but currently I don't see any mechanism for extending GWT based ui and RPC/JSON servises. For example there is no possibility to add
> new page/option to the user preference page without modifying gerrit sources. Is there any idea how such extensions can be implemented?
>
>
> We currently have no solutions. The GWT UI is compiled to javascript at compile time, so plugin support is not easy. This is something I hope we can solve in the next few months.

I think I found solution how we can extend web ui using GWT or javascript without breaking existing implementation.

The idea is to add 'web-plugin' folder inside plugin jar with compiled GWT or plain javascript (+plus resources) code. Then during plugin installation copy its content to /static/${plugin_name}/, add
it with given module name (eg. hello-gerrit-ui.nocache.js, extension.js etc...) to list of active web ui plugins. Finally when users enter gerrit web page we will load this list and dynamically add
scripts to page (it is also possible that GWT based plugins would require additional initialization).

Currently I managed to build proper jar using maven with javascript based plugin and load and execute this simple 'hello-world' plugin during Gerrit web load process. Now will investigate how GWT
plugin can be loaded, then will add some stable id's and JSNI hooks/listeners for buttons so that plugins can be easly integrated with existing Gerrit UI.

Hope to share with you my code in next 3 or 4 days. Any hints/comments on my current approach are welcome ;)

Shawn Pearce

unread,
Oct 3, 2012, 10:17:42 AM10/3/12
to Dariusz Luksza, repo-discuss
On Wed, Oct 3, 2012 at 2:01 AM, Dariusz Luksza <dariusz...@gmail.com> wrote:
> On 09/27/2012 08:48 PM, Brad Larson wrote:
>> On Wednesday, September 26, 2012 3:39:05 PM UTC-5, Dariusz Łuksza wrote:
>>
>> For extending server side Gerrit there are plugins and extensions, but
>> currently I don't see any mechanism for extending GWT based ui and RPC/JSON
>> servises. For example there is no possibility to add
>> new page/option to the user preference page without modifying gerrit
>> sources. Is there any idea how such extensions can be implemented?
>>
>>
>> We currently have no solutions. The GWT UI is compiled to javascript at
>> compile time, so plugin support is not easy. This is something I hope we can
>> solve in the next few months.
>
>
> I think I found solution how we can extend web ui using GWT or javascript
> without breaking existing implementation.
>
> The idea is to add 'web-plugin' folder inside plugin jar with compiled GWT
> or plain javascript (+plus resources) code. Then during plugin installation
> copy its content to /static/${plugin_name}/,

There is no need to do this. Please don't extract content from the
plugin JAR or install it into $site_path/static.

If a plugin has a "static/" folder in the top level of its JAR, this
content is available automatically over HTTP as
/plugins/$name/static/$path. So you just need to package the web
content for the plugin in a package named "static" within its JAR. Add
a src/main/resources/static folder to your plugin and put your files
there. :-)

> add it with given module name
> (eg. hello-gerrit-ui.nocache.js, extension.js etc...) to list of active web
> ui plugins. Finally when users enter gerrit web page we will load this list
> and dynamically add scripts to page (it is also possible that GWT based
> plugins would require additional initialization).

Use an extension point registration. Though we may want this to be a
bit more automatic-magical based on a specific JavaScript source file
name being present in the static/ folder of a plugin's JAR, but the
most flexible approach is to use an extension point with a tiny
interface definition:

public interface WebUiScript {
/** @returns URI of the JavaScript resource to load by a <script>
tag to permit the
* plugin to contribute to the web UI. The URI should be relative
to the plugin's
* root, so "static/foo.js" to load foo.js file from the plugin's
static resources folder.
*/
public String getScriptUri();
}

Until automagic-magical registration works, plugins will need to
register this with a Guice module. But now you can build a
DynamicSet<WebUiScript> and have the HostPageServlet iterate through
these during doGet() and inject additional <script> tags right into
the host HTML page as it is sent to the browser. Now any plugin can
force any JavaScript into the host page.

> Currently I managed to build proper jar using maven with javascript based
> plugin and load and execute this simple 'hello-world' plugin during Gerrit
> web load process. Now will investigate how GWT plugin can be loaded, then
> will add some stable id's and JSNI hooks/listeners for buttons so that
> plugins can be easly integrated with existing Gerrit UI.

Right, stable IDs and stable native JavaScript callback points are
necessary to connect the two chunks of JS together.

> Hope to share with you my code in next 3 or 4 days. Any hints/comments on my
> current approach are welcome ;)

This might actually work. I am looking forward to seeing it. :-)

Dariusz Luksza

unread,
Oct 3, 2012, 12:07:17 PM10/3/12
to Shawn Pearce, repo-discuss
On 10/03/2012 04:17 PM, Shawn Pearce wrote:
> There is no need to do this. Please don't extract content from the
> plugin JAR or install it into $site_path/static.
>
> If a plugin has a "static/" folder in the top level of its JAR, this
> content is available automatically over HTTP as
> /plugins/$name/static/$path. So you just need to package the web
> content for the plugin in a package named "static" within its JAR. Add
> a src/main/resources/static folder to your plugin and put your files
> there. :-)

Great! didn't know that, this make things even simpler!

> Use an extension point registration. Though we may want this to be a
> bit more automatic-magical based on a specific JavaScript source file
> name being present in the static/ folder of a plugin's JAR, but the
> most flexible approach is to use an extension point with a tiny
> interface definition:
>
> public interface WebUiScript {
> /** @returns URI of the JavaScript resource to load by a<script>
> tag to permit the
> * plugin to contribute to the web UI. The URI should be relative
> to the plugin's
> * root, so "static/foo.js" to load foo.js file from the plugin's
> static resources folder.
> */
> public String getScriptUri();
> }

I have similar idea, but instead of providing full URI to script I would rather prefer return main script name and then concat it with /plugins/$name/static/$path. Maybe even would be better to create
two interfaces one for GWT based plugin and for native javasript one. Then we could at least concatenate GWT moulde name with ".nocahe.js"

> Until automagic-magical registration works, plugins will need to
> register this with a Guice module. But now you can build a
> DynamicSet<WebUiScript> and have the HostPageServlet iterate through
> these during doGet() and inject additional<script> tags right into
> the host HTML page as it is sent to the browser. Now any plugin can
> force any JavaScript into the host page.

In my current draf implementation I extend HostPageData with List<WebUiPlugin>. WebUiPlugin contains only plugin name and module/file name.

It seams that we have quite similar idea how Web Ui plugins should be implemented ;)

Brad Larson

unread,
Oct 3, 2012, 3:19:38 PM10/3/12
to repo-d...@googlegroups.com, Shawn Pearce
Sounds very promising!  I posted on irc a while back that something like http://code.google.com/p/gwt-google-apis/wiki/GadgetsGettingStarted might be an option for using gwt to compile the plugin javascript.  One of the great benefits of injecting JS for plugin UI is that the plugin JS can be compiled by gwt or hand-generated (or something else...)

Dariusz Luksza

unread,
Oct 6, 2012, 5:17:34 AM10/6/12
to repo-d...@googlegroups.com
Hi all

Here is a quick update on status of Web Ui plugins.

As I mentioned before JavaScript based plugins was really easy to implement. Just put source code in static/ dir in jar file and load it into gerrit using GWT API.

Most straggle I had with GWT based plugin. It appear that compiled gwt modules cannot be simply loaded into web page. The EntryPoint.onModuleLoad is not called when it is dynamically loaded, even when
plugin loads and I "manually" execute module init function (called same as module name) the web page just reload into some undefined state showing just white background. After some time I decided to
play a bit with gadget API mentioned by Brad (thanks Brad!), first I started hacking on compiled version of gadget bootstrap script (after extracting it from gadget.xml file). Commenting out couple
lines of code makes gadget ui loadable in Gerrit (I manage load hellogadget sample app into gerrit, but clicking on 'click me' doesn't show dialog window). Finally I moved to modifying gadget linker
source code to generate proper bootstrap file on compilation. For now this is also done, I can easily compile and load GWT generated javascript into gerrit web page.

Next tasks are:
* Figure out why dialog window doesn't appear after cliking on 'click me' button in hellogadget app
* Port gwt-gadget linker and rebinds into Gerrit. I think I'll add new maven module called eg. gerrit-gwtui-plugin-linker (do you have anything against this?)
* IMO it is worth to have separate artifacts for JavaScript and GWT based artifact.
* Define stable ID's and hooks for connecting plugins with current UI infrastructure
* Provide sample plugins

Swindells, Thomas

unread,
Oct 8, 2012, 4:34:26 AM10/8/12
to Dariusz Luksza, repo-d...@googlegroups.com
It looks like you are doing really good work here, thank you.

I look forward to seeing it complete and being able to customize Gerrit even further,

Thomas
> -----Original Message-----
> From: repo-d...@googlegroups.com [mailto:repo-
> dis...@googlegroups.com] On Behalf Of Dariusz Luksza
> Sent: 06 October 2012 10:18
> To: repo-d...@googlegroups.com
> Subject: Re: Extending Gerrit Web UI
>

Luca Milanesio

unread,
Oct 8, 2012, 4:44:34 AM10/8/12
to Dariusz Luksza, repo-d...@googlegroups.com
Hi Dariusz,
the work you are doing seems very exciting ... though complicated I guess :-(

Do you think this would produce an "easy-to-use" plug-in framework ?
If not ... can we think about something less compelling but simpler ? (i.e. allowing pluggable menu-items and "empty div" to be served/rendered by a HTTP-based plug-in ?)

The all purpose of plug-ins should be enable "non-Gerrit-techies" to extend the platform without knowing so much about the internals.

What do you think ?

Luca.

Dariusz Luksza

unread,
Oct 8, 2012, 11:24:55 AM10/8/12
to Luca Milanesio, repo-d...@googlegroups.com
Hi Luca,

Yes it is exiting, but at the beginning it looks much simpler ... at
least we have igoogle gadget gwt linker source code on which we can
base our code.

Currently it looks that we can establish public API for GWT based
plugins that will look more or less like:

public interface GerritUI {
public interface Containers {
void appendToMainMenu(Widget element);
void appendToAdminTab(Widget element);
void appendToMyTab(Widget element);
...
void appendToProjectOptionsTab(Widget element);
}
public interface Actions {
onGeneralProjectOptionsSaved(Callback callback);
onSubmit(Callback callback);
}

public Cointerners getContainers();
public Actions getActions();
}

public class ExampleUiPlugin extends GeritUiPlugin {
public void onPluginInit(GerritUi ui) {
ui.getContainers().appendToMainMenu(new Label("Manage instance"));
}
}

And you will have new "Manage instance" tab next to "Admin" tab. Of
course you also need to add one dependency to yours pom.xml and
gwt.xml files. Rest should be handled by GWT compiler and maven.

Same plugin in javascript could look more or less like this:

var instanceManager = document.createElement('p');
instanceManager.setInnerHtml('Manage instance');
gerritElements.containers.appendToMainMenu(instanceManager);

IMO it won't be complicated for consumers ... but it can be
complicated for us to implement such framework.

Shawn Pearce

unread,
Oct 8, 2012, 12:09:47 PM10/8/12
to Dariusz Luksza, Luca Milanesio, repo-discuss
Interesting. I originally thought the gadget linker might be a bit too
complex to justify using, but this is a reasonably straight forward
API for clients to work with.

We should try to make adding items to the menu even easier than
shoving a random widget in, because at least in the menu system you
want the menu linked to a URL and the URL to be stable, so we need to
also teach our dispatcher how to parse URLs for plugins and forward
them to the plugin's own dispatcher routine (or routines).

Dariusz Luksza

unread,
Oct 10, 2012, 1:43:20 PM10/10/12
to Shawn Pearce, repo-discuss
Here is first part of Web UI plugin support[1], currently only plugin
loading is supported (no extension points yet was defined). Also I've
notice that plugin installation requires Gerrit restart because
HostPageServlet doesn't refresh and uses old cached (at start up) list
of loaded plugins. I will look on this and amend first commit.

You can try to play with Web UI plugins using defined artifacts for js
and GWT based plugins. Have fun!

I'm looking forward for any comments on current patch status.


[1] https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit+branch:master+topic:web-ui-plugins,n,z

Sarah Thiel

unread,
Nov 14, 2012, 7:51:17 AM11/14/12
to repo-d...@googlegroups.com, Shawn Pearce
Hi Dariusz,
I was trying to download your suggestions for a web-ui-plugin; however the page is comming up blank - or do I just don't have access to it?

So, is there currently a way to extend the gerrit web ui in the way Dariusz was asking at the top of this thread?
I'm trying to find a way wih the existing code, but the only method I could think of (or find) was via HttpServlets - what would be kinda dirty hacking
What I'm trying to get is a plugin that would add items (and therefore also pages/screens) to the menu of the Gerrit web UI.

Thanks for your ideas!

Nasser Grainawi

unread,
Nov 14, 2012, 11:23:15 AM11/14/12
to Sarah Thiel, repo-d...@googlegroups.com, Shawn Pearce
It's coming up blank because that search string had "open" in it. Dariusz's changes were merged.

Nasser
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Dariusz Luksza

unread,
Nov 14, 2012, 11:41:52 AM11/14/12
to Nasser Grainawi, Sarah Thiel, repo-discuss, Shawn Pearce
Unfortunately we break Web UI plugins during code review... here is
last needed fix[1], just fetch it and install locally then try
generating new plugin using new archetype (if it works please +1 my
changes ;)). Hope this will be merged soon in 2.6-SNAPSHOT/2.6-rc0

[1] https://gerrit-review.googlesource.com/#/c/39297/
GSM: +49 017 445 41235

Jeff

unread,
Jul 22, 2013, 11:11:50 AM7/22/13
to repo-d...@googlegroups.com, Nasser Grainawi, Sarah Thiel, Shawn Pearce
Dariusz,
Should this be functional in 2.7? I have built a plugin based on gerrit-plugin-gwt-archetype, and have it working on my 2.7.rc2 build, but I have not been able to "restrict" the plugin to a specific page, or bind to a new page.  Should this be possible at all yet? Currently the GWT toolbox is showing up on every page in the Gerrit UI..  
Any suggestions would be greatly appreciated!

Dariusz Luksza

unread,
Jul 23, 2013, 1:00:25 AM7/23/13
to Jeff, repo-discuss, Nasser Grainawi, Sarah Thiel, Shawn Pearce
Hi Jeff,

Yes, this fix is in 2.6 and of course in 2.7.

To restrict plugin to a specific page you need to add use
gerrit_addHistoryHook function (it is exposed to JS in
Gerrit.java:437). I takes function of one string parameter and should
be called when Gerrit will change screen. Based on screen names you
can show/hide UI content. You will need another JSNI function in yours
code to wrap gerrit_addHistoryHook and be able to use it in GWT. I did
NOT test this idea, but theoretically it should work please update me
whether it worked or not ;)
> --
> ---
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.

Jeff

unread,
Jul 23, 2013, 2:39:06 PM7/23/13
to repo-d...@googlegroups.com, Jeff, Nasser Grainawi, Sarah Thiel, Shawn Pearce
Thanks Dariusz,

Here's what I've come up with so far for diagnostics/proof of concept (IE: not finalized code). This is in the "client" side of the Plugin I generated from gerrit-plugin-gwt-archetype (HelloPlugins.java):

  public native static JavaScriptObject getHistoryHook() /*-{
  var rv = new String("Didn't work");
window.onload = function() {
      $wnd.gerrit_addHistoryHook(function (s) {
        alert(s);
        rv = s;
      });
    };
   return rv;
}-*/;
The intention was to use a method similar to this to determine the current page, and only perform the rest of the page load on a specific page (admin/plugins for now, probably)

I tweaked the "Click me" button to return the results of this cast to a String.  With this change, I end up with a "Didn't work" button, and whenever I change pages, I do get the JS alert, with the correct page URL identified ("/#/admin/plugins", etc).  The JS alert does NOT happen in Chrome, only Firefox.   I'm not really sure why.  

This seems to indicate that the $wnd.onload is being called, but only after the OnModuleLoad() method in the Plugin.  

Do you have any suggestions, or am I totally on the wrong track?  I seem to have run into a bit of a chicken & egg problem.

Thanks!
-Jeff

Shawn Pearce

unread,
Jul 23, 2013, 3:45:47 PM7/23/13
to Jeff, repo-discuss, Nasser Grainawi, Sarah Thiel
On Tue, Jul 23, 2013 at 11:39 AM, Jeff <jeff....@garmin.com> wrote:
>
> Thanks Dariusz,
>
> Here's what I've come up with so far for diagnostics/proof of concept (IE: not finalized code). This is in the "client" side of the Plugin I generated from gerrit-plugin-gwt-archetype (HelloPlugins.java):
>
> public native static JavaScriptObject getHistoryHook() /*-{
> var rv = new String("Didn't work");
> window.onload = function() {
> $wnd.gerrit_addHistoryHook(function (s) {
> alert(s);
> rv = s;
> });
> };
> return rv;
> }-*/;
> The intention was to use a method similar to this to determine the current page, and only perform the rest of the page load on a specific page (admin/plugins for now, probably)
>
> I tweaked the "Click me" button to return the results of this cast to a String. With this change, I end up with a "Didn't work" button, and whenever I change pages, I do get the JS alert, with the correct page URL identified ("/#/admin/plugins", etc). The JS alert does NOT happen in Chrome, only Firefox. I'm not really sure why.
>
> This seems to indicate that the $wnd.onload is being called, but only after the OnModuleLoad() method in the Plugin.

Don't use window.onload. Your plugin code looks like this:

package com.garmin.test;

public class HistoryHook {
static void onPageChange(String token) {
Window.alert(token);
}

native static void init() /*-{
$wnd.gerrit_addHistoryHook($entry(@com.garmin.test.HistoryHook::onPageChange(Ljava/lang/String;)));
}-*/;
}

In your onModuleLoad() call HistoryHook.init() to install yourself.
Gerrit will invoke your onPageChange static method with the new token.
Fill in code from there.

Jeff

unread,
Jul 23, 2013, 5:05:29 PM7/23/13
to repo-d...@googlegroups.com, Jeff, Nasser Grainawi, Sarah Thiel
Thank you, Shawn,
I tried the code you provided, unfortunately I think I'm still doing something wrong:

I added a static String url to the HistoryHook class (with proper getters and setters), and set it in HistoryHook.onPageChange,  however after performing HistoryHook.init() from my plugin's onModuleLoad() , the HistoryHook.getUrl method still is not providing the correct results, unless I call it in the onClick handler for a dialog box.  I'm probably doing something stupid, but this seems to indicate that i am still not getting the HistoryHook class populated (via onPageChange) until after the onModuleLoad() has completed.

Perhaps I am making this too difficult, is there a simpler way to extend the Gerrit UI, without resorting to writing everything directly from a Servlet (as indicated in the example provided at http://gerrit-documentation.googlecode.com/svn/Documentation/2.7/dev-plugins.html)? I have tried integrating various frameworks with the Plugin API/HttpModule framework, ultimately without success.  All that I am trying to accomplish is a simple request form/result page for the plugin I am working on (https://groups.google.com/forum/#!topic/repo-discuss/_-5-23TX3MY), unfortunately I seem to be running into roadblocks in every approach I take.  

Thanks again for the help.
Reply all
Reply to author
Forward
0 new messages