Problem creating reusable widgetsets

I have a problem reusing a widgetset I created. The problem lies inside the mechanism of referencing the public widgetset-directory from client-side (GWT) code.

I have used the following:

GWT.getModuleBaseURL()+"external-javascript-file.js"

But this only seems to work ok, if I’m using the widgetset directly in the application. But if I inherit the widgetset the method getModuleBaseURL does not return the correct widgetset directory anymore (it returns an empty string).

Basicly, what this does is that any of inherited widgetsets referencing static resources using the getModulebaseURL do not work.

I’m not sure if I’m facing a GWT bug here, but maybe my approach is wrong altogether and there is a some better solution in the IT Mill Toolkit for this? Should I even be using getModulebaseURL to find the static resources within a widgetset?

Toolkit version: 5.3.0. RC5
GWT version: 1.5.3 (Mac)

Btw: It would be nice to have the ApplicationConnection.isDebugMode as public to you write debugging code for your own widgets.

Hi Sami!

Have you tried using script tag in your gwt module description file ? (the one that ends .gwt.xml). It automatically loads script file when application starts.

I don’t believe there there is a bug in module inheritance. Can you provide some more information what you are doing?

What kind of debugging are you trying to accomplish? There is some basic methods available. Try for example a following code:

 ApplicationConnection.getConsole().log("Test") 

cheers,
matti

Hi!

I made ApplicationConnection.isDebugMode() method public. So in next RC release you ought to have this available. Now you should be able to optimize your debug messages.

cheers,
matti

Thanks Matti,

I managed to solve this… or something :slight_smile:

I have two levels of GWT inheritance (i.e. an application with its own widgetset using another component widgetset that in turn used external GWT module with static resources (flash, javascript).

It was not enough to use the

in my applications widgetset. I also had to include all modules the component widgetset was using (regardless that the component widgetset had all necessary inherits). So it seems that the GWT inherits are not transitive.

I could not figure out all this by myself, so I think it is best to warn everyone there trying to create reusable widgetsets:

I was experiencing wide variety of seemingly unrelated symptoms in my application using a custom widgetset: disappearing windows, URI and parameter handlers not working and so on. This all seemed somehow be timing related and sometimes everything even worked ok! Debugger did not reveal anything relevant, but the reason for all these problems was pretty obvious … once you know it.

If you create a widgetset that is inherited you must
make sure that there is not a GWT entry point in that widgetset
. Otherwise your application ends up initializing the server connection twice, which in turn yields to numerous (unrelated) problems.

Basically, I fixed this in the inherited custom widgetset by introducing WidgetSetNoEntry.gwt.xml file along to the original WidgetSet.gwt.xml. This file does not have the GWT entry point declaration and it can be safely inherited in application widgetsets.

Ok, this was my own fault, not understanding all this GWT stuff, but still a little enhancement suggestion:
It would have be
very
helpful if the framework should at least try to warn developer about these multiple GWT entry points. Best would be that applications would not start at all (together with proper error message of course).

Hi,

This is a very good point! It’s easy to fix once you understand the problem, but it can be (usually is) extremely hard to figure out what the problem is.

I created
#2494
for this issue.

I think we can now solve this and remove the need to provide a separate “[…]
NoEntry.gwt.xml”, since GWT 1.5 has some new features that were not available previously - at the very least, we can make it fail completely with an informative error message when this situation is detected.

Best Regards,
Marc