Hi Thomas and thanks for your response.
You're right, I'm not talking about how the View sees its Presenter but how
the Presenter is seen from "what's above him" (in my case, usually another
Presenter, my Presenters are nested). From what I understood (and pretty
like it !) from the Google MVP Tutorial
<https://developers.google.com/web-toolkit/articles/mvp-architecture>the
Presenter is usually not a component (or Widget) in itself but puts its
component (its View) inside the container that is given to him in its
go(...) method. So I thought what I am doing was pretty classic MVP...
Nevertheless, I totally agree that the solution using the "HasWidgets" type
in the go(...) method may lead the Presenter to have too much knowlege of
the internals. The drawback: it seems that more components implement the
HasWidgets type rather than the AcceptsOneWidget one. I wouldn't want to
have to force every class to reuse my dirty wrapper (see
HasWidgetsToAcceptsOneWidgetWrapper). Anyone with prior experience ?
Le vendredi 7 septembre 2012 13:21:58 UTC+2, Thomas Broyer a écrit :
>
>
>
> On Friday, September 7, 2012 12:21:19 PM UTC+2, Francois Marot wrote:
>>
>> Hi all,
>>
>> I'll have to set the basics for a in-house framework and can't make my
>> mind on the basic Presenter interface. Is it better to use HasWidgets or
>> AcceptsOneWidget ? This would lead to:
>>
>>
>> public interface Presenter {
>> public void go(final HasWidgets container);
>> }
>>
>> or
>>
>> public interface Presenter {
>> public void go(final AcceptsOneWidget container);
>> }
>>
>> The former is more generic I think but you always have to think about
>> adding the line container.clear() in your implementations. In the latter,
>> it's more straightforward (container.setWidget(myView) ) and it is clearer
>> as it's enforce the responsibility on the depper Presenter to provide only
>> one widget. It's his responsability to group every widget into one
>> container before calling setWidget().
>> I prefer the latter but it seems that more components implement
>> HasWidgets so in the end the former would be easier to developp. What do
>> you think ?
>>
>> For the record, I was forced to develop a wrapper
>> (HasWidgetsToAcceptsOneWidgetWrapper) in order to pass the RootLayoutPanel
>> to my first Presenter using the latter method. Here's the dirty code:
>> public class HasWidgetsToAcceptsOneWidgetWrapper implements
>> AcceptsOneWidget {
>> private HasWidgets wrapped;
>>
>> public HasWidgetsToAcceptsOneWidgetWrapper(HasWidgets wrapped) {
>> this.wrapped = wrapped;
>> }
>>
>> public void setWidget(IsWidget widgetToAdd) {
>> wrapped.clear();
>> wrapped.add(widgetToAdd.asWidget());
>> }
>>
>> }
>>
>
> I suppose from that last comment that your Presenter interface is seen by
> objects manipulating the "MVP component", i.e. it's not the presenter "as
> seen by the view".
>
> Anyway, in either case, it shouldn't be the responsibility of the
> component to display itself, but rather the responsibility of some sort of
> conductor/manager/controller. So just have your presenter implement
> IsWidget and you're done.
> As an added bonus, because it's an IsWidget, you can use it anywhere a
> widget is expected/accepted, including in UiBinder templates.
>
> To answer your question though, it strikes me as odd to use HasWidgets
> here: you really want to give your component the power (and responsibility)
> to clear() its container? or add() more than one widget to it? or inspect
> (via interator()) the widgets already contained in it and possibly remove()
> some of them? (how about removing all but the first 2, adding itself and
> adding the removed widgets back in, to simulate an insert?)
> No, really, you don't want HasWidgets, AcceptsOneWidget is the way to go;
> or IsWidget as I said above.
>
> But all of this really depends how you're intending to use your
> "Presenter" interface. I'm not familiar with that approach (first and
> foremost: I see MVP as an implementation detail, the outside world simply
> deals with a "component" and it doesn't matter whether it uses MVP
> internally or not).
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/LbSJT3t-fXQJ.
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.
