On Jul 22, 3:51 am, Thomas Broyer <[email protected]> wrote: > They're IMO as easy to parse > as "path-like" tokens like Gmail uses; it's just a matter of taste > (and how you'd like to model your internal API)
Agree that the implementation depends on the model for an applications internal API. Part of me thinks that most of the design patterns Ray presented may not be generalizable into a Presenter, Place, EventBus, or Command Pattern API library that would work for everyone. For everyone who likes a simple key/value structure to place objects (where any large paths are aspects of parsing a value token in an application dependant way), there is someone who likes query-string like tokens. For everyone who thinks an application wide event bus is useful, there's someone that wants to partition an event bus into specific components. And for everyone that wants a series of core classes that represent all Presenter and View interfaces/objects, there are individuals that will prefer to implement M-V-P in their own classes without providing interfaces and abstractions. You bring up a good point regarding preference, and I think its relevant to this thread in considering that there isn't a clear cut approach to the design patterns presented that is right or wrong for any given application. Each developer must pick their poison, so to speak, and make trade off's based on their concerns. Respectfully, Jason --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
