Hi, I've been working on a project with PureMVC for Flex for some time and I really like it.
When looking at the example I've noticed a small difference from the GWT implementation, that is the necessity of creating a Provider for executing the Commands. While I understand that it must be done because GWT does not let one use reflection, I think that a small change could remove the necessity of such Provider. If, at the Controller and MacroCommand classes, instead of receiving references to Class<? extends ICommand> , the parameter becomes an instance of ICommand, and when invoking the registerCommand or subCommand we pass a new Instance of the desired Command, it could be achieved. The only difference I see is that there would be always the same reference to the Commands, instead of creating a new instance each time. I don't know if that would be a problem. I have the modified code, and it runs fine with the login example, and I could send it to you (Luciano). By the way, are you brazilian? Thanks On Sat, Sep 20, 2008 at 5:44 PM, Luciano Broussal <[EMAIL PROTECTED]> wrote: > > 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 [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 -~----------~----~----~----~------~----~------~--~---
