Natan, if you need some help with GIN, feel free to ask in the list. I
think that most of the new projects are using GIN as DI framework.

On Mon, Aug 24, 2009 at 5:34 PM, Nathan<[email protected]> wrote:
>
> I see where you're going, with that gwt-mvp-sample code.  With GIN,
> you don't even need to think about my problem, because every Presenter
> is automatically going to be created and injected with the right
> View.  I think in your case, your answer is more along the lines of
> "Let GIN do it for you," which is certainly a fine idea -- sadly, I
> spent an entire day trying to get GIN to work with no success, so I
> gave up 'cause manual DI works fine for me for the most part.  This
> conversation has made me feel like I have a good understanding of this
> problem now, but it doesn't seem to agree with anything anyone has
> said.  Basically, in my mind, what I'm seeing now is a Presenter gets
> to think "Okay, I am a presenter.  I have some Display requirements:
> my Display needs to know how to display this text, handle these
> clicks, and view these child Presenters."  Then the View
> implementation is responsible for knowing what Display classes to use
> for the Presenter -- if it's a MockMainDisplay, it would instantiate
> and bind a MockChildDisplay, if it's a live website MainWidget, it
> would instantiate and bind the ChildWidgets.  This way, View handles
> the View, Presenters handle the Presenters.  Of course, the better
> idea here would be to use GIN.  Perhaps, since I have a small sample
> code that uses GIN in gwt-mvp-sample, I can give that another try.  :)
>
> Thanks again for all the help, everyone.
>
> On Aug 24, 1:28 pm, Christian Goudreau <[email protected]>
> wrote:
>> I'll add something :http://code.google.com/p/gwt-mvp-sample/
>>
>> And one comment about decoupling. There will be always time when some
>> component cannot work without others. You can decouple them, but you'll have
>> to add it at one point in one presenter.
>>
>> In that example, the main container is MainPresenter and his job is to
>> assemble the other views and presenters. Maybe it'll be more clear with this
>> then everything I could say :)
>>
>> Christian
>>
>> On Mon, Aug 24, 2009 at 1:22 PM, Christian Goudreau <
>>
>> [email protected]> wrote:
>> > Sorry then, it's clear in my head, but I got some difficulty to translate
>> > it in English. And by the way, by your question, you cleared my own
>> > questions about it ! LOL
>>
>> > Christian
>>
>> > On Mon, Aug 24, 2009 at 12:58 PM, Ian Bambury <[email protected]>wrote:
>>
>> >> I think I could do with an example which matches your problem more
>> >> closely. The email header thing obviously doesn't really mirror what you 
>> >> are
>> >> doing, and comments like
>>
>> >>> My complex object is three things - a complex data structure, a complex
>> >>> presenter, and a complex view.
>>
>> >> is too vague (for me anyway) to be able to give an answer (even if it's
>> >> 'dunno, mate').
>>
>> >> Ian
>>
>> >>http://examples.roughian.com
>>
>> >> 2009/8/24 Nathan <[email protected]>
>>
>> >>> I'm not sure I follow.  My complex object is three things - a complex
>> >>> data structure, a complex presenter, and a complex view.  The Widget
>> >>> aspect is just one implementation of the view, and I do understand
>> >>> that it is just a widget.  However, my MockDisplay is not a widget,
>> >>> and in my unit tests, there is no widget.  My question is about how
>> >>> the parent and child Presenters and parent and child Views relate/
>> >>> interact with each other.  Your comment seems to be about how a View
>> >>> would add a child View, but who would be calling addSearchBar on a
>> >>> view?  The parent Presenter?  That doesn't make sense, nor does it
>> >>> decouple.  As such, your example is just adding to my confusion, not
>> >>> clearing it up... :/
>>
>> >>> Thanks for tryin', though!
>>
>> >>> -nathan
>>
>> >>> On Aug 24, 8:35 am, Christian Goudreau <[email protected]>
>> >>> wrote:
>> >>> > You have to see your complex object as another Widget. On the
>> >>> container, you
>> >>> > simply add this complex widget that has his listeners and maybe other
>> >>> > complex widget in it. Little example for the view :
>>
>> >>> >     public void addSearchBar(WidgetDisplay display) {
>> >>> >         removeSearchBar();
>> >>> >         searchBar = display.asWidget();
>> >>> >         seekBarPanel.add(searchBar);
>>
>> >>> >     }
>>
>> >>> >     public void removeSearchBar() {
>> >>> >         if (searchBar != null) {
>> >>> >             searchBar.removeFromParent();
>> >>> >         }
>> >>> >     }
>>
>> >>> > If you have to register for changes in the main container, since you
>> >>> have an
>> >>> > event bus, you don't have to passe everything up, you only have to
>> >>> register
>> >>> > for events that your hoping for and then you act according to it, so
>> >>> it's
>> >>> > not a problem if you decouple everything in small pieces.
>>
>> >>> > By the way, I'm using the framework Presenter.
>>
>> >>> > Christian
>>
>> >>> > On Sun, Aug 23, 2009 at 10:44 PM, Nathan <[email protected]>
>> >>> wrote:
>>
>> >>> > > Hmm.  Okay, and since my case has a complex row (not just String/
>> >>> > > ClickHandler -- but a whole Presenter/Display for an Object that has
>> >>> > > multiple/complex details.  So...:
>>
>> >>> > > class MainPresenter {
>> >>> > >  interface Display {
>> >>> > >  // easy stuff
>>
>> >>> > >  void clearEmails();
>> >>> > >  void addEmail(EmailDetails email);
>> >>> > >  }
>> >>> > > }
>>
>> >>> > > Then:
>>
>> >>> > > class EmailPresenter {
>> >>> > >  interface Display {
>> >>> > >    HasText getSubjectLabel();
>> >>> > >    HasText getBodyLabel();
>> >>> > >    HasClickHandlers getReplyButton();
>> >>> > >    // etc...
>> >>> > >  }
>>
>> >>> > >  ...
>> >>> > > }
>>
>> >>> > > So, do I just have a bad design idea here?  I don't want my
>> >>> > > MainPresenter.Display implementation instantiating EmailPresenters...
>>
>> >>> > > How about changing
>> >>> > > MainPresenter {
>> >>> > >  interface Display {
>> >>> > >    ...
>> >>> > >    void clear();
>> >>> > >    void addEmailPresenter(EmailPresenter email);
>> >>> > >  }
>> >>> > > }
>>
>> >>> > > Then the Display picks the Displays for the sub-Presenters...  Yeah,
>> >>> > > this is making some sense now.  Does this sound about right to
>> >>> others?
>>
>> >>> > > Thanks for the help!
>>
>> >>> > > -nathan
>>
>> >>> > > On Aug 23, 9:53 pm, Ian Bambury <[email protected]> wrote:
>> >>> > > > Hi Nathan,
>> >>> > > > I think all you need is a clear() and an addLine(String text).
>>
>> >>> > > > The presenter clears the display and loops through the headers
>> >>> adding
>> >>> > > lines
>> >>> > > > as it goes. If you need to respond to clicks, then add a click
>> >>> handler
>> >>> > > > parameter to the addLine method.
>>
>> >>> > > > Or am I missing something here?
>>
>> >>> > > > Ian
>>
>> >>> > > >http://examples.roughian.com
>>
>> >>> > > > 2009/8/24 Nathan <[email protected]>
>>
>> >>> > > > > Hello everyone.
>>
>> >>> > > > >  I watched Ray's talk, and have been reworking my project to
>> >>> follow
>> >>> > > > > many of his suggestions/standards, and have been quite happy with
>> >>> the
>> >>> > > > > results.  Today, however, I ran into a small problem.  I am
>> >>> making a
>> >>> > > > > website that has a layout fairly similar to an email program --
>> >>> that
>> >>> > > > > is, there are a variety of buttons/widgets/whatever in the
>> >>> interface,
>> >>> > > > > plus a set of some number of rows in a table, essentially.
>> >>>  (Email
>> >>> > > > > header info, basically?).  Here's the Presenter/Display idea:
>> >>> > > > >  class ExampleEmailPresenter {
>> >>> > > > >    interface Display {
>> >>> > > > >      HasClickHandlers getComposeNewEmailButton();
>> >>> > > > >      ... various other buttons
>>
>> >>> > > > >      HasValue<String> getSearchEmailField();
>> >>> > > > >      ... etc -- all this makes sense to me, and I've done it on
>> >>> my
>> >>> > > > > less complex pages and it works
>>
>> >>> > > > >      // Now, how do you handle the display of a set of emails?
>> >>> > > > >      // ArrayList<EmailOverviewPresenter.Display>
>> >>> getEmailDisplays
>> >>> > > > > () // ?
>> >>> > > > >      // HasListOfValue<EmailOverview> getEmailOverviewList(); //
>> >>> a
>> >>> > > > > new Has* idea?
>> >>> > > > >      // Something I'm not thinking of? (this is what I'm assming)
>> >>> > > > >    }
>>
>> >>> > > > >    ArrayList<EmailOverview> emails;
>> >>> > > > >    // Then register on the EventBus to receive alerts when the
>> >>> email
>> >>> > > > > list is updated, and call:
>> >>> > > > >    public emailListUpdated() {
>> >>> > > > >      // This would be code to connect up the Email list Displays
>> >>> to
>> >>> > > > > the emails.
>> >>> > > > >    }
>> >>> > > > >  }
>>
>> >>> > > > >  Basically, I can think of a few ways that I could connect them
>> >>> up,
>> >>> > > > > but every way I think of feels like a hack, like I'm missing the
>> >>> > > > > really smooth, clean way to have a list of something.  I mean,
>> >>> even if
>> >>> > > > > it's just an unknown number of Strings you want in your
>> >>> display...
>> >>> > > > > How does one Presenter's Display have a set of child displays
>> >>> (even if
>> >>> > > > > they are jut HasText's or something simple) without crossing
>> >>> borders,
>> >>> > > > > or having a lot of ugly maintenence code?  Any examples or
>> >>> suggestions
>> >>> > > > > out there?  Basically, what I'd like to see is what structure you
>> >>> put
>> >>> > > > > in the Display, what structure you put in the Presenter, and what
>> >>> > > > > logic would go into the "The Data Was Updated" function...  Even
>> >>> just
>> >>> > > > > a description of what you'd do is fine, this entire Email example
>> >>> is
>> >>> > > > > made up for discussion anyway, I'm just looking for help with
>> >>> > > > > understanding the design paradigm.
>>
>> >>> > > > > Thanks in advance,
>>
>> >>> > > > > -nathan
> >
>



-- 
Eduardo S. Nunes
http://e-nunes.com.br

--~--~---------~--~----~------------~-------~--~----~
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