Mvp4g and GWT 2.x: RunAsyncFeatures
Pierre
Mvp4g could use new GWT 2.x features:
"In GWT 2.x there is a feature to define code splitting. Separate
config files could be as modules, each file could contains module
specific views, presenters and etc. and each module should be
activated on specific event within "RunAsync" mode. After module
activation event triggered, module should be downloaded and module
init action should be performed.
Thereby we can decrease size of *.js files and application startup
time." (see message http://groups.google.com/group/mvp4g/msg/e403b4dd29a4776b)
He also gave two implementation examples:
see message http://groups.google.com/group/mvp4g/msg/e984ca78e4e72dd5
"Hi, I have additional improvement. This improvement-proposal is
consider
with abilities to define alternative configuration file. This
functionality
will be helpful when your application requires separate GWT and mvp4g
based
admin panel (back-end) and you want to separate it from front-end part
of
application.
To provide this to your application you need to extend Mvp4gStarter
interface and to define @com.mvp4g.client.Configuration annotation and
to
specify value as path to config file for annotation. Then you simply
call
GWT.create(YourExtendOfMvp4gSarter);
Example:
*Configuration("alternative-mvp4g-config.xml")*
*public interface YourExtendOfMvp4gSarter extends Mvp4gStarter {}*
Now your application will have to separate entry points with own
configuration files.
Thanks in advance for your comments."
(see message http://groups.google.com/group/mvp4g/msg/b09a03bc96a7bdeb)
Pierre
Mvp4gStarter. I started looking at GWT 2.x, I think it could be really
useful with the RunAsync mode.
At start, you can load one module:
Mvp4gStarter module1 = GWT.create(Module1.class)
module1.start();
and then later during the execution of your application, you can load
other module when needed:
GWT.runAsync( new RunAsyncCallBack(){
public void onFailure( Throwable reason ) {
// Do sthg
}
public void onSuccess() {
Mvp4gStarter module2 = GWT.create(Module2.class)
module2.start();
}
};
I have some questions:
-should modules share elements (like the event bus, services, history
converters)?
-should modules be able to communicate between each other (can module1
send events defined by module2 and vice versa)?
-should a module defined by one xml-file or would you still give the
possibility to have severals files thanks to module tag you suggested?
I think that one module should be defined in one configuration file in
order not to have too many xml files (to prevent having X modules each
defined by Y configuration files).
What would be perfect, it's when you start your application, one
module is loaded, and whenever an event that requires another module
is thrown, the framework would automatically thrown this event
(developer wouldn't have to check if module is loaded before throwing
the event). I don't know yet if it's possible. What do you think?
On Oct 21, 7:45 pm, Pierre <plcoir...@gmail.com> wrote:
> This message is to continue the discusion about Webdizz's idea on how
> Mvp4g could use new GWT 2.x features:
>
> "In GWT 2.x there is a feature to define code splitting. Separate
> config files could be as modules, each file could contains module
> specific views, presenters and etc. and each module should be
> activated on specific event within "RunAsync" mode. After module
> activation event triggered, module should be downloaded and module
> init action should be performed.
> Thereby we can decrease size of *.js files and application startup
> He also gave two implementation examples:
webdizz
On Oct 21, 9:13 pm, Pierre <plcoir...@gmail.com> wrote:
> I really like your idea of creating severals interfaces that extends
> Mvp4gStarter. I started looking at GWT 2.x, I think it could be really
> useful with the RunAsync mode.
>
> At start, you can load one module:
> Mvp4gStarter module1 = GWT.create(Module1.class)
> module1.start();
>
> and then later during the execution of your application, you can load
> other module when needed:
> GWT.runAsync( new RunAsyncCallBack(){
>
> public void onFailure( Throwable reason ) {
> // Do sthg
> }
>
> public void onSuccess() {
> Mvp4gStarter module2 = GWT.create(Module2.class)
> module2.start();
> }
>
> };
>
it, I guess, will try to run GWT code generation process.
> -should modules share elements (like the event bus, services, history
> converters)?
currently executable module to another or previous one should exist.
In this case all modules should share events and etc., but each has
own config file.
> send events defined by module2 and vice versa)?
possibly leads to "spaghetti-code". It will be more clear to prevent
such opportunities, however there should be ability to catch another's
module event to pass control to this module.
> possibility to have severals files thanks to module tag you suggested?
config file.
> order not to have too many xml files (to prevent having X modules each
> defined by Y configuration files).
Pierre
/**
* This is the entry point method.
*/
public void onModuleLoad() {
Button start = new Button( "start" );
start.addClickHandler( new ClickHandler() {
public void onClick( ClickEvent event ) {
GWT.runAsync( new RunAsyncCallback(){
public void onFailure( Throwable reason ) {
}
public void onSuccess() {
Mvp4gStarter starter = GWT.create( Mvp4gStarter.class );
starter.start();
}
});
}
} );
RootPanel.get().add( start );
}
}
I tried this code with GWT 2.0 and the code has been splitted fine.
> > -should modules share elements (like the event bus, services, history
> > converters)?
>
> I think it depends on the app. For monolithic app the way to go out of
> currently executable module to another or previous one should exist.
> In this case all modules should share events and etc., but each has
> own config file.> -should modules be able to communicate between each other (can module1
> > send events defined by module2 and vice versa)?
>
> i think it's not good idea to throw another's module event this
> possibly leads to "spaghetti-code". It will be more clear to prevent
> such opportunities, however there should be ability to catch another's
> module event to pass control to this module.
The way I see it is that a main module will know one to many child
module(s) and it will have a way to load them.
When a child module is loaded, it will need to know the view where it
is supposed to execute (it could be the GWT RootPanel but it could
also be a particular frame in the page) and information already loaded
by the application. The main module will be in charge of giving these
informations. The child module won't be aware of the main module.
When the application starts, the main module is always loaded.
Does it seem the right way to do it?
Pierre
-modules to load when an event is thrown
-how start view of the child module should be placed inside parent
module view.
To manage this last point, I decide to use an event. You will need to
configure a parent event to throw to place the child view. The parent
event will have to be associated with an object, which type is
compatible with child view type.
It could also be interesting that, when an event loads a child
module, the object associated with this event could be pass to child
module that could use it in its start event.
You will have then something like that:
public ParentEventBus implements EventBus(){}
public void event(MyBean bean){
GWT.runAsync(new RunAsyncCallback() {
public void onSuccess() {
ChildModule childModule = GWT.create(ChildModule.class);
childModule.createModule();
Widget startView = childModule.startModule(bean);
//throw a parent module event to load child view
changeBody(startView);
}
...
});
}
public void changeBody(Widget w){
rootPresenter.onChangeBody(w);
...
}
}
To configure child modules, this is how I see it:
XML:
...
<modules package="com.mvp4g.example.client">
<module name="module1" class=".module1.Module1"
eventToLoadView="changeBody" async="true">
...
</modules>
...
<events>
<event type="changeBody" handlers="rootPresenter" />
<event type="goToModule1" handlers="onePresenter"
modules="module1"/>
...
</events>
Annotations:
@ChildModules(
@ChildModule(moduleClass=Module1.class, async=true)
@ChildModule(moduleClass=Module2.class, async=true)
...
)
@Events(startView=MainView.class)
public interface MainEventBus extends EventBus {
@Event(modules=Module1.class)
public void goToCompany();
@UseToLoadChildView({Module1.class,Module2.class})
@Event(handlers=MainPresenter.class, load={})
public void changeBody(Widget newBody);
}
I also want to have the following rule:
-you can't have two modules with the same class. This would be
forbidden:
<modules package="com.mvp4g.example.client">
<module name="module1" class=".module1.Module1"
eventToLoadView="changeBody" async="true">
<module name="module2" class=".module1.Module1"
eventToLoadView="changeBody" async="true">
</modules>
-an event can load one-to-many modules.
What do you think?
-Pierre
webdizz
As for prohibition of different modules from same class - it's ok, by
the way who wants avoid it can extend Module ;)
Pierre
should be implemented:
public ParentEventBus implements EventBus(){}
public void event(MyBean bean){
GWT.runAsync(new RunAsyncCallback() {
public void onSuccess() {
ChildModule childModule = GWT.create(ChildModule.class);
childModule.createModule();
//throw a parent module event to load child view
changeBody(startView);
childModule.getEventBus().event(bean);
}
...
});
Toine
this would be a nice inplementation.
I think is it could be wise that the parent can pass to a child like
childModule.getEventBus().event(bean);
the getEventBus is a mandatory getter of the ChildModule
also it could be wise to have in the ChildModule something like
ChildModuleA {
getParentEvent(){ }
getParent()
setParent();
}
or like the guice & gin way @Inject it
Pierre
> ChildModuleA {
> getParentEvent(){ }
> getParent()
> setParent();
>
> }
ChildModule is used only by the framework. I'm not sure when you would
use getParent & setParent.
My idea is that a child should act the same way no matter who loads
it.
Now if a child needs to communicate with its parent, one way to do it
it's that the parent pass its event bus when passing the event:
public void event(ParentEventBus parentEventBus){
public void onSuccess() {
//pass event to child
childModule.getEventBus().event(parentEventBus);
...
-Pierre
Pierre
first version of multi-modules features and an example Mvp4gModules.
For now, you can manage multi modules only with annotations (no XML
yet) and only in async mode.
I also added three more options:
-an event to call when an error occurs (@LoadChildModuleError)
-an event to call before a module is loaded and an event to call after
a module is loaded (@BeforeLoadChildModule & @AfterLoadChildModule).
It can be really usefull if you wish to display a wait popup when your
child module is being loaded for example.
Let me know what you think of this feature and if you have any ideas
to improve it.
Thanks,
Pierre
Maurice Zeijen
I have been trying the new module functionality and I like what I see.
I encountered some little problems:
- The @LoadChildModuleError seems to be required when using chid
modules, which is fine, however at first didn't include it and I got a
nullpointer exception in stead of a nice exception that tells me to
include the annotation.
- By defining event methods on the parent event bus it is possible to
propragate events to the child module. But this always results in that
the start view of that event is shown. I believe it would be usefull
if it could be optional to show the start view of the child module.
- So it is possible to send events to a child module from its parent
module, but how do I send events from the child module to the parent?
This would be extremely usefull. For instance if I have a central
'alert' system in the root module then I would like to be able to
trigger it from the child module.
I have one point that isn't about the module system but about the
event system. The current version with annotation is almost type safe
which is a superb feature. However on thing that isn't type safe is
the method declaration of the event handler. In the event bus you
declare a method, for instance showView, and then you must be sure
that the event handler has a method 'onShowView'. It would be great if
this also could become type safe. I am not sure how however.
Keep up the great work.
Regards,
Maurice
Pierre
Thanks for your feedback, I really appreciate it.
> - The @LoadChildModuleError seems to be required when using chid
> modules, which is fine, however at first didn't include it and I got a
> nullpointer exception in stead of a nice exception that tells me to
> include the annotation.
The first version of this feature didn't include any control. I will
add them in the next release.
> - By defining event methods on the parent event bus it is possible to
> propragate events to the child module. But this always results in that
> the start view of that event is shown. I believe it would be usefull
> if it could be optional to show the start view of the child module.
I guess it's something that could be implemented. But, why would you
want to load a child module if the user isn't gonna see? As a best
practice, shouldn't you load a module only when the user will interact
with it?
> - So it is possible to send events to a child module from its parent
> module, but how do I send events from the child module to the parent?
> This would be extremely usefull. For instance if I have a central
> 'alert' system in the root module then I would like to be able to
> trigger it from the child module.
One way you could do it, it's to attach parent's event bus to the
event when you load a child module:
public void goToChild(ParentEventBus eventBus);
But I guess it would be nice to have an easier system. One idea could
be to have the possibility to indicate if an event should be forwarded
to a parent:
@Event(...., forwardToParent=true)
public void displayMessage(String message)
In this case, parent should implement displayMessage. Now I'm not sure
if it can be implemented because when you build the child module, you
don't have access to parent module information. I have to take a
closer look at it.
> I have one point that isn't about the module system but about the
> event system. The current version with annotation is almost type safe
> which is a superb feature. However on thing that isn't type safe is
> the method declaration of the event handler. In the event bus you
> declare a method, for instance showView, and then you must be sure
> that the event handler has a method 'onShowView'. It would be great if
> this also could become type safe. I am not sure how however.
If you declare an handler that actually can't handle the event because
it doesn't define the right method (either because the method doesn't
exist or because the method doesn't have the right parameters), a
Java compilation error is raised and your GWT code won't be able to
compile. That's why I think handlers are type safe. Did you encounter
a type problem with handlers?
> Keep up the great work.
Thanks :)
-Pierre
Maurice Zeijen
My comment is inline:
Hi Maurice.
Thanks for your feedback, I really appreciate it.
The first version of this feature didn't include any control. I will
> - The @LoadChildModuleError seems to be required when using chid
> modules, which is fine, however at first didn't include it and I got a
> nullpointer exception in stead of a nice exception that tells me to
> include the annotation.
add them in the next release.
> - By defining event methods on the parent event bus it is possible toI guess it's something that could be implemented. But, why would you
> propragate events to the child module. But this always results in that
> the start view of that event is shown. I believe it would be usefull
> if it could be optional to show the start view of the child module.
want to load a child module if the user isn't gonna see? As a best
practice, shouldn't you load a module only when the user will interact
with it?
> - So it is possible to send events to a child module from its parentOne way you could do it, it's to attach parent's event bus to the
> module, but how do I send events from the child module to the parent?
> This would be extremely usefull. For instance if I have a central
> 'alert' system in the root module then I would like to be able to
> trigger it from the child module.
event when you load a child module:
public void goToChild(ParentEventBus eventBus);
But I guess it would be nice to have an easier system. One idea could
be to have the possibility to indicate if an event should be forwarded
to a parent:
@Event(...., forwardToParent=true)
public void displayMessage(String message)
In this case, parent should implement displayMessage. Now I'm not sure
if it can be implemented because when you build the child module, you
don't have access to parent module information. I have to take a
closer look at it.
> I have one point that isn't about the module system but about theIf you declare an handler that actually can't handle the event because
> event system. The current version with annotation is almost type safe
> which is a superb feature. However on thing that isn't type safe is
> the method declaration of the event handler. In the event bus you
> declare a method, for instance showView, and then you must be sure
> that the event handler has a method 'onShowView'. It would be great if
> this also could become type safe. I am not sure how however.
it doesn't define the right method (either because the method doesn't
exist or because the method doesn't have the right parameters), a
Java compilation error is raised and your GWT code won't be able to
compile. That's why I think handlers are type safe. Did you encounter
a type problem with handlers?
> Keep up the great work.Thanks :)
-Pierre
--
You received this message because you are subscribed to the Google Groups "Mvp4g" group.
To post to this group, send email to mv...@googlegroups.com.
To unsubscribe from this group, send email to mvp4g+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mvp4g?hl=en.
Pierre
> Well I could think of cases where you want to send some information to a
> module that could use it as soon as it is displayed. But maybe that is
> simply a bad practice and the module should get the information as soon as
> it needs it.
So you actually think it's a better practice to send information right
away?
> I never thought of the possibility to simply send the eventBus with the>
> event call. However I am not sure if that is always that comfortable. For
> instance you are already within a module and you invoke an event to another
> part of the same module then you must make sure that the parent event bus is
> available for that part that is going to invoke the event. Being able to
> retrieve a parent module from some 'module global' point would be the most
> comfortable way.
What do you think of my idea to add a 'forwardToParent' attribute?
@Event(...., forwardToParent=true)
public void displayMessage(String message)
This could be implemented and still be type safe if I add the
following constraint: if you want to communicate with parentEventBus,
then you need to define the following method in your child module
interface:
public interface CompanyModule extends Mvp4gModule {
public void setParentEventBus(ParentEventBus
eventBus);
}
Thanks to this method, the Mvp4g compiler will be able to verify if
events that have to be forwarded to the parent are handled by the
parent event bus. Another advantage is that child presenter don't need
to know if an event is going to be forwarded to a parent or not.
Would this fit your need?
-Pierre
Maurice Zeijen
Hi Maurice,
So you actually think it's a better practice to send information right
> Well I could think of cases where you want to send some information to a
> module that could use it as soon as it is displayed. But maybe that is
> simply a bad practice and the module should get the information as soon as
> it needs it.
away?
> I never thought of the possibility to simply send the eventBus with the>What do you think of my idea to add a 'forwardToParent' attribute?
> event call. However I am not sure if that is always that comfortable. For
> instance you are already within a module and you invoke an event to another
> part of the same module then you must make sure that the parent event bus is
> available for that part that is going to invoke the event. Being able to
> retrieve a parent module from some 'module global' point would be the most
> comfortable way.
This could be implemented and still be type safe if I add the
@Event(...., forwardToParent=true)
public void displayMessage(String message)
following constraint: if you want to communicate with parentEventBus,
then you need to define the following method in your child module
interface:
public interface CompanyModule extends Mvp4gModule {
public void setParentEventBus(ParentEventBus
eventBus);
}
Thanks to this method, the Mvp4g compiler will be able to verify if
events that have to be forwarded to the parent are handled by the
parent event bus. Another advantage is that child presenter don't need
to know if an event is going to be forwarded to a parent or not.
Would this fit your need?
-Pierre
Maurice
Pierre
> > > Well I could think of cases where you want to send some information to a
> > > module that could use it as soon as it is displayed. But maybe that is
> > > simply a bad practice and the module should get the information as soon
> > as
> > > it needs it.
>
> > So you actually think it's a better practice to send information right
> > away?
>
> > I am not experienced enough in this types of applications to say what is
>
> better. I don't think it would be to complex to make it optional to show the
> view on a parent to child module event. Is there any good reason not to
> implement it?
It's actually not that easy to implement bc if you want to be able to
configure for each event, which module view should be load or not
because you need to find a way to easily represent it in xml and
annotations. Unfortunately, you can't have this:
@Event(modules={{Module1.class, true}, {Module2.class, false}, ..})
What can be easier is:
-either having the possibility to configure for an event that for all
the modules to load, module views should be loaded or not (ie either
you load module1 AND module2 views or you don't).
@Event(modules={Module1.class, Module2.class}, loadModulesView=false)
-or having the possibility to configure for a module if, for all
events, its view should be loaded (ie either you load view module for
event1 AND event2 or you don't). Then the child module will have to
manage when its view should be displayed by communicating with its
parent (with the new process, see next question)
@ChildModule(moduleClass= Module1.class, loadModuleView=false)
I'm not sure what solution would fit your need better (maybe 1?).
I think that as a best practice, you shouldn't load code or
instantiate objects that your user won't used that's why it may not be
a good idea to load a module if it's the user won't see it. After,
it's true that there are probably cases where you don't have the
choice.
My idea is that the presenter won't need to know if an event is
forwarded to the parent or not (the framework will manage it). The
less the presenter knows, the better (to prevent 'spaghetti effect').
So it won't need to call the setParentEventBus method. This method is
here just to allow framework to verify that events sent to parent
event bus are actually managed by parent event bus.
There is actually a better way to represent, you could have:
@Parent(ParentModule.class)
public interface CompanyModule extends Mvp4gModule {
}
In case the parent module is the main module, then you would have
@Parent(Mvp4gModule.class)
It shouldn't be too hard to implement so I will add it to Mvp4g 1.1.0
version.
-Pierre
Maurice Zeijen
Regarding "@Event(modules={{Module1.class, true}, {Module2.class, false}, ..})". You can fix this with an array of annotations. For example:
@Event(modules={
@TargetModule(moduleClass=Module1.class, showView=false),
@TargetModule(moduleClass=Module2.class, showView=true)
})
Regarding the @Parent annotation. It sounds like a good solution.
Regards,
Maurice
-Pierre
Pierre
> ..})". You can fix this with an array of annotations. For example:
>
> @Event(modules={
> @TargetModule(moduleClass=Module1.class, showView=false),
> @TargetModule(moduleClass=Module2.class, showView=true)
>
> })
makes @Event annotation a lot more complex than before to manage a
particular case (in most cases, you won't need to set showView).
After having thinking about it, I think the best way to do it it's to
implement the solution 2 I suggested before. Either you want the
framework to autoload view of a particular child module (which will be
the default behavior because I think it's the recommanded way to go)
or you don't want it and you manage it manualy (by settings a
communication from the child module to its parent).
You would then have sthg like that:
@ChildModules({
@ChildModule(moduleClass=..., autoload=false)
})
public class ParentEventBus .... {
@Event(module=...)
public void giveInfoToChild(InfoBean info)
@Event(module=...)
public void displayChild()
public void changeBody(Widget w);
}
public class ChildEventBus .... {
@Event(...)
public void giveInfoToChild(InfoBean info)
@Event(...)
public void displayChild()
@Event(forwardToParent=true)
public void changeBody(Widget w);
}
public class ChildPresenter .... {
public void giveInfoToChild(InfoBean info){
this.info = info;
}
@Event(...)
public void displayChild(){
eventBus.changeBody(w);
}
}
Do you see any problems with this solution?
> Regarding the @Parent annotation. It sounds like a good solution.
I actually realised when I started the implementation that I need a
setParentEventBus method in order the framework to be able to inject
the parent event bus to the child module. Since I have this method,
@Parent annotation is not needed anymore. You would have then
something like that:
public interface CompanyModule extends Mvp4gModule {
public void setParentEventBus(ParentEventBus
eventBus);
}
The purpose of this method is only for configuration (ie it is
analyzed and used only by the framework) so you will never have to
call it in your code.
-Pierre
Maurice Zeijen
Cool, I have nothing to add.
Regards,
Maurice
-Pierre
Pierre
I upload a new snapshot of Mvp4g that includes the communication from
child module to parent. Compared to the last discusion, I had to bring
one small change to give the possibility to manage history for sub
modules. Instead of defining a setter for the parent event bus, you
now need to define a setter for the parent module:
public interface ChildModule extends Mvp4gModule {
public void setParentModule(ParentModule parentModule);
}
If parent module is the root module of the application, then
ParentModule will be equal to Mvp4gModule. You can look at the
Mvp4gModules example to see it in action.
-Pierre
> > mvp4g+un...@googlegroups.com <mvp4g%2Bunsu...@googlegroups.com>.
> > For more options, visit this group at
> >http://groups.google.com/group/mvp4g?hl=en.- Hide quoted text -
>
> - Show quoted text -