Hi Luciano, On 19 sep, 19:27, Luciano Broussal <[EMAIL PROTECTED]> wrote: > > Here is the > documentationhttp://puremvc.org/component/option,com_wrapper/Itemid,174/. > It is available on the PureMVC Home page.
Thanks (so it was the thing called "best practices" ;-) ) > Maybe you don't like but i'm not sure you can do more simple than the > 15 classes which compose PureMvc and help the developper to separate > layers and the main design patterns it use : > > Proxy > Facade. > Medialor > Commands > View > Controller Don't get me wrong, I didn't say I dislike PureMVC or its approach, quite the contrary actually! Two things though: - I'm not a fan of frameworks, I prefer libraries/toolkits and a set of patterns - given that the PureMVC framework preferred usage is through the "patterns" (Façade, Proxy, Mediator, Command), why not making it lighter with mostly those classes and a few helper classes? (e.g. Model Controller and View are masked behind Facade, just get rid of the singletons and > Anyway, thank you for had a look to the project. Some thoughts: - PureMVC best practices, page 28, reads: "Because of its readability, and the ease of which one may refactor to add or remove Notifications handled, the ‘switch / case’ construct is preferred over the ‘if / else if’ expression style inside the handleNotifications method." Given that you cannot do switch/case on strings in Java, I'd replace the Notification names with integer identifiers. An Enum could be used but that would mean making the classes generics: Facade<E extends Enum>, etc. (to be implemented as "ApplicationFacade extends Facade<ApplicationConstants>"). - AFAIK, a Flex application must inherit mx.core.Application, so it can't inherit Facade at the same time; hence the dichotomy; but in GWT we implement EntryPoint, so the Facade could be the EntryPoint, with appropriate abstract methods to avoid the need for explicitly calling a "startup" method. This might lead to "bad uses" of the framework though, where the façade would have direct access to - I haven't yet read the "best practices" 'til the end but couldn't a Mediator be a Composite? - I'm concerned that there's no notion of "relevant" mediators at a given time (e.g. in a tabbed app, the components outside the active tab are "irrelevant", so handling of notifications could just be "mark as dirty" and when the components become "relevant" again, they can re- build or update their UI subcomponents); or should it be handled on the "visual component" side and have the mediator handle notifications independently of this relevant/irrelevant state) The EntryPoint as Facade and Mediator as Composite would drastically reduce the sample's code... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
