Mvp4g News (continued)

[Pierre Coirier]

The first snapshot of mvp4g-1.4.0 is available (you can find it in the
download section). It includes 2 features:
-possibility to block (or deactivate) a presenter for a specific event
(issue 76, see the documentation here:
http://code.google.com/p/mvp4g/wiki/PresenterViewService_140#Blocking_Presenters)
-possibility to automatically generate multiple presenters when firing
an event (issue 81, see the documentation here:
http://code.google.com/p/mvp4g/wiki/PresenterViewService_140#Event_Generate_Feature)

It also includes the corrections of the following issues: 79, 80, 82.

Let me know if you have any problem.

Thanks,
Pierre

[Jeff Larsen]

Thanks so much Pierre!

[Pierre Coirier]

A second snapshot of Mvp4g-1.4.0 is available. It includes 1 new
feature and 1 major change:
-startView has been replaced by startPresenter to make the event bus
view free. The change should be pretty easy, you can just set your
start presenter instead of your start view. The main impact is that
when you use @DisplayChildModuleView: the method annotated must accept
one parameter compatible with the view interface of the start
presenter (before it was only had to be compatible with the
implementation of the start view, not its interface).

-possibility to easily switch GIN module to set different view
implementations for different devices (android, iphone, ipad..., see
the documentation for more information:
http://code.google.com/p/mvp4g/wiki/GinIntegration_140#Setting_GIN_module_for_multiple_devices)

Let me know what you think and if you encounter any issue.

Thanks,
Pierre

[Rocco De Angelis]

Very cool .. THX Piere!

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.

[cybervision]

Perfect!

On 12 Jul., 01:27, Pierre Coirier <plcoir...@gmail.com> wrote:
> A second snapshot of Mvp4g-1.4.0 is available. It includes 1 new
> feature and 1 major change:
> -startView has been replaced by startPresenter to make the event bus
> view free. The change should be pretty easy, you can just set your
> start presenter instead of your start view. The main impact is that
> when you use @DisplayChildModuleView: the method annotated must accept
> one parameter compatible with the view interface of the start
> presenter (before it was only had to be compatible with the
> implementation of the start view, not its interface).
>
> -possibility to easily switch GIN module to set different view
> implementations for different devices (android, iphone, ipad..., see

> the documentation for more information:http://code.google.com/p/mvp4g/wiki/GinIntegration_140#Setting_GIN_mo...)

[Jeff Larsen]

Hey Pierre, any chance you can push the snapshot build into the googlecode maven repo?

[Pierre Coirier]

Hi Jeff,

The second snapshot of mvp4g-1.4.0 is already available on the
googlecode maven repo (http://mvp4g.googlecode.com/svn/maven2/
snapshots/com/googlecode/mvp4g/mvp4g/1.4.0-SNAPSHOT/
mvp4g-1.4.0-20110711.230104-2.jar).

Any issue to download it (maybe a cache issue)?

Pierre

[Jeff Larsen]

Oh shoot, I was pointing at the release repo, not the snapshot repo. Sorry!

[Jeff Larsen]

One thing I just noticed with the generation of multiple presenters is that when one gets added it doesn't get removed. I can add getEventBus().removeHandler(this) to all my methods but it seems like it would make the most sense to remove the handler immediately after creation. 

What if on Generate it not only created the presenter and added it to the event bus, but it also removed it after the event is fired? 

Something like this:

OneMultiplePresenter one = eventBus.addHandler( OneMultiplePresenter.class );

one.onExecuteEvent(SomeEvent evt);

eventBus.removeHandler(one);

[Pierre Coirier]

Hi Jeff,

I think removing it right after might be a particular case. Most of
the time you will probably want to keep your handler, above all if
your handler is a presenter (otherwise your user doesn't have time to
interact with its view). One case, for example, is adding a new widget
each time the user clicks on a create button. In this case, you may
fire an event that generates a new presenter/view you want to keep on
the screen so that the user can interact with it.

Also if you plan on removing your handler right after it handles your
event, do you really need to use the multiple feature because it seems
you will have only one instance of this handler at all time?

Pierre

[Jeff Larsen]

Removing the handler from the EventBus doesn't remove the widget from view, it just means I can't interact with it via the event bus.

For example, lets say i have an event on the EventBus that opens up a DialogBox. 

I can have multiple dialog boxes displaying at one time, and each time I call showDialog(IsWidget widget) I want a new dialog box.

In my EventBus I have 

   

    @Event(generate = DialogPresenter.class )

    void showMessage(IsWidget message);

The first time I execute showMessage one dialog appears. I close the dialog, then execute the code that executes showMessage again and I get one dialogbox with a widget inside it, and another that is empty. I close both of those, and the next time I get 2 empty dialog boxes and 1 with the widget inside it. 

[Pierre Coirier]

I think I get your issue a little bit better. The problem here is that
showMessage should be handled only by the new generated presenter and
not the ones previously created. Instead of removing the handler from
the event bus, we could have this:

//only the newly generated presenter will handle the showMessage
event

@Event(generate = DialogPresenter.class )
void showMessage(IsWidget message);

//all the instances of DialogPresenter will handle this event,
included the new generated one
@Event(handlers=DialogPresenter.class, generate =

DialogPresenter.class )
void showMessage(IsWidget message);

What do you think?
Pierre

[Jeff Larsen]

That sounds great. 

[Pierre Coirier]

A new snapshot of Mvp4g-1.4.0 is available. It includes:
-implementation of issue 86: sibling module communication. You can now
forward events to the parent module, the child modules and the direct
sibling modules (for more information: http://code.google.com/p/mvp4g/wiki/MultiModules_140).
-event generation feature has been changed so that only the new
generated handler handles the event by default (for more information:
http://code.google.com/p/mvp4g/wiki/PresenterViewService_140#Event_Generation).

Let me know what you think and if you ever have any issue.

Thanks,
Pierre

[Pierre-Laurent Coirier]

A new Mvp4g-1.4.0 snapshot is available. It includes the bind feature
to ease nested view management:
http://code.google.com/p/mvp4g/wiki/GinIntegration_140#Using_GIN_to_manage_nested_views.
You can also look at the MailWithMvp4g example now included with the
snapshot. A particular thanks to Sergey Shvets for implementing this
feature.

There is also a minor change concerning the feature to block presenter
based on events. Instead of overriding isActivated, you need to
override the pass method. This method must return false if the
presenter is blocked, true otherwise:
http://code.google.com/p/mvp4g/wiki/PresenterViewService_140#Blocking_Presenters.

Let us know what you think and if you have any issues,

Thanks,
Pierre

[Pierre Coirier]

A new Mvp4g-1.4.0 snapshot is available. It includes the splitter
feature to easily split one or a few presenters/event handers. You can
find the documentation here: http://code.google.com/p/mvp4g/wiki/MultiModules_140#Splitter
and look at the last Mvp4gModules example.

There are two known issues with this feature:
-issue 103: you can't split a multiple presenter/event handler. I will
change this for the 1.4.0 release.
-issue 104: there is a bug with gwt-2.4.0 and the multiple-device
feature (new feature in mvp4g-1.4.0). With this feature, all fragment
ends up in the left-over fragment (see this thread for more
information: http://groups.google.com/group/google-web-toolkit/browse_thread/thread/99759f1d000b4f8f/).
I'm looking into it and should have a fix soon.

Let me know what you think and if you have any issue.

Thanks,
Pierre

[Pierre Coirier]

A new snapshot of Mvp4g-1.4.0 is available. It includes:

-a fix for the multi-devices feature and code splitting.
-support for multiple presenter and splitter. You can split a multiple
presenter but you can generate it only thanks to the generate
attribute of @Events:
http://code.google.com/p/mvp4g/wiki/MultiModules_140#Splitter_and_Multiple_Presenter/Event_Handler.

Let me know what you think and if you have any issue.

Concerning the roadmap of 1.4.0, I'd like to add a new feature, the
module loader (issue 73) and correct a few bugs (including better GIN
integration, issue 95). There are other popular enhancement (like
annotation inheritance), I think they're great feature but may take
some time and I'd like to have a final 1.4.0 version soon, hopefully
in a month or two.

Thanks,
Pierre

ps: You can't generate a split multiple presenter with addHandler
method. I tried to support this method but I couldn't find a solution
where the split presenter didn't end up in the leftover fragment. If
anyone has experience with code splitting and is willing to look at
this, let me know. Thanks.

[Pierre Coirier]

A new snapshot of Mvp4g-1.4.0. It includes the module loader feature:
http://code.google.com/p/mvp4g/wiki/MultiModules_140#Loader

Let me know what you think and if you have any issue.

Thanks,
Pierre

[martin.gutenbrunner]

I'm really looking forward to the Splitter feature.

Any idea about the release date of 1.4.0?

Great work, thanks

[Pierre Coirier]

There is one more feature to implement before releasing 1.4.0 so
hopefully by the end of Febuary.

On Jan 17, 2:32 am, "martin.gutenbrunner" <martingu1...@gmail.com>
wrote:

[Pierre Coirier]

A new Mvp4g-1.4.0 snapshot is available. Place service and logger are
now generated with GIN. This snapshot includes all the features
planned for 1.4.0.

Let me know if you encounter any bugs, final delivery should be coming
soon…

Thanks,
Pierre

[Wensheng Chen]

Ahh sorry, I just read the previous few posts. I am looking forward
for March. :)

[Wensheng Chen]

Awesome :) Let me see what's new.
When is the anticipated time for full blown release of 1.4?

On Feb 9, 10:42 pm, Pierre Coirier <plcoir...@gmail.com> wrote:

[Pierre Coirier]

Mvp4g has now its Google+ page: https://plus.google.com/109663970589991411522.
Don't hesitate to follow it to get the latest news on the framework
and share your project and experience with Mvp4g.

Thanks,
Pierre

[Pierre Coirier]

I updated the blog examples with mvp4g-1.4.0.

[Pierre Coirier]

Mvp4g-1.4.0 is finally available on maven central.

[Deba]

Hi Peter,

Personally wanted to thank you for your work and have a feasibility question and thus didn't want to pollute the group. 

Technically is it possible to build an EventBus from a configuration object from database assuming that the required handlers in the Presenters of the  components exists and do use some required annotations if needed. So theoretically such a configuration will primarily contain data about all components that are going to receive a specific Event from the EventBus. 

Any pointers about how we can go about building such a DynamicEventBus would be extremely helpful. I wouldn't cloning MVP4G and submitting my code for review. 

Please let me know. 

thanks,

Debasish

On Monday, 13 June 2011 00:04:22 UTC+5:30, Pierre-Laurent Coirier wrote:

The first snapshot of mvp4g-1.4.0 is available (you can find it in the
download section). It includes 2 features:
-possibility to block (or deactivate) a presenter for a specific event
(issue 76, see the documentation here:
http://code.google.com/p/mvp4g/wiki/PresenterViewService_140#Blocking_Presenters)
-possibility to automatically generate multiple presenters when firing
an event (issue 81, see the documentation here:
http://code.google.com/p/mvp4g/wiki/PresenterViewService_140#Event_Generate_Feature)

It also includes the corrections of the following issues: 79, 80, 82.

Let me know if you have any problem.

Thanks,
Pierre

[Pierre-Laurent Coirier]

Hi Debasish,

Thanks for your support:) 

> Technically is it possible to build an EventBus from a configuration object

> from database assuming that the required handlers in the Presenters of the 

> components exists and do use some required annotations if needed. So

> theoretically such a configuration will primarily contain data about all

> components that are going to receive a specific Event from the EventBus.

What do you want to do? Do you want to read the config file when you build your GWS app or when you start your app?

Pierre

[Deba]

Hi Pierre,

Sorry didn't get an update on this so kinda missed responding in time.

The idea is we want to get a eventbus and wiring description from server embedded in some form (json) in the html page and want to wire the components required dynamically on startup or when the event is fired first time. 

Is this doable ? Any pointers will be helpful. 

thank you,

Debasish

[Frank Hossfeld]

We have started with version 1.6.0. If you have any ideas for the next version, let us know. The first thing we did was to enable building mvp4g with the current gwt version (2.7.0)

[Nicolas Perez]

Hi Frank,

I was thinking, I could collaborate with a new feature for MVP4G than can reduce the amount of boilerplate code necessary to execute event handlers in a delayed way.

I will explain myself with a use case, given an event:

@Event(handlers = { PresenterUI.class, PresenterSave.class })
void nextPage();

The execution of the line "eventBus.nextPage();" will call all their handlers in a sequential order, first PresenterUI.onNextPage() and immediately later PresenterSave.onNextPage().

But some times it is required to finish the execution of some presenters as soon as possible, in order to show a fast visual response. Following the previous example, it is more important to show the next page, than saving the page. The actual version of MVP4G (1.5.0) calls all handlers and then just after finishing that, the changes in the DOM will be visible to the user.

To avoid such situation and as a workaround, PresenterSave.onNextPage() can be implemented so:

public void onNextPage({
    Scheduler.get().scheduleFixedDelay(new RepeatingCommand() {
        @Override
        public boolean execute() {
            //code to save the page
            return false;
        }
    }, 1000);
}
This implementation allows to show a quick visual response by putting all DOM changes in PresenterUI and the rest in PresenterSave, but the situation can get cumbersome if the event has many handlers and it is desired to delay all of them except by one, for example:

@Event(handlers = { PresenterUI.class, PresenterSave.class, Presenter3.class, Presenter4.class, Presenter5.class})
void nextPage();

In such case, not only PresenterSave has to handle the event using Scheduler but Presenter3, Presenter4 and Presenter5 have to do it as well.

As a proposal, the event declaration for the delayed execution of handlers can be done like this:

@Event(handlers = { PresenterUI.class }, delayedHandlers={PresenterSave.class, Presenter3.class, Presenter4.class, Presenter5.class}, delay={1000})
void nextPage();

Where "delay" and "delayedHandlers" are optional values, and "delayedHandlers" can be set without setting "delay", the default value of delay can be 1000 (1000 millisecond).

With that simple declaration the execution of delayed handlers can be centralized in one place and it will do MVP4G more versatile.

What do you guys think about it?

[Lukas Schmidt]

Hi Nicolas,

thank you for your efforts and your participation to improve the framework. I think that it is dangerous to work with delays. When you are working with a delay, it is not guaranteed that the action has been completed successfully. I think that the use case what you are describing is solved by a better solution. You can use the NavigationConfirmation feature of the mvp4g framework. The idea is that before leaving the current page, you fire a savePage Event in the current Presenter to save the page. You implement the onSavePage-Event in Presenter PresenterSave. After doing the saving process you confirm the navigation event to switch to next page. You know what I mean?

For more information about the NavigationEvent click on the Link.

I'm not a fan of delayed actions. I think that it is always better to end an action with a confirmation as to trust that it is complete after x seconds. Maybe there is another use case where delayed events are needed. What do you think guys?

Best regards

Lukas