Thank you very much for the latter link - I just finished reading this wonderful article. But - if I'm not mistaken - according to this suffering-oriented programming I did the right thing: I collected a set of use-cases (in my particular case: the ItemListener, NPCListener and Belongings, which display different information in a very similar manner), I hacked down a solution that sort-of works, but even though I tried to prevent the mistakes you make almost by default, I'm sure my code is sloppy and not as efficient as it could've been if it went through a process described by Nathan Marz.
I think I'll try to do what itches me sort-of the most about my program now: I really want to go about working on the application business logic rather than having to deal with all the stuff regarding the display etc. But in order to be able to get to developing that business logic, I'll have to deal with the latter problem first, no? I want to abstract the UI-elements as much as I can, to be able to have them do the same work they do now, but make it easier for me to go about the actual application logic. If I consequently follow this idea, I'd be probably where I was at the beginning: I think I'm not sure what I have to do first... try to switch to some UiBinder-driven interface? Implement Activities/Places or a MVP-approach? What I certainly dislike about what I've "produced" is, that I have to deal with basic UI-definition as I had to when I used Swing or AWT. And if I'm at the widgets, I want to be able to encapsulate as much as possible in order for them to reveal just the functionality I really need to have my use-case work. Thank you for your reply :). Igor. -- 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.
