I tries to do the same.
I have some editor environment wtirren on gwt and want do able dtting
the plugins.
So I created "api" library and define Plugin interface.
The "core" library tries to load "plugin implementation" ( is separate
project where the PluginModule implements EntryPoint, api.Plugin )
The next way is registration plugin in core. I tries to add
plugin.nocache.js to loaded "core" project and register plugin throw
native js function.
Before i sets this function like

   private native void setRegisterPluginFunction(PluginRegister
instance) /*-{
      var func = function(plugin) {
 
[email protected]::onRegisterPlugin(Lorg/
exoplatform/ideall/api/plugin/IDEPlugin;)(plugin);
      }
      $wnd.setRegisterFunction(func);
   }-*/;

here setRegisterFunction - is variable in javascript.
after i tries to call the function like below from plugin ( it has own
entry point ) and onRegisterPlugin function is called in "core" but
parameter is wrong.
i received some object ( windows chrome says that this is
DIVHtmlObject or like ) against Plugin implementation

   public static native void addPlugin(IDEPlugin ob) /*-{
      try {
         alert("register function:" + $wnd.registerPluginFunction);

         if ($wnd.registerPluginFunction == null) {
            alert("RegisterPluginFunction is not set!");
         } else {
            alert(">> registering >> " + ob);
            $wnd.registerPluginFunction(ob);
         }
      } catch(err) {
        alert("Error: " + err);
      }
   }-*/;

I think than for current time there is no way to do this.
I see that is able to communicate with two modules with
JavaScriptObject's ( same JSON structures ) but I want to communicate
with some GWT instances.

On 25 фев, 10:57, Blessed Geek <[email protected]> wrote:
> Sorry, I reread your post quite a few times and I am still feeling
> fuzzy if I had the comprehension to understand it.
>
> I've tried this before, mixing the gwt compilation output of all the
> modules into the same folder in the war.
>
> I don't think that is necessary. If I wanted all the modules in the
> same war context folder, I simply have more than one entry-point
> modules within the same source directory. And then gwt would compile,
> say you have five entry-points in the same source directory, and all
> the five output war context folders would contain the same contents.
> Every of the five context output folders contains the compiled of all
> the five entry-points.
>
> What I think you are trying to do is wanting to use the same url
> context for, say, five different gwt compiled entry-point js.
>
> You cannot copy only the nocache.js files. You have to copy the other
> files too because the brand of the browser would determine which files
> are used. Inside a  the nocache.js, you will find a translation table
> mapping browser type to the js file to be used.
>
> Therefore, I don't think getting our fingers dirty by copying the
> output into a single context folder should be done. At the worst, you
> should create more than one entry-points within the same gwt source
> path.
>
> Even that, I don't recommend because gwt compilation is repeated n-
> squared times, n = number of modules.
>
> You should use the module rename-to attribute and then have a single
> launch html to load all five modules.
>
> Still, even that I would not recommend. Why would you want to load all
> five modules when your user would then choose to only use one of the
> five.
>
> I am trying to understand why you can't have a single entry-point
> module and five non-entry-point module and then inside your gwt java
> source refer to these modules and let gwt manage the loading in an
> optimal way. I am feeling I don't understand your problem too well
> because, I still can't figure out why you cannot have a single entry-
> point module whose gwt.xml inherits the other modules. Which is what I
> do as I too have multiple applications being accessed from the same
> context url.
>
> We should not be thinking about Reflection. We should design our
> applications with Interfaces or with a common super-class module. So
> that, depending on user choice, since all our modules implement a
> particular interface, we are able to direct our various applications
> to load or execute in a commonly recognised way.
>
> Thousands apologies if I misunderstood your post.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to