Thomas, Thanks for your interesting point of view.
Feel free to checkout the project and you can help me to get it better. Currently is a port of the java version of PureMVC but i didn't want to change it to not loose people who already know and use PureMVC with other languages. Regards. On 20 sep, 21:31, Thomas Broyer <[EMAIL PROTECTED]> wrote: > 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 Google-Web-Toolkit@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
